briancarper.net (λ) (Tag: Gnome)

KDE rules

Thu, 07 Feb 2008 22:42:21 -0800

A few short years ago the majority of apps I used were GTK2 apps. I alternated between Gnome and/or XFCE4 regularly. Compiz and Beryl came out and they were all gconf'd and whatnot so it was more Gnome. There was Gaim, Firefox, I think Thunar for file management, Gvim, GIMP, and so on.

It's strange when you're so immersed in your own world that you almost forget that another world exists. I kind of had in the back of my mind that KDE was probably dying out there somewhere and that all the KDE apps were just clunky crappy versions of GTK apps. This is what happens when you go a long time without using them. Eventually I gave KDE another try around a year or so ago, and I haven't looked back. I've mentioned before some of the reasons I like KDE. (The window manager in KDE actually manages windows, for one thing.)

Today I found another reason. Interestingly, lately more and more GTK apps I thought were indispensable are being sniped by QT apps. Not KDE4 apps either, I haven't installed KDE4 and don't plan to for a long while. Just old mature QT3 apps. Today on a whim I tried Kopete and much to my surprise I find that it's a nice alternative to Pidgin. Last time I tried it years ago it was really not a lot of fun to use, but it seems to have matured. It's a lot more customizable in look and feel than Pidgin, almost Adium-like.

Lately also I've taken to using Akregator for RSS feeds, and again, I'm largely impressed. It sits in the taskbar unobtrusively, and overlays a number on its icon indicating how many new feeds there are. You can then view them in what appears to be an embedded Konqueror tab, or in an external browser, depending if you left-click or middle-click. Embedded view works fine for the things I RSS for (webcomics and geek blogs).

I've even given up urxvt, which I'd used for many many years, for Konsole. KDE apps tend to be loaded with features, but also tend to be loaded with ways to disable all of those features and keep the one or two you actually want. Konsole is a good example of that. You could barely tell that my Konsole window isn't a lightweight terminal, until you right clicked it and got a billion options. No menubar, no statusbar, no tabs, no scrollbar if I don't want one (but I do). And under the hood you have sane font selection dialogs rather than screwy xft:strings:of:crap or -*-*-*-*-font-*-*-**-*specs-**-- no one can read. You can turn on/off visible or audible bell via a menu selection. You can save/load color schemes rather than waste endless amounts of time hacking of .Xdefaults. You have session management, pre-set standard row/col sizes, selectable word boundaries for double-click-highlight, etc. etc. etc. All those features only if you want them, otherwise go ahead and pretend they don't exist. It has everything you could want and more, yet it runs just as fast (on my machine) as any other terminal, and it looks identical.

Same for Kopete actually. My Kopete contact list has no toolbar, no menubar, no statusbar, nothing but a window frame with people's contact icons in it. And you have four or five different ways to display those icons. KDE somehow has some reputation for being bloated or having a bloated interface, but I find just the opposite. It has an interface you can make exactly as bloated or non-bloated as you want at any given moment.

Had I not blindly tried KDE one day I would never have realized how nice it all was nowadays. Sadly this train of thought leads me to the conclusion that I should blindly try Gnome again sometime soon. How depressing.

Once someone ports Firefox to QT and revives Kvim I'll be set. I'm sure that'll happen. Any day now. May as well start holding my breath.

KDE 3.5

Thu, 22 Nov 2007 03:10:53 -0800

What with all the news about the release of the first KDE 4.0 release candidate, I realized I've been using KDE 3.5 for quite some number of months now. This is quite a feat given how often I used to bounce between window managers in the past. I believe I first used KDE when it was 2.something; I'm pretty sure it was the first window manager I ever used when I started playing with Linux. Since then I've given substantial time to Gnome (obviously), XFCE4, FVWM2, Openbox, and Fluxbox. Last time I stuck with one WM this long was probably back with FVWM2.

I really can't complain about KDE nowadays. KDE has just about everything you could want in terms of options. Kwin as a window manager is suprisingly powerful; I'd say possibly second only to FVWM for my needs in terms of configurability, per-application settings and whatnot. Metacity is total trash in that regard.

There's a funny quote on Wikipedia from the author of Metacity:

Metacity's focus is on simplicity and usability rather than novelties or gimmicks. Its author has characterized it as a "Boring window manager for the adult in you. Many window managers are like Marshmallow Froot Loops; Metacity is like Cheerios."

That rings true. So KDE has that going for it. Also in spite of all the claims of bloat, KDE feels very responsive and snappy to me. QT-based apps always seem more responsive than GTK apps even when I was a heavy Gnome user. Whether they actually are more responsive, or just seem to be, doesn't matter to me; my perception is all that matters in this case. Many of the apps that come with KDE are really high-quality too. Amarok obviously, but also ktorrent which has been my bittorrent client for a while now. And both Konq and Dolphin are top-notch file managers. Then there's K3B and so on.

