briancarper.net (λ) (Tag: Themes)

Fluxbox, we meet again

Sun, 15 Nov 2009 16:32:59 -0800

I'm sort of tired of KDE4 crashing left and right and Plasma barfing all over me all day. So I decided to check out the current state of lightweight window managers.

Lo and behold, Fluxbox is still going strong. It was the first WM I used way back in 2000-something when I started using Linux full-time. Last time I tried, there were always weird compatibility problems with system tray icons and pagers working properly when running a mix of KDE and Gnome and other apps, but those seem to have cleared up nicely; I have yet to hit any snags. Here's a screenshot.

This took very minimal effort to install and set up. Maybe a couple hours total. I'm using ipager and conky. The wallpaper comes from the UniQ KDE theme. Vim and Emacs themes are my own.

The Fluxbox style is mydefcon_4 from tenr.de which is probably the largest and most thorough set of themes created by one person that I've witnessed. That fellow is motivated.

For all the bells and whistles of KDE4, what features did I actually use regularly?

A menu of apps
Taskbar + System tray + Clock
KWin's good window management.
Global keyboard shortcuts galore
One widget: current CPU/RAM/Network usage
Mouse/keyboard management, background-setting, etc.

Fluxbox gives me all but number 5, and Conky gives me that. Number 6 you can do with xset and feh and such.

And I like being motivated to use keyboard shortcuts for more things. I'm already halfway there. Maybe I can take the plunge eventually and try a tiling window manager. Not sure I've reached that level of nerditude yet though.

And now I can move and resize windows without my graphics card bursting into flames. Maybe when I can afford a few more cores worth of CPU I'll try KDE4 again. Honestly I think I have too much monitor real-estate for my ancient computer to handle smoothly in KDE4.

Not to knock KDE4; it's awesome and I'll probably go back someday. But everyone needs a break now and then.

Emacs Clojure colors

Fri, 30 Oct 2009 19:02:14 -0700

In yet another step along the path of trying to forcibly morph Emacs into Vim, I started a port of my Vim color scheme Gentooish to an Emacs color-theme.

Then I threw a few lines at the bottom of .emacs to highlight a few more Clojure-specific things when in clojure-mode. Result:

This is inspired partly by parenface.el which dims parens so they don't stand out as much. Lispers have this silly meme where they pretend they can't see parens at all, but being a mere human I want Emacs to help blend them into the background a bit.

I want to dim parens but also make braces and brackets pop out a bit more. Coloring braces, brackets and parens slightly differently helps make a few things easier to read in my opinion, especially in ))]}])) kinds of situations (like at the end of the function above).

This is pretty brute-force and I really wish I could figure out how to highlight #{} (sets) differently than {} (hash-maps). Highlighting (), '(), `(), and #() differently would be awesome too. But that is well beyond my elisp skills at the present. Certain areas of Emacs are all but impenetrable, no matter how much documentation I read and how much banging on the keyboard I do. The morass that is font-lock is one of those areas.

p.s. I find an easy way to keep your dotfiles in git is to make a folder (called dotfiles or something) and symlink your dotfiles from there to your home directory. I also put * in .gitignore so git doesn't slurp up anything sensitive by accident.

KDE4 Konsole Kolor Skheme Kdownload

Sun, 12 Apr 2009 20:31:19 -0700

I put a color scheme for KDE4's Konsole up for download. From a cursory glance I think KDE3 and KDE4 color schemes are the same format, but I haven't tried it.

Also I know I'm not the first to say it, but all of the K's in KDE program names are a bit annoying after a while, aren't they?

Vim cterm colors

Sat, 04 Apr 2009 12:48:06 -0700

Note to self. Vim color schemes that only set cterm colors don't work unless you export TERM=xterm-256color in your terminal emulator. Konsole in KDE4 seems to default to plain xterm. Took me a half hour to figure out why my color scheme wasn't working in Konsole.

KDE4 disaster

Sun, 05 Oct 2008 13:49:10 -0700

From reading the bug it sounds like KDE4 is getting close to being ready to hit the tree, which is awesome. Foolishly, I decided to try it early from the overlay last night. It was a total disaster. Things were crashing left and right, panels would resize themselves to be fullscreen (with hilarious results), half of my apps didn't work at all. I found three or four ways to bring down the entire X server. It took me many hours to get KDE3 running again. This is totally to be expected from installing masked packages as I did, so it's my own dumb fault, it was amusing and I wanted to get a taste.

