GNOME – Patryk Zawadzki

The GtkSwitch problem

it’s amazing that people find the on/off switch *that* confusing. I wonder how do they turn on and off the lights in their houses @ebassi

Dear GNOME designers,

When you came up with the original idea of GtkSwitch (or looked at iOS and thought “ooh, shiny”, I don’t blame you), you overlooked the problem of localization. Just as today’s kids have no idea what a floppy is, most of us, Europeans, have no idea what device this widget represents and how it is supposed to work.

What you see:

What you think:

Light switch in the bathroom by anotherpioneer, on Flickr (cc) BY-NC

What you really think: a freakin’ light switch!

For reference, here’s a light switch we use in Europe:

240720081083 by jakub.szestowicki, on Flickr (cc) BY-SA

Pressing the top turns the lights on, pressing the bottom turns them off. The ends are unlabelled.

The only device that I could find that matches GNOME’s current behavior for the GtkSwitch is the voltage switch on a PSU. See the red part. You slide it with a flat screwdriver to tell the PSU if the input voltage is 115V or 230V (which, again, is a standard here in Europe):

Power-Supply-noswitch by Kevin Byrom, on Flickr (cc) BY-SA

Update: apparently none of this is true¹ and the widget is perfect. Therefore I stand corrected. Hats off then and bonus points for the humor in the implementation. “How do I turn it OFF?” “It’s easy, just click and drag it all the way to where it says ON.”

¹ As proved by @ebassi: one, two, three.

Procedural wallpapers?

Here’s an idea for GNOME 3.x. Instead of showing a static wallpaper, start treating the wallpaper as an infinite plane. Basically instead of using a JPEG or PNG file as input, build a library that given a rectangle returns the image data (raster or even better vector) corresponding to the surface it covers. As monitors and workspaces come and go, the shell can expand and contract the background, calling the library as needed to build the missing parts.

The possibilities are endless. The easiest implementation is an infinitely tiled texture. Another could be a photo wall with randomly rotated and scaled faux-polaroid versions of your Pictures. Or take pre-defined sets of vector cliparts as input. Whatever is visually pleasant and results in a background unique enough to give subtle hints as to the current position on the plane. By “learning” the wallpaper, the user will subconsciously know where he is and where his windows are.

Add parallax scrolling. When switching to the next workspace, only scroll the wallpaper by a fraction of the size of the workspace. Say 50%. This will add to the perception of depth (wallpaper being non-interactive) while the uniqueness of procedurally generated workspace will give hints about both the current position in the workspace stack and the contents of the adjacent workspaces (as they share parts of the background with the current one).

Profit?

Ambient music daemon?

Disclaimer: before you call me a freak, keep in mind I do know none of this is possible. At least not now and not without hacking half of the desktop. Nonetheless it was an awesome dream.

That’s right, I’m blogging about my dream from last night. Seriously. And it sure was an awesome dream too!

Imagine a daemon playing a number of tracks in perfect sync. Think old trackers here (ah, the times of .MOD, .S3M, .IT, .XM etc.) with — say — 8 tracks, all muted for now.

Now teach the little daemon in your head how to track window focus. Have it know if you’re editing a file or if you’re doing voodoo in your terminal. Make it whistle different tracks depending on what is happening at the moment. What I mean is make it slowly fade the current track into the next one.

Now teach your little pet how to track long running background tasks. Make it whistle an additional tune while you’re burning a CD, compiling a kernel or downloading a large file. So if you have a long lasting operation, you have 2 tracks playing at the same time.

Now add notification icons. Say having a non-dismissed notification adds an additional track that slowly fades in when the first icon appears and slowly fades out as the last icon goes.

Like it? I thought it was an awesome dream. And an awesome idea too. Sort of how LittleBigPlanet’s dynamic music tracks work.

Dear Santa,

What I want for Christmas is simple:

an awesome Python completion module for gedit.

KTHXBAI

How to determine the first day of week

Today we got a report for bug #554256 in Hamster. The first day of week was reported as Sunday for some locales that certainly used Monday. I did some research and found that before Hamster relied on a simple check to determine the result:

Run locale first_weekday (by the way, we have to use os.popen here as these don’t seem to be accessible from Python)
If the result is 1, use Sunday, else use Monday (literally, it would treat 2 and 6 as Monday)

That seemed to work at least for some countries but was wrong which became apparent when more people started using Hamster (and to put myself in shame: I didn’t notice this before but it was also broken for me). It seems the correct version is:

Run locale first_weekday week-1stday
Parse week-1stday as date with %Y%m%d
Move the result first_weekday - 1 days forward
Check the weekday of the result

Rationale:

While locale manual pages are horribly outdated, all web searches point to week-1stday as the beginning of the first week of tracked Unix time. first_weekday is the 1-based offset of that week’s start day. It seems it’s only there so you can specify first_weekday=2 and first_workday=1 for the rare cases where working days span across two weeks.

Please do correct me if this is wrong as all of the above are assumptions based on glibc code and Google results. Hope the above helps someone in the future.

Update: vuntz was kind enough to point me to gtkcalendar.c, part of GTK+. It does the same thing described above so it seems the method is correct.

Happy hamsters

Project Hamster is now part of GNOME! Along with Empathy and some blessed external dependencies. Do not underestimate them however for they are some truly powerful libs including libcanberra, Clutter, Conduit and PolicyKit.

Some new pains are now (temporarily) part of my life. As PH’s father, Toms, is away I am the one responsible for the SVN migration, releasing 2.23.6 and cooperating with i18n and a11y teams. I think we should start by making the stats accessible but I’ll concentrate on moving to GNOME infrastructure for now. Hope the rest of the team gets their SVN accounts up and running soon.

