Category: General

We’ve been very successful at spreading Ubuntu CDs among students over here at the Technische Universität in Munich. Today, I’ve distributed 250 of them among the students of Electrical Engineering, and Moritz Angermann was even able to distribute around 1000 among the students of Computer Science, Mathematics and Physics.
All of them originated from Murray’s cellar. There are still loads of them available, so if you need a bunch of them, just ask him :).

Ross: I like your signal emission proposal! Sadly, GnomeVFSDrive doesn’t have any padding.

On the application startup itself: If we use the MIME type approach, it may be neccessary to add a hidden desktop file for each application (like gthumb-camera-handler.desktop), since the “Exec” line might not be appropriate.

I’ve also noted that “ghumb –import” doesn’t take any additional arguments. Shouldn’t it receive the BUS/Device/ID triple of the camera? Maybe we need new positional parameters for these very special use cases.

Update

Murray points out that one does not have to specify default signal handlers in the class vtable upon signal registration, which obviously renders my concerns pointless. This proves how well-thought out and flexible our core GObject system is. Kudos to Matthias Clasen and all the other hackers :).

On an unrelated sitenote: g_signal_override_class_closure seems to provide a mechanism to override the default handler for subclasses, although this isn’t relevant for GnomeVFSDrives. The g_signal_add_emission_hook API also looks very interesting.

Jeffrey Stedfast writes:

Ross Burton writes:
> > So. Someone puts in a CD. A while later, although there’s no
> > indication something is happening, sound-juicer pops up.
>
> This is a bug in gnome-volume-manager: it doesn’t give you any feedback
> that it is probing the new media, or starting Sound Juicer. I think a notification
> area icon for “new media inserted” would be good whilst it probes, and then
> the standard startup notification animation/panel entry when it starts up
> Sound Juicer.

This is actually completely false. No probing of audio CDs is ever done by g-v-m – any probing done on the device is done by the kernel/HAL/somewhere-lower-in-the-stack and so not only is the fault not with g-v-m for this delay, but g-v-m also cannot possibly report any notifications/progress/whatever.

I think Ross does not refer to the fact that probing a device takes time, but exclusively to the fact that gnome-volume-manager does not use startup notification. It simply executes /desktop/gnome/volume_manager/autoplay_cda_command.

IMHO, we should rather use a special key in .desktop files specifying that a particular application handles a particular media type (i.e. VolumeManagerBlankCDExec=foo %s, VolumeManagerDVDExec=bar %s, etc.). If we add gnome_desktop_item_launch_full to the GNOMEDesktopItem API, allowing the client application to specify another key than “Exec”, we’ll be able to pick up all applications with such a key and let GNOME Desktop ensure that the “StartupNotify” key is evaluated.

This would also resolve the following usability rant. I’ve felt exactly the same when seeing the dialog for the first time, btw.:

I realize that providing a drop-down list of known applications would only throw a very small light on what the system usually offers. However, the average desktop user neither knows about commandline parameters nor even about the names of all the applications he uses because the GNOME naming schema (in menus and so forth) differs from the real application names (they’re not localized, for example).

I think somebody already came up with a similar proposal, at least I remember seeing a mockup.

I’ve been trying to get my old freedesktop.org CVS account renewed for more than 2 months now. I filed a bug report and kindly and repeatedly asked on IRC. I was told that they have no admin ressources or got no response at all. I’m curious how many of your efforts were already massively slowed down by the lack of clear rules and responsibilities. I’m also perceiving similar problems in GNOME, where lack of time by people in charge who mostly work on distro-specific stuff that has nothing to do with stock GNOME, or lack of clear accountings already proved to scotch many efforts.

Back to freedesktop.org: Nobody seems to care for my bugs and some bugs in the GNOME bugzilla depend on them, like this one (cf. related GNOME bugzilla rant by Erich Schubert). Whoever can arrange that my CVS account works again, he’ll be my very special hero of this weekend and get a free beer.

Update

Eric Anholt deserves beer!

On a sidenote: I always think it’s kind of sad if people get what they want exclusively because of some sort of advantage over others (i.e. some people are not able to rant in blogs), or rather the position they have in a community. Bugzillas are IMHO really meant to work in a socialistic fashion by being polite and treating all bug reports equal.

Helping people on gtk-app-devel-list is fun, especially when familiarizing them with C pitfalls. I’ve written a little lineup describing four common C pointer argument conventions:

1 void foo (const void *bar);

means that bar will definitly not be modified. While the foo author
could theoretically force to free or modify it, that would require casting the const away and whoever does it is on crack:
C uses call by value. So after invoking foo, which could do free ((void*)bar), and set its local copy of bar to NULL, the outer bar variable is undefined. Using it further will most likely result in a crash, including calling free (bar); in the outer frame again.

2 void foo (void **bar);

This is some sort of call by reference. You pass the address of the bar
variable, i.e. char *foobar = …; foo ((void **) &foobar); This syntax
ensures that the foo function can dereference its local copy of &foobar,
and make *bar (which is foobar) point to NULL after freeing, or
reallocate it – do all the pointer magic (except for pointer arithmetic,
because it is a void * pointer in this case).

3 void * foo (void *bar);

This will also work on the local copy of bar, and
– if it changes bar – return that changed value, i.e. the new address of its local bar copy. So you can invoke it
like char *foobar = …; foobar = foo (foobar);.

I’ve never seen any function acting like that, to be honest.

4 void * foo (const void *bar);

Just some flavor of 3, which will always return newly allocated memory
in addition to that already allocated for bar, while not modifying the
latter.
eel_str_strip_chr uses this variant.

Update:

Tollef points out that flavor 3 is used for realloc.