I'm afraid it's going to be inevitably difficult or impossible to migrate cleanly from KDE3 to KDE4. I had the same problem in Kubuntu when I tried a while back. KDE is so huge and so many things link to it or interact with it that it's going to take a year to track down and remove all the cruft after the switch.

I couldn't even import my old KDE3 color schemes or Konsole color schemes into KDE4, which was surprising. QtCurve was un-configurable, dekorator didn't work, and so on. I didn't get far enough to figure out if my preferred icon themes work or not. I didn't realize they broke backwards compatibility to that large an extent, but I maybe it's to be expected.

There were other problems that were seemingly due to the lingering immaturity of KDE4. I can see all the pieces there which are going to allow people to do really neat stuff eventually. In the meantime KDE4 feels horrible.

KDE4 fonts look nice though.

Desktop screenshots

Mon, 01 Sep 2008 13:00:38 -0700

I've been using this theme forever and I'm thinking of changing it, so I wanted to grab some screenshots before I did. I have bandwidth to kill anyways, so enjoy my 3.5 MB PNGs.

My KDE color scheme is here, my QTCurve config is here, my Konsole theme is here, my Vim colors are here, the icons are Buuf, and I uploaded those wallpapers.

I really need to re-upload all the screenshots I took over the past 5 years. That was always one of the more popular sections of the site, for whatever reason.

Vim color scheme: Gentooish

Sat, 10 May 2008 11:49:52 -0700

I look at Vim 7 or 8 hours a day, so it's nice if the colors don't give me a headache. I've used ps_color for years but recently I decided it's a bit too washed-out and it has some quirks that make it hard to read Ruby code. It's hard to find anything else that's any better though. inkpot is good but it's a bit too monochrome for me. I like things to have a very distinct hue rather than rely on saturation or subtle differences.

So I started writing my own color scheme. For some reason that's beyond me, I seem to gravitate toward purple and green. Green is my favorite color, but why purple? I think it might be due to Gentoo brainwashing, so I called this color scheme Gentooish. I've been using it for a week or so and I keep changing things that annoy me, which will probably continue, but it's non-sucky enough to upload at this point probably.

Download gentooish.vim.

I've never written a color scheme before, but it's not difficult. inkpot had nice clean source code so I used that as a basis. ps_color's source is horrific.

Sadly I'm not 100% sure how vim color schemes map to colors in a terminal. Konsole, urxvt, xterm, and a real terminal all show me different colors when using the same color scheme. So I didn't bother with it.

White text? Black text? Cow text?

Mon, 18 Feb 2008 16:13:06 -0800

I took a screenshot of my blog and went into Gimp and did Colors => Invert and thus a new blog layout was born. I also brought back the purple/green one. You can change it via the little skin-selector drop-down thing that's hopefully showing up and working properly for everyone. Skin selection is courtesy of a WP plugin; that site is not in English, but the instructions in the download are, if you want to use it yourself.

Black text on white vs. white text on black... the age-old question. My Vim theme has forever been a black background (ps_color to be specific). Even in broad daylight I find that a black background reduces eye strain considerably. Or maybe it's all in my mind, but then again this is a subjective sort of thing, so whatever's in my mind is all that really matters isn't it?

It's notoriously difficult to use a dark-background GTK/QT theme. Too many programs are written with the assumption that your theme is going to be light backgrounded. However thanks to Kore and a few tweaks here and there I've been getting along pretty well for a few months with a dark theme in KDE. I really need to start posting desktop screenshots more often again. Note to self.

So what's up with the cows? Cows are big, dumb, silly beasts. They can represent strength, or embody vulnerability. They're so disgusting that it somehow wraps around again to awesome.

Are cows really dumb though? Does their silent cud-chewing indicate stupidity, or thoughtfulness? Are cows really silly? Or do we project our own latent silliness onto them? Cows thus embody some of the deepest philosophical questions man has ever dared to ask.

Not really. I've been told by various people that I have the kind of sense of humor where it's impossible to tell whether I'm joking or being serious. Sometimes even I can't tell whether I'm joking or not. I love walking that line. Cows are partly a joke that I never get tired of telling, but also they really do make me smile. Cows are a way to have fun with this website. I view my website almost as a sort of parody of a blog, but a parody I still take seriously in a way. I believe it was Friedrich Nietzsche who said:

If you look long enough into the cow, the cow begins to look back through you.

The internet does not have to be serious business, and I don't want my website (or my opinions) to be taken as seriously as many people seem to want to. My secret hope is that whenever someone comes on here to flame me about my opinions, they'll look up and see a cow in a fedora and say "Wait a second... what am I doing?"

