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

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.

Seriously, WTF is the blue bar? The ugliest tabs ever. And where did the action box go? Now you can probably get used to it but here comes the beta:

Guys, the 1995 is calling and wants to have its sites back. WTF? It’s not only ugly, what the hell happened to all the navigation? Hope it never makes it into production. Please, I can has the green Launchpad? Kthxbye.

1. You start by creating a template SVG.
2. 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.
3. 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.
4. 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).
5. 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.
6. Save your template to a directory called svg. Make sure you hide the plate layers before saving.
7. Download the Split Icons script.
8. 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.
9. 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.

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.

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.

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.

• Integrate videoscale with pitivi’s wonderful smartvideoscale element. The main difference is that the latter keeps the aspect ration untouched by adding black stripes to the appropriate sides when scaling. The logic here is pretty straightforward so any gstreamer hacker should be able to merge these two (smartvideoscale uses videoscale internally and is implemented in Python).
• Implement an encodebin element to allow applications to use pre-defined profiles for encoding. See below for details

The encodebin proposal

The way I see encodebin would make the element itself pretty simple. To make it useful, it should try to stay profile-agnostic and all specific details should be part of the profiles. Provided that queue can handle multiple streams, the profiles themselves could be as simple as that:

[gstreamer-profile]
Name=PlayStation 3 console
Name[pl]=Konsola PlayStation 3
Type=device
Icon=computer-gaming-sony-ps3
Pipeline="queue name=input input. ! ffmpegcolorspace ! x264enc ! queue ! output. input. ! queue ! audioconvert ! faac ! queue ! output. queue name=output"

The element itself would only have to enumerate the profiles and use the one indicated by the profile property. Placing the profiles in a common %_datadir location would allow external packages to add profiles for both common container formats and for specific devices (gaming consoles that only handle certain formats, mobile devices that require lower resolutions etc.).

Ideally the encodebin element should accept video, audio and subtitle streams (as choosing a font size requires you to know the output resolution). This would allow one to build a re-muxing application while focusing on the GUI and not on all the devices to support.

All comments welcome. Disclaimer: I am certainly not a gstreamer hacker so I don’t know poo about gstreamer’s internals. Please be kind.

gst-launch filesrc location=test.txt ! \
subparse subtitle-encoding=cp1250 ! subs. \
filesrc location=test.avi ! \
decodebin name=demuxer \
demuxer. ! queue ! ffmpegcolorspace ! \
textoverlay name=subs font-desc="Sans Bold 20" ! \
ffmpegcolorspace ! x264enc ! queue ! muxer. \
demuxer. ! queue ! audioconvert ! faac ! queue ! muxer. \
ffmux_mp4 name=muxer ! \
filesink location=output.mp4

It loos complicated but it’s not. It basically works like this:

1. filesrc opens test.txt
2. subparse decodes the file as one of the supported subtitle formats and sets fallbac encoding to cp1250 (unfortunately one of the most popular encodings used for subtitles in Poland)
3. another filesrc opens test.avi
4. decodebin detects the container format used, demuxes it and decodes the audio and video streams inside
5. the video stream gets passed to textoverlay which takes the subtitle stream decoded earlier and overlays it in the Sans Bold 20 font
6. x264enc takes the resulting video stream from and encodes it into the H264 format used by PS3
7. faac takes the audio stream and encodes it to the AAC format used by PS3
8. ffmux_mp4 takes both audio and video from the earlier elements and muxes it into the mp4 format
9. filesink writes the results back to disk

Unfortunately it turns out the mp4 muxer does not work as intended. Either that or all the sound encoders are broken. The resulting file plays fine in mplayer but any attempt to use it with gstreamer gives you smooth video with broken audio (one sample per half a second). Playing it bac on the PS3 is impossible as it claims the file is simply corrupt.

Then I thought well, I can still use xvid, right? Wrong. xvidenc + lame + avimux = broken file. Again, mplayer plays the video without any sound, gstreamer just hangs on the first frame. This time I’m pretty sure it’s my fault but I have no idea what params to pass to the encoders and the muxer. Even the avimux example from the gstreamer docs results in an unplayable file on my machine.

Simple idea: how about creating a encodebin element to mimick the decodebin behavior? It could work like this:

audiotestsrc ! encoder. \
videotestsrc ! encoder. \
encodebin name=encoder profile=ogg ! \
filesink location=output.ogm

The new GUI rocks and the experience is great including all the little animation bits here and there. Hooah to the Banshee team. The Rhythmbox community has a new target to follow (and beat!).