In spite of all the KDE4 news, I'm not really sure what it brings to the table that's much different than KDE3. I know there are some new gui toolkits etc. that will make it look prettier. At least I hope that's true. Most of the KDE themes in the world right now are pretty darned ugly compared to Gnome themes, in my estimation; that's the one thing Gnome has going for it. I like muted, minimalistic themes. KDE is always big and round and flashy. I hope someone with some good artistic sense can take advantage of KDE4. The screenshots I've seen of the default theme look horrendous, but then again this is just a release candidate, and most default themes for most window managers / desktop environments do, I guess.

I'm really waiting to see what KDE4 is going to offer in terms of usability, which is KDE's big strength to me. The worst thing that can happen is if KDE takes a step BACKWARDS in usability, to try to move forwards in eye-candy. KDE 3.5 is so wonderfully mature and feature-rich at this point, I'd be amazed if KDE4 can match it right away, unless they were able to reuse a lot of KDE 3.5 components in KDE 4.

Time will tell. In the meantime I'm very happy with KDE right now.

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.

Programming dilemmas

Mon, 12 Mar 2007 23:09:28 -0700

I scrapped the throw-away version of the KDE <=> Gnome theme converter script which I started many months ago, and started over. I'm trying to do it "right" this time.

It looks like the same index.theme files (if properly written) can be read by Gnome and KDE both, which is nice. I found this handy index.theme specification which should help. Assuming Gnome and KDE implement the spec correctly.

One thing I tend to struggle with is the "big picture". I'm good at getting the details right (or if not right, at least working), but organizing all the bits into a comprehensive, clean whole is something I have trouble getting my head wrapped around at times. Ruby is a nice Object Oriented (tm) language, and that helps a bit with organizing code, assuming a problem maps nicely onto OO-space. But it's oh so very easy to write bad OO code too. Dumping sucky code into a bunch of classes doesn't make the sucky code suck any less.

I think this program is a good exercise in properly abstracting a problem. At the top level is the Theme, which contains Contexts ("applications", "filesystem", etc.), which contain Icons. Probably I need a Size abstraction in there too, each of which contains many Contexts, because each Context can be listed under multiple sizes.

So the end target in all this is really just a bunch of filenames. Now, where should those be put in this abstraction? Do I let the Icons manage and deal with their own absolute pathnames? Or the Contexts? Or the Theme? Or a higher level? Taking a step back, it seems that a relative base directory, "ThemeName", is intrinsic to a Theme, but an absolute pathname, "/home/user/some/dir/ThemeName" isn't; rather the absolute name is part of an operation you do on a theme: "export yourself into this directory". Likewise a Context has (is) a directory name ("applications") and possibly shouldn't care which Theme it's a part of, and an Icon has a filename ("icon.png") and seemingly shouldn't care which Context it lives in.

But the more I think about it, should an Icon know more? Should an Icon know exactly what absolute path on the filesystem it maps to? If not, there needs to be some mechanism to convert Icons into absolute pathnames, somewhere along the line. Where should that go? Should I just crawl down the tree top to bottom, Theme -> Sizes -> Contexts -> Icons, and have it return the pathname that way by building it out of parts? Seems cleaner conceptually, but it's so darned expedient to give the absolute pathname to every object. I think I tend to err on the side of expediency, usually to ill effect, so I'm going to try the other, "proper" way this time and we'll see how it goes.

I also need the ability to sort and search Icons by size; that seems trivial if I have a Size abstraction. And I need the ability to search for Icons by name; seems like a good place to use hash lookups. But I see other possible choices that could work too. Then I just write a tool that takes two Theme abstractions, matches the abstractions in some way, and maps the conversion to real file operations. And some tools to read index.theme files and build Themes from them, and some tools to take a Theme and write out an index.theme file. Seems easily doable. All of these little design questions are the kind of thing that I tend to get hung up (i.e. tripped up) on. It's good exercise at least. I learn a little every time I go through this kind of thing.

KDE 4

Sat, 03 Mar 2007 11:26:46 -0800

I bounce back and forth from Gnome to KDE very regularly; I'm not really the kind of person who views this as a religious argument. What's the point of having so much delicious choice in Linux if you don't take advantage? Over the years I've given lenghty tries to openbox, fluxbox, xfce4, and fvwm too. I honestly enjoy them all; they all have their strengths and weaknesses.

Right now I'm in Gnome country, and I'm starting to get tired of it. I'm rather excited about KDE 4. Apparently it will have new icons, which is great because Crystal makes my eyes bleed. And they have a new file manager Dolphin which is also great. There was very recently a news item explaining some of the motivation behind Dolphin and how it will differ from Konqueror (along with some tasty screenshots).