As for Empathy, great stuff. If you like it as much as I do, you can help me convince Xavier to make it a bit prettier and more readable. Hooray for lobbying!

Edit: hamster-applet 2.23.6 is out, following the upcoming GNOME 2.23.6 release.

Improved one canvas workflow

Jimmac’s post got me thinking. His script did the job for a single icon. Why not improve upon it to allow multiple icons sharing a single SVG file? Immediately decided to give it a go and after a few iterations the result works as follows:

You start by creating a template SVG.
For each icon (not size) you create a layer ~~and set its name to context/icon-name. You can use a different syntax but it has to contain at least one slash. The rest of the layers are treated as drawing aids~~.
For each layer you create a sublayer and give it a name starting with plate. Inkscape requires you to have distinct layer labels so a simple plate won’t do for multiple icons but you are free to use names such as plate for foo.
The plate consists of a set of rectangles. Each rectangle will result in a separate PNG and the size is taken verbatim from the rectangles (so make sure you don’t end up with ten decimal places in width or height).
The plate also needs two text objects: one with label set to context and one with label set to icon-name. The text you put there is used to create the directory structure.
Save your template to a directory called svg. Make sure you hide the plate layers before saving.
Download the Split Icons script.
Run the script. If you pass a path (or several paths), it will only process the files from the command line. If you don’t pass anything, it will process the whole svg directory.
Draw art!

Here’s a template example.

PS: b.g.o upload sucks. It will only accept .gz files and then will strip the dot from the original extension.

Update: updated the script to handle the new format invented by jimmac. See the example above for details.

To git or not to git

These days most of the buzz is around choosing an appropriate DVCS for GNOME. Like, dude, what the hell?

It’s not like we’re choosing between CVS and SVN where one is the other plus cool features minus broken design. Today we should concentrate on using the most widely adopted DVCS, not on one with the cutest syntax. Features across the board are actually pretty much the same, the rest is just sugar coating.

Just take git and wrap it, add plugins, make it look like Bizarre or Peculiar. We certainly don’t want to tell new contributors to download and build 20+ source control tools just to build a single GNOME app from trunk. I can tell you for sure most of the devs want to get stuff done and they don’t give a poo about repository storage formats. We want to be able to easily commit changes and generate diffs, having a bunch of PostIt notes with various DVCS incantations is far from desired.

A good example of a bad trend

To add an example to my last note, here’s what happened recently.

One user posted the following:

I’ve noticed FOO desktop is no longer able to mount removable drives. I get the following:
org.freedesktop.hal.storage.mount-removable no <-- (action, result )
What do I do?

And here’s the proposed solution:

Just edit /etc/PolicyKit/PolicyKit.conf and add the following part:
<match action="org.freedesktop.hal.*">
<return result="yes"/>
</match>

And they lived happily ever after, right? Wrong. This is a great example of why asking the uneducated crowd to help you solve technical challenges is the best way to shoot yourself in the foot.

I doesn’t take rocket surgery to figure out that PolicyKit won’t allow certain actions to be accessed by certain users. In this case it only allows active local sessions to mount removable volumes. What constitutes an active local session? A session logged in locally (which is the case) and connected to ConsoleKit (which is not the case since FOO desktop environment does not seem to use ConsoleKit).

Now if the user asked in the proper place (file a bug or send the question to the proper mailing list) instead of the forums there would be two good answers:

Teach FOO desktop how to register itself with ConsoleKit (by fixing the code or using means of pam_consolekit)
Tell PolicyKit to allow certain users to access the action (polkit-auth --user foo --grant org.freedesktop.hal.storage.mount-removable)

Now do you see the problem? The original thread in a more illustrative form: if my aunt comes to visit and she does not have the keys, how does she come in? Oh, that’s easy, just remove the locks.

Why forums are a bad way to help the community

Many people point to places like Ubuntu forums or Fedora forums or insert-your-distro-here resources as an example of how great Linux support is. It goes like this: if you have a problem just go and ask other people, wait for their replies and assemble the arcane scripting languages to publish a definitive HOWTO. This way if something doesn’t work you have a high chance of finding a thread or two with all the necessary scripts and workarounds. Great, huh? That’s where people fail.

Having a usable desktop system is all about having stuff working out of the box, not about being able to find a good enough workarounds. The latter often add to the confusion and FUD by offering the right console incantation backed up by technical descriptions that are utterly wrong. If you have a problem, file a bug. If something does not work, file a bug. If you see a ghost, call Ghost Busters. Filing bugs means fixing stuff at the proper place and by people with the right knowledge.

If you are afraid to file bugs upstream (where the software authors live), file them in your distro’s bug tracker. Nice developers should be able to forward it to the right place (and Launchpad makes it so much easier by allowing one to track upstream bugs). Just file it. Sure, do check if the exact same bug was reported earlier, do check if you have the latest packages available. But when everything else fails, file a bug. The worst it can get is that some developer will close it as already fixed or ask you for further details.

There’s no other way the developers know about your problems. It’s not like they spend 12 hours a day reading various forums and looking for problems to solve. In other words: if you don’t file a bug you have absolutely no right to complain about how your issue was not solved in the latest release. Be it Linux, GNOME or Windows, we can’t fix stuff unless someone tells us it’s broken.

PS: blog posts are no better than forums.

Edit: I certainly didn’t mean to ditch GIMP HOWTOs and other resources showing you how to use the tools effectively. The point is HOWTOs are not the proper way to get the stuff working as intended.