Also Gentoo's mascot is a cow. I estimate that the cows on my website increase its overall performance by 14%.

QT-GTK

Sat, 10 Nov 2007 22:30:34 -0800

For a long time in Gentoo, if I had the "Use my KDE style in GTK applications" option selected in KDE, certain themes would cause all GTK apps to fail to even start. Only certain QT themes did it though. Domino for example, which happens to be my favorite QT app.

I also had some redraw problems with GTK apps no matter what QT theme I used. When changing between virtual desktops, bits and pieces of certain GTK apps wouldn't redraw properly until I moved them around or resized them. And as I mentioned an entry or two ago, I had some lag problems when switching between desktops in general. Nothing show-stopping. Just barely bad enough to annoy me at times.

Strangely, all of those problems seem to have been corrected. Must've been something fixed in the past month. Or maybe something on my system was b0rked and the slew of updates that accumulated over the past month caused me to have to recompile something that fixed it. That included a new version of xorg, tons of KDE apps, a new nvidia driver, and lots of other things, and I upgraded freetype to the latest keyworded version. I wish I knew what it was in particular that fixed things so well. Such are the mysteries of Gentoo.

Dark QT theme = unreadable text fields in web pages

Wed, 26 Sep 2007 12:55:12 -0700

I use a dark QT theme. Many web pages (example: Youtube) have CSS which sets text fields to have black text, but don't set the background color of text fields to be anything. So the background color ends up being my default dark (set by my browser / window manager), but the text in the fields is set by the page's CSS to be black, so I can't read it.

This is incredibly annoying. If sites would either set BOTH the text color and background, or NEITHER the text color nor background, things would be readable. Picking one ends up causing a mess for anyone using a dark theme.

In Firefox to fix this I have to screw around with ~/.mozilla/firefox/$PROFILE.default/chrome/userContent.css and force the font color of all my text fields to be white. This then screws up pages that style their text fields to have white backgrounds, so I have to force my background to be dark for all sites.

input {
    color: white !important;
    background: black !important;
}

However this looks horrible. Largely due to the fact that form elements in Firefox look like Windows 3.1 widgets to begin with.

In Opera on the other hand, I can go to Tools -> Preferences -> Advanced -> Content -> Style Options... -> Enable Styling of Forms and disable all form styling on all web pages. This cause forms to revert back to their default appearance as decided by Opera. In Opera, the default appearance is often set by the theme you're using, so this is actually a nice option and gives nice-looking form widgets. You can also use a custom stylesheet in Opera similarly to Firefox where you can override the colors of form elements using CSS, if you so desire. It's in the same dialog box as the option above.

Any styling that a web page applied to make form widgets fit in better with the rest of the page is gone when do you do this kind of thing, but I'm willing to pay that price.

Wordpress theme download (Cow 1.0)

Sat, 22 Sep 2007 10:34:29 -0700

I put my old Wordpress theme up for download as requested. Enjoy. I think.

Wordpress - Cow

Sat, 22 Sep 2007 10:29:17 -0700

Download Cow 1.0 Wordpress theme.

KMenu

Sun, 15 Jul 2007 11:09:59 -0700

I found an article describing how to tweak how Kicker looks. I wrote about this before but this site includes a few tips the KDE wiki article does not include.

Interestingly you can add some text to your KMenu button:

[KMenu]
ShowText=true
Text=Some Text

That looks hideous, so I don't use it. But you can. I do like making my menu icons bigger, and removing the section titles though. Combined with the Domino KDE theme to give it nice rounded edges and some Buuf icons, I think it looks nice:

Firefox controls are ugly in Linux

Sun, 08 Jul 2007 07:40:05 -0700

This little article gives instructions on how to make your input controls (input fields, buttons, drop-down lists) look nicer in Linux. I tried and it worked pretty well. The buttons end up very slightly rounded, which is better than the GTK1-like crudely-3D blocky things I had otherwise. The colors of the controls changed to match my QT theme too, which is nice.

Layout

Thu, 28 Jun 2007 19:59:04 -0700

I finished my new layout, for some sufficiently small value of "finished". I went really minimalistic with a hint of cow. Lack of cow was the real problem with my last layout.

Screenshots - KDEtastic

Thu, 10 May 2007 10:12:17 -0700

I haven't done much with my GUI for a good long while. I've been more focused on making it functional rather than pretty. I decided to see what I've been missing the the realm of KDE theming. Apparently I've been missing a lot. This Domino theme is on par with anything in Gnome. It's the complete opposite of the bulky, cartoonish look KDE has by default. Very subtle and soft and I think it looks tasty. The rounded menus and slightly 3D text almost make it look like Englightenment.

Dilemmas continued

Sun, 18 Mar 2007 13:13:56 -0700

I previously prattled on about what the right abstraction should be for an icon theme. I said a hierarchy of subclasses would work.

I was very wrong. It didn't work at all. For example I tried to write a == method for my Icon class. With the class structure I was using before, the only thing I could compare between two Icons is the icon name. In which case, two icons of different sizes in different contexts would have to be considered equal. That's not right. The only other option was to make some kind of is_equal? method all the way at the top of the class hierarchy, and have it construct a complete picture of an icon on the fly, and use that in the comparison. That kind of defeats the whole purpose of setting up the class hierarchy that way to begin with.

A better abstraction is a single Icon class with size and context as properties. An icon needs to know these things about itself. I recently was reading Head First Design Patterns and one of the first "rules" it gives is:

Favor composition over inheritance.

It's right in this case. I was tripped up by the fact that on disk a size does contain a context, and a context does contain an icon. But there's no reason my abstraction needs to match that structure.

On a side note, it's a good book, even though it mostly deals with Java. Many of the "design patterns" it gives are workarounds for the inflexibility of Java itself, but it does give some interesting ways of looking at certain problems.

GTK engines on amd64

Sun, 29 Oct 2006 11:20:13 -0800

Today I figured out how to get GTK engines to work on my amd64 machine when using programs like mozilla-firefox-bin which are pre-compiled for x86. By "figured out" of course I mean "read some ebuilds someone else wrote and then modified them to work for themes of my choosing".

Basically you have to find a binary pre-compiled x86 version of the theme and unpack it into /emul/linux/x86/usr/lib/gtk-2.0/2.4.0/engines/. The theme I was after is Rezlooks. Ubuntu seems like a good place to find pre-compiled versions of themes. In fact you can download a .deb for Rezlooks here. (You do have to register at the forums to download the file, which is annoying.) Download and unpack gtk2-engine-rezlooks-0.6-1.deb into /usr/portage/distfiles, then run this ebuild. (Disclaimer: I have no idea what I'm doing. If the ebuild deletes your boot partition and kicks your cat, don't blame me.)

I need to figure out how to set up a chroot to compile things for x86 myself, probably. Another day.

conkyrc

Thu, 26 Oct 2006 19:45:44 -0700

Someone asked me to post my conkyrc so I did. I also posted all the Ruby scripts that I use with it. If you don't mind spawning 6 or 7 Ruby interpreters every couple minutes, you might find them useful, though they are extremely simple.

Buuf 0.1

Sun, 15 Oct 2006 23:07:36 -0700

Release early, release often, right? I put an experimental Buuf KDE icon theme up for download. Go upvote it on KDE-look and I'll give you a cookie*. Or go look in my themes section.

*Cookie offer expires right about.... now.

Gnome <=> KDE icon themes, continued

Sat, 14 Oct 2006 18:22:33 -0700

I've been working on that script to convert Gnome icon themes to KDE icon themes. My first goal is to get Buuf to work.

I came up with a way of doing this. I downloaded the Tango icon theme. To install Tango you have to actually ./configure && make && make install it. Running configure like this:

./configure --enable-png-creation --prefix=~/some_temp_dir

spits out a nicely formed icon theme that follows a standard naming convention, and makes a ton of symlinks so that both KDE and Gnome can find the icons (because neither Gnome nor KDE follow that convention, sadly).

So I wrote a Ruby script that crawled through the Tango directories and recorded all the symlinks that had been created. Then I wrote another Ruby script that crawled through the Buuf Gnome icon theme directories, copied the existing PNGs there to the "standard" locations as recorded from the Tango theme, and then made a bunch of symlinks to those. The result is a theme that appears to cover both KDE AND Gnome apps. See for example my K-menu, where (most) Gnome and KDE apps are properly themed (click for a bigger version):

There are still some bugs to be worked out; I need to have the script dump a properly-formed index.desktop file for example. And I may try to track down a parseable version of the naming convention itself rather than "guessing" at the convention based on the Tango icons, given that the Tango icons may not be fully implementing the naming convention. I also need to test it with other themes, not just Buuf. Once I get those things worked out I'll put an alpha version of the script here so others can (hopefully) use it.

