the (un)real thoughts of realbt

Doing some work on quizmeBC over the last week or so, and I ran into a particularly annoying form bug in Mozilla/Gecko browsers. It seems that if form elements are place inside and outside of a table, it will cause Mozilla to refresh the form’s state incorrectly upon reload or browsing back in history. In my particular situation, each selected radio button would move up one option in the radio group upon every refresh, until nothing was select any longer.

The fix was to move a hidden form element that existed outside of the table into the table. This stopped this weird and very annoying behaviour. It was certainly hard to figure out, and a little tricky to find on Bugzilla too.

When I switched to Linux, the first thing I did was play around with the various desktop environments Linux has to offer. Many exist, but KDE and Gnome stood apart from the others as they were much more than just window managers — but full graphical shells with standard native applications like text editors and such.

I started with Gnome. I liked Gnome because the PIM suite I was using at
the time (Evolution) was
written using GTK for Gnome (though, of course, it will run under KDE as well). It was also relatively fast and widely used. The biggest problem I had with Gnome/GTK applications was that they weren’t pretty. And while I have never been one to talk much about GUI vanity, I did find myself becoming increasingly more frustrated with Gnome’s lack of common look and feel, something I later found KDE excelled at.

Take for example the standard GTK file selector. It was plain, and quite ugly. It was not quick to navigate by any means. And it wasn’t terribly intuitive (especially for a former Windows user, and I don’t just mean myself).

KDE, as I noted, has a vast look and feel movement. Applications written for KDE (using the Qt GUI libraries) generally feel the same. Whatever they’re doing — they’re doing something right. Maybe there’s a few things that could be made easier, simpler, or whatever. One of the biggest complaints people make about KDE is that it’s bloated.

Though I’m very unlikely to switch to Gnome from KDE, I’m still glad to see that there is being some development on the GTK+ libraries. There are a variety of mock-ups of what the new file selector dialog should look like in a recent OSNews article.

And of course, the file selector is but a mere example of widgets and dialogues/selectors that could do with some improvement in GTK/Gnome.

Why does this matter so much to me?

While I don’t use Gnome, I still use some GTK applications. GIMP is a great example. While I wish there was a KDE/Qt-based port of GIMP, there isn’t, so I’m forced to use the standard GTK version. Another is XMMS, a relatively good mp3 player for Linux. The only reason that these two applications have succeeded with me is the quality and function of the application itself. There are few
things that I like about their user interfaces (of course, XMMS is skinable, so that helps a bit), and there are even fewer things in common between their user interfaces, despite both using GTK. Two applications using Qt will look and feel the same to me. But two applications with GTK? About the only thing that stands out in my mind is the ugliness of the widgets.

So here’s to hoping for success of GTK+.

Wow, you should see my super amazing, unbelievable, “Brett you are so cool”, “you work too hard”, “what did you do on Canada Day?”, my back hurts, my eyes are sore, I’m-even-impressed-with-myself progress on picGo. Of course, you can’t actually *see* it yet since it’s still under (and on) the development server (ie., my home computer), though I will hopefully soon be moving it to verification (ie., a secondary account on the web server in which the production picgo.com exists).

Tonight I tweaked the database structure a little to make room for some improvements I’ve decided to include in this version rather than wait until later — improvements which include threaded comments and notifications (more on this feature later). I’m also breaking down some handy functions into a utility class rather than having everything stand-alone. I rather like this idea. I also tested the migration script I wrote (a bunch of insert … select sql statements) to see if everything will work as it should without the album owner’s having to tweak their galleries — and everything looks great.

On Canada Day I re-designed the management interface and gave it a whole new look (now red, rather than green). I started the import wizard (which I also worked on tonight) and nailed down the actual process. I find that thinking through the algorithm before writing it is so much better than just sitting down and coding and changing your mind 5 times during the process. Yes, I’m being fascetious — obviously it’s better to do this, and it’s not something I “find” — it’s something I just “know”. The problem is that despite “knowing” this, I often “find” myself doing just the opposite and writing heaps of code only to realise it’s not very useful …

I’m also planning on implementing, at some time or another, something to allow you to do some live modifications to photos: re-generate thumbnails, replace photos (say you needed to touch something up …), rotate, etc. I seriously think this will come later, though.

The new picGo (that I’m calling version 0.5; the one in production is 0.2) has a total of 8 database tables, whereas the old one only had 5.

Once I finish the management interface, I’m going to move back over to working on the end-user gallery (which is looking quite pretty, if I say so myself) and continue working on a new “skin” (ie., stylesheet).

I hope to have 0.5 in production before the end of July when I go on holiday. That would be nice. Even if there are a few bugs to iron out, it’ll still be more stable than the current version.