In my opinion, Konqueror is a great program except for the horrible clutter. It tries to do way too much. It tries to be an image previewer and isn't as good as a standalone program (feh?). Anything that opens PDFs inline quickly earns my undying hatred. A file manager also being a web browser strikes me as one of the most horrible ideas I can think of at the moment; I'd guess the only reason it was even considered in KDE is to copy what Windows does. Aside from being able to "browse" files and HTML pages both (in completely separate ways, note) the two tasks have nothing in common and should remain well separated, and happily the news item above agrees with me. On the other hand, I enjoy FTP support (and other remote file managing support) in Konq, because browsing remote files and browsing local files are exactly the same task; happily Dolphin will retain that feature.

Gnome is a nice environment, but Nautilus bugs the living crap out of me for whatever reason. Can't quite put my finger on it, but I detest trying to browse files in Nautilus to the point where I go out of my way to avoid it.

December screenshot

Mon, 04 Dec 2006 19:11:55 -0800

Haven't posted one in a while. Gnome + Beryl, Buuf icons, MurrinaNeoGraphite GTK theme. I caught a window in mid-closing-animation, but I thought it looked neat so I left it.

Stupid X errors

Sun, 12 Nov 2006 23:09:28 -0800

I tried out this new xeffects overlay. Apparently it comes with some patched kdelibs ebuilds. These things cause massive system breakage for me. Trying to start X and KDE fails with some kind of fatal IO error code 104. This is such a hard bug to figure out. It leaves no clue as to what's causing it. After a good half hour of screwing around with installing different version of nvidia-drivers and re-installing Xorg, I thankfully remembered that this same exact thing happened to me before. I'm hoping that rm -rfing the xeffects kde-related ebuilds and re-installing kdelibs is going to fix this.

This is the good thing about keeping a bare-minimum Gnome installed as a backup. However, ew. Gnome feels icky. I remember why I ditched it.

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.

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.

SSH security woes

Wed, 11 Oct 2006 12:21:27 -0700

I checked my /var/log/messages recently and it turns out my SSH server on my home machine is being hammered with login attempts. I suppose that's pretty common and it's probably just a bunch of bots. I carefully grepped through my logs and none of the login attempts were successful (so far as I can tell), which is good. One IP tried the following usernames one after the other:

staff sales recruit alias office samba tomcat webadmin spam virus cyrus oracle michael ftp test webmaster paul guest admin linux user david web apache pgsql info tony core newsletter named visitor ftpuser username administrator library test admin guest master admin admin admin admin test test webmaster username user admin test danny alex brett mike alan data www-data http httpd pop backup info shop sales web www wwwrun adam stephen richard george john angel pgsql ident webpop susan sunny steven ssh search sara robert richard party amanda rpm sgi users admins admins dean unknown securityagent tokend windowserver appowner xgridagent agent xgridcontroller jabber amavisd clamav appserver mailman cyrusimap qtss eppc telnetd identd gnats jeff irc list eleve proxy sys zzz frank dan james snort radiomail harrypotter divine popa3d aptproxy desktop workshop mailnull nfsnobody rpcuser rpc gopher

Are there really that many people in the world using "harrypotter" as their usernames? Other common login attempts seem to be for usernames "admin" and "oracle".

I've started taking SSH security more seriously since then. I limited the number of login attempts you can make before it blocks you. I made sure root login in SSH is disabled entirely. And I have SSH listening on a non-standard port. That last one is "security though obscurity", sure, but it seems to defeat bots. I've had 0 login attempts at all since I've moved to a different port. I've had a lot of garbage connection attempts, but those are apparently bots looking for a different service since they don't provide any identification at all. My next step is probably limiting login to using a key file I'll carry around with me on a flash drive, if I can figure out how to get that working.

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.)

Gentoo fun

Mon, 11 Sep 2006 18:55:04 -0700

My upgrade to GCC 4.1 went perfectly well. But I think perhaps only because I've learned lessons in the past when things have gone terribly wrong. Such as, don't forget to recompile your kernel. And don't reboot before you emerge -e system.

Before I upgraded GCC, I tried to install Gnome 2.16. Horrible, horrible breakage. gnome-panel would no longer start. I tried to downgrade back to 2.14 and it broke even worse. control-center refused to compile at all, which means /usr/libexec/gnome-settings-daemon was missing, which means no GTK themes in KDE.

But since I knew I was going to have to emerge -e world after upgrading GCC anyways, I figured no better time to try something like that. Just remember that; any time there's a major system upgrade that will require a total recompile of all your packages, that's the time to start trying crazy experimental hard-masked alpha desktop environments. : )