I am progressing well with Bazzite now. Underlying preliminary setup, theme selection, and theme installation functions have been created. The CLI can also handle theme selection and installation. I’m also planning on adding a theme creation utility into Bazzite so that users can create their own theme. The code isn’t really object oriented–just a bunch of functions put together. However, it should convert well when I start building the GUI.
Monthly Archive for February, 2007
Now that I’ve played around with splash screens in Beryl, I have discovered that a manager that would take care of the settings for you would be kind of nice to have. Enter Bazzite. While Emerald is a manager for window decorations, Bazzite aims to be a manager for splash screens. The keyword there is “aims.” I doubt that Bazzite will ever be nearly as good as Emerald is.
Bazzite, or Bazz for short, will allow designers to package their splash screen designs in a .tgz archive. The archive will contain four files: logo.png, background.png, splash.conf, and screenshot.png. The first two are the images that will be used in the splash screen. The file splash.conf will contain the settings that will correspond with the .beryl/settings file, as well as a description of the splash screen. The fourth file will be a sample screenshot that will allow the user to preview the splash screen.
Bazzite will allow users to install and choose splash screens for Beryl. It will also eventually allow users to edit the splash screens (just as Emerald allows users to edit window decorations).
Yes, this program is useless. But it is a good way to get back into Python. I haven’t programmed in this language for a long time now. If things go really well, it will facilitate the creation of more splash screen images.
For the reason why I chose Bazzite for the name, take a look at this page. The fact that bazzite is related to beryl but not a direct form of it fits perfectly with this program.
I’ll try to have a command line version out as soon as I can. Progression to a GUI will take a little while though. I’ll probably use the GTK bindings for Python.
I’ve been working on a glassy-blurry-dizzying splash screen for Beryl. You can follow its progress via this topic at the Beryl forums.
Basically, I wanted to create a new splash screen that takes advantage of the features of Beryl’s awesome Splash plugin. At first, the background was just a simple shadow that wobbled around. However, as I discussed the evolution of the splash screen with a forum member or two, crimesaucer suggested that I don’t show the wobbliness of the background. I then played with the concept of diagonal lines running through the background. And that’s more or less how it came to be.
It’s still a work in progress. I’ve got a bunch of things to do with it right now, but you can grab a copy of the latest images here:
Screenshot (click for larger view):
Splash Logo: http://joeyjwc.x3fusion.com/pic/splash_logo.png
Splash Background: http://joeyjwc.x3fusion.com/pic/splash_bg.png
The screenshot definitely doesn’t do the splash image justice. I’ll post up a video once I can get XVidCap actually working…
Edit: Here are a couple of videos:
One from me:
http://joeyjwc.x3fusion.com/ext/beryl-splash-glassy.avi
One from delfick, another Beryl user (better quality, in my opinion):
http://delfick.videos.googlepages.com/beryl-splash.mp4
I was bored, so I quickly recorded an example of what I can do with VKeyBd. I made several mistakes because I recorded it only only once with virtually no warmup time at all, so don’t expect it to be any good. And the sound quality isn’t great because I can’t seem to find a way to record what my computer outputs (and also hear what I’m playing) except by redirecting the output to the input of another computer (I guess I could make a simple splitter, but I don’t have enough parts to make one right now). The overall point, however is to just show what VKeyBd can do. The piece is the Toccata from Bach’s Toccata and Fugue in d minor. I can play it much faster (and more evenly) on a piano keyboard; it seems harder to play on a QWERTY keyboard.
Here’s a screenshot of VKeyBd (click for larger view):
And here’s the mp3 file:
http://joeyjwc.x3fusion.com/ext/toccata.mp3
Enjoy!
I’ve always had an irrational fear of compiling the Linux kernel. I think it stems from some bad experience that I vaguely remember having once (nothing is scarier than seeing “kernel panic” fill your screen). However, now I’m going to try to conquer that fear. I’ve compiled custom kernels before, but now, I’m trying to optimize the kernel as much as I possibly can. I’ve gotten rid of support for devices and chipsets that I’ll never use, integrated a ton of options right into the kernel instead of as modules, and enabled some optimization options such as 4kB stacks, 1000Hz timing (Ubuntu uses 250Hz by default), and kernel preemption to speed up the system.
I’m compiling my first passthrough. I’m getting a TV card soon, so I left all of the TV card options as modules until I find out which card that I get. I fully don’t expect this to work. Usually, it takes me two or three tries, especially since I’ve gotten rid of almost everything and thus probably got rid of a bit too much. I’m also going to need to reinstall my nVidia drivers and may need to compile some programs over again.
Edit: It only took me two tries. 
joey@alpha:~$ uname -r
2.6.17.14-ubuntu1jcustom2alpha
joey@alpha:~$ lsmod
Module Size Used by
nvidia 6827476 34
That’s one clean kernel. It took me two tries because the first time, I had accidentally enabled the nVidia Framebuffer, which needs to be disabled in order to compile the nVidia accelerated drivers.
The system boots in under 30 seconds now. Literally: GRUB Menu (wait 1 second), “Starting Up…” (wait 3 seconds), some disk information and startup messages (wait 5 seconds), loading the KDE desktop (about 10 seconds before the desktop appears and another 5 to start and stabilize Beryl).
Next, I’ll probably recompile some software in order to improve optimization.
Edit: How I did it:
Basically, I grabbed the kernel sources (2.6.17.14) and symlinked them to /usr/src/linux (they are really installed in /usr/src/linux-source-2.6.17.14). Most programs like it when you do this, so I would recommend it.
Next, I copied my kernel configuration from /boot/config-2.6.17-10 or whatever it was to /usr/src/linux/.config. Then, I ran make oldconfig to set the system up as it was before. Then, I did kdesu make xconfig to present me with a list of all of the options. I systematically went through all of these options, completely removing support for all of the hardware and other stuff that I didn’t need and compiling the rest into the kernel to improve speed. If I didn’t know whether I needed something or not, I would run lsmod |grep [modulename] to see if it was loaded. If it wasn’t, I removed it. So, I basically just continued to do this until I got to the kernel hacking options, where I enabled some speed optimization features. Then I compiled it with make-kpkg –initrd –append-to-version=jcustom kernel_image kernel_headers. That created two Debian packages, one for the kernel image and one for the kernel headers. The final step was to just run dpkg -i on the kernel image and fix the GRUB bootfile (every time I upgrade my kernel, it removes all of my options and replaces it with what it wants), and then I was done.