Porting Gnome icon themes to KDE (and vice versa)

Thu, 05 Oct 2006 11:04:02 -0700

I really like the buuf icon theme. But it only exists for Gnome. I want a version for KDE.

A post made by someone on KDE-Apps says:

It is very easy to convert GNOME icon theme to KDE icon theme, because it's the same format ;). Just edit index.theme and change any Statu to Actions, Places to FileSystems and Categories to Applications (remember to include big letters :D).

I tried this, and it failed. It properly themes GTK apps in KDE, but all the KDE apps have blank icons.

It seems like this should not be such a hard problem. The icon theme files of the two DEs are nearly identical. There are probably only a few things that need to be changed to get this working. I could probably even write a script to do the conversion if I knew what exactly needs to be converted. I'm thinking even of getting to the level of sophistication where you could make a mapping of Gnome <=> KDE apps. Like if an icon exists for Rhythmbox, make a copy or symlink called "Amarok" when porting from Gnome to KDE, and vice versa.

This would be a dirty hack to make up for the deficiency (as I see it) that Gnome and KDE apparently haven't completely standardized on an icon theme specification. Or else that themers are not adhering to the standard, if one exists. It looks like both Gnome and KDE are using some variation of the standard listed at freedesktop.org but clearly there are still some differences. This kind of thing I think is one area where it makes no sense to have anything but a single standard. Everyone would benefit. I think we're to the point now (if we weren't already) where lots of people are mixing and matching QT and GTK apps. Gnome and KDE both have "killer" apps which I personally can't do without. K3B and Amarok, and Gaim and Firefox for example. It would make sense to have themes nowadays provide icons for both. If there was a good standard, then the work of making a theme wouldn't necessarily have to be significantly more than it is now, either.

But I think even a dirty hack script to port themes, at this point in time would be really helpful and useful. If I can ever find good documentation about how KDE and Gnome icon themes are laid out, and the differences between them, I might give it a try.

(If anyone knows of such a script that already exists and works, that would be helpful, obviously.)

Opera theme chooser

Sun, 17 Sep 2006 00:48:44 -0700

Previously I blabbered about how writing themes for Firefox sucks.

Now, on a related note: why is the Opera theme browser so much superior to Firefox?

Observe Opera:

In Opera the theme browser opens in a window in the application itself. You browse some themes. You pick one and click Download and it downloads right in the window there. It applies (without restarting the browser, note) and asks if you like it. If you don't, then it reverts back to the original theme.

Changing between already-installed themes involves a SINGLE CLICK in the themes dialog. You click a theme name and it applies instantly. That's it.

Observe Firefox:

When browsing/applying themes, Firefox opens up this window. Clicking the obscure "Get More Themes" text link takes you to an external URL, https://addons.mozilla.org, in my opinion one of the worst-designed theme sites I've ever seen. There, you get to browse through text links of themes on the main page (without thumbnails). Sometimes thumbnails appear on the secondary individual theme pages, and sometimes not; but not a thumbnail in sight on the main page. This means to visually browse themes (judging by, you know, what they look like rather than their name and version number), you have to click about a hundred times on all the theme links.

Once you find a theme you like, you can click the "Install Now" link on that page, in which case a dialog box appears asking if you want to install a theme from this JAR file:

Now, why in the world does it do this? I'm a borderline-OCD computer-programming geek-monster and even I don't give a crap about the URL of the JAR file I'm installing a theme from. One reason for this is that after downloading a theme JAR file, I have no idea what to do with it to get Firefox to import it. It used to be that you had to run a special page with some Javascript triggers that would import a local JAR theme file into Firefox. Then I read that you can drag-and-drop a JAR file into Firefox to install it, but this never worked in Linux and I never tried again. I don't want to screw around with this crap. I want Firefox to load the theme.

Anyways. Clicking OK to install the JAR file makes the theme magically appear in the original (separate) Themes dialog I posted a screenshot of above. And then, to try the theme, you double-click it or click Use Theme, and THEN you have to restart your browser. And if you don't like the theme, you have to restart your browser AGAIN to change the theme back.

Firefox used to let you update your theme without a browser restart. This was years ago, but I remember it. And it never worked right. Sometimes parts of the interface would change and parts wouldn't. And you'd have to restart the browser to fix it (or to discover that the theme just hosed your Firefox profile and you need to wipe it and start fresh).

Firefox got this wrong in pretty much every way. I just tested Firefox Beta2, and other than combining the Themes and Extensions windows into one window, and moving some buttons in the Themes window around, it looks exactly the same. Bad bad bad.

(IE has no themes. So it still sucks worse than both. apply "IE_Sucks" tag)

Firefox theming sucks

Thu, 07 Sep 2006 16:23:47 -0700

Firefox makes me sad. There are many reasons, but if I had to pick one, I'd say theming. Writing a Firefox theme is so ridiculously hard as to be pretty much not worth the effort. I wrote the Lila theme for Firefox a couple years ago. I kept up with it for a few Firefox versions, but there's just no way any sane person would want to continue doing so.

The theme itself is packaged as a jar file, for reasons that are beyond me. Inside this file are XML files which you get to hand-edit. Now, don't confuse Firefox's UUID with your theme's UUID (which you must generate manually in some way). Remember, em:targetApplication.Description.em:id is where YOUR UUID goes!

The whole layout is controlled by CSS. Not just CSS, but CSS with Firefox-specific crap mixed in. These CSS files are scattered randomly through a bunch of directories with helpful names like "browser" and "global" and "communicator". I assume some of these are leftover trash from Netscape, but I have no idea. There are many times you'll find two directories with the same name, and you have little idea which of them you should be using. global/icons or browser/icons? Beats me. Some folders contain image files that look like they were designed for Windows 3.1, which again I assume is some kind of legacy remnant of Netscape.

If you want to change the look of a single component of the display, you're likely required to wade through 4 or 5 levels of cascading CSS files scattered in multiple directories. The partial solution to this is apparently to stick !important on everything, to override everything that came before it. However this too loses its usefulness after the 4th layer of !important's overriding !important's.

$ grep -r '!important' `find lila -iname '*.css'` | wc -l
666

I didn't make that number up. How interesting.

At the time I wrote my theme, there was absolutely no documentation (that I could find) on how to do anything. Basically you were expected to wade through a couple hundred threads at MozillaZine or something. In practice what everyone did was grab someone else's theme as use it as a default, because otherwise you have no chance. (Clearly someone, somewhere came up with the FIRST theme, from which all others are derived. My theory is that this original theme was introduced into human society by extra-terrestrials or some kind of god-figure.)

The hoops you have to go through to test a theme while working on it is ridiculous. The normal theme install procedure for Firefox was designed by someone with a severe masochistic streak. Where is the Lila theme installed on your computer? If you guessed ~/.mozilla/firefox/01yf2p25.default/extensions/{9957f6c1-021d-4cbf-9462-26a0c1921fe4}/chrome, you're right! But that's just the location of your theme's jar file. If you want Firefox to read it in non-jar format, it's possible, but the method of setting it up can only be called black magic. But without doing this, seeing the result of making any change in your theme requires 5 minutes of fumbling.

Is there a difference between themes for Linux, OS X, and Windows? Clearly so, because those things are specified on the specs for each theme on the Firefox site. What exactly those changes are, or how to resolve them, I would not want to begin to guess.

The best thing is that every Firefox release completely breaks old themes. Even today at MozillaZine we have a 16 page thread about changes from 1.5 to 2.0. And there's already an 8 page thread about changes from 1.5 to 3.0 (God help us all).

Someone apparently updated my Lila theme for version 1.5 at the official Lila page. I installed it, and big surprise, it's broken. The RSS/secure connection icons in the toolbar are totally trashed in the layout. Menus have random highlighting problems. Etc. And here comes Firefox 2.0! Time to rewrite it again! Big chance this theme won't even install in version 2.0, let alone look correct. Nothing at all against whoever updated this theme; I tried to update my old one for version 1.5 myself and I just gave up. Not worth it.

Compiz screenshots

Mon, 07 Aug 2006 11:14:33 -0700

There are plenty of nice Compiz themes at compiz.net. Here's Milk, which I've always liked. KDE + Compiz is just too nice:

Since taking these screenshots, I've started using dual monitors. There's a good FAQ on the Gentoo Wiki about setting up TwinView. It honestly couldn't be easier. I don't know how I got along with only one monitor before now. It's so much nicer with two.

The only bad thing about TwinView is that you can't specify which screen is your "main" screen. As seen in this thread, this is a limitation of the nvidia drivers. Kind of sucks, but KDE's support for dual screens makes up for nvidia's lack. You can force Kicker to be on one or the other screen or both; you can set wallpaper for each independently; etc. Full-screening most apps works fine. It all works perfectly fine with XGL/Compiz too.

Linux has come so far in the past 5 or 6 years. It's really quite amazing.