One thing missing from GObject and esp. the signal system is that there’s no way to control the order in which signal handlers will be fired except the after flag, which isn’t very powerful either. Sure, 99.99% of all applications will never need to be able to have fine-grained control about the signal invocation order, but then there’s always atleast one application, that needs this feature in order to avoid other weird work-arounds.
Thunar is such an application and the use-case is pretty simple: We have a ThunarIconFactory class in Thunar, which is used to load icons and perform some kind of caching on the icons, so you don’t need to grab them from the disk everytime. Now if the currently selected icon theme changes, the icon cache must be cleared before other modules get informed about the icon theme, as they’ll immediatly perform an icon lookup. So, the order in which the signal handlers are invoked matters. Unfortunately you have don’t necessarily have control about the modules, it can be code in Gtk+ or other libraries. Sure you could say, the icon factory is the first object I create and so it’s signal handler will always be fired first, but that’s really messy, as - according to murphy’s law - somebody will forget about this condition at some time (no matter how much comments you add to that code) and you’ll have a very, very hard to find bug, because you simply don’t think about that condition in the first place.
As a work-around, and that’s what we’re now used with Thunar, you can connect a signal emission hook to the "changed" signal of the GtkIconTheme class. Emission hooks are garantied to be run before any signal handler is fired (the default handler may run first, depending on the signal flags, but that’s no problem for us). Ok, this sounds cool so far. Unfortunately emission hooks aren’t bound to instances, but to types. And so whenever the "changed" signal is run on any instance of GtkIconTheme, the emission hook will be fired. While in theory this looks like a bad thing, in practice with the icon theme class, this is not a big deal, as you only have one icon theme per screen (or maybe even only the global icon theme) and so the worst thing that can happen here is that you loose the icon cache for all screens if you change the icon theme (which is not really a common action).
So, problem solved. But the solution is pretty hacky, tho no real need to break GObject. Just wondering…
And just right now Gtk+ 2.7.0 was announced with lots of breakage - have fun fixing your custom widgets if you used to use Xlib directly. ;-)
According to murrac, patches have been applied to Nautilus CVS to implement a tree view on a spatial view similar to what is possible with Aqua/Classic Finder. Judging from the screenshot this looks very similar to what xffm (and xftree in the Xfce3 days) did and still does if started with xffm. Sure the UI looks cleaner than the default xffm UI, but at the core its the same concept. So, if that’s what is needed to stop people complaining about the spatial Nautilus, why didn’t they use xffm instead (probably even sending some patches to edscott to polish the default UI)?
Postponed all work on the icon view for now, and been working on the volume manager and the trash implementation for the last 2 days. As initially planned, the ThunarFile class is now an abstract base class and the ThunarFolder class will be turned into an interface or an abstract base class as well. In addition, the ThunarFile class won’t export the associated ThunarVfsInfo (which is now only associated with ThunarLocalFile instances). This way we don’t limit ourselves to file implementations, which are more or less based on stat(2) directly. For example, there will be virtual files, like the trash can itself, and forward files like the trashed files. You could even imagine another class that handles locations other than file:// and trash:// using GnomeVFS, to provide support for network file systems and such. But that is an optional gimmick and not important right now.
While working on the trash classes, I was testing the basics when I realized that the far-from-being-complete implementation of the ThunarTrashFile and the not yet adjusted ThunarFolder class lead to an interesting effect:
I was pretty confused to see this working on first sight. My bet was that it would crash right away. But of course, it had to work that way. Anyway, not the expected behaviour from a user’s point of view, but it looks just too weird to not post the screenshot here.
A friend of mine pointed me to an interesting article today, which on first sight looked like just another useless Linux vs. BSD article, esp. since it quotes Theo De Raadt, who was never known for being very objective. But De Raadt points out some real problems with the Linux development model (everybody that has ever worked on the kernel or a non-trivial driver will be aware of these problems). Unfortunately, De Raadt’s diction is very bad, as usual, and so it’s unlikely that any of the Linux guys will pay much attention.
But the problems with quality assurance is not limited to Linux in the open source world. Many OSS hackers still seem to believe, that “if it runs, it’s good”, which is obviously not the case. There’s a common misbelieve that the crux in being part of the OSS world is knowledge about coding (it’d rather use the term hacking). From my experience, coding was always (and is still) the easiest part of the story. The hard work is to figure out what to code, and how to organize the various modules, to make it fit into the whole picture, and once the implementation is done, verify that the implementation covers all use cases and performs well. This is the shortest possible definition of my understanding of how to develop high-quality software.
But in order to develop the way described above, you need to setup clear goals for your projects. And this is exactly the point where Linux and many other OSS projects lose. They concentrate too much on providing an universal solution or on adding a new feature as soon as possible, and so improvements happens by fluke many times, not as a result of structured development and quality assurance. And even if they’re pushed by big players like IBM at the moment, this kind of development won’t work in the long run.
I’m not trying to blame Linux/OSS hackers, instead I strongly invite people to think about their development models and their understanding of open source. Take the chance to develop high quality software in your spare time; many of us will be forced to develop low quality software in our daily job anyways (yannow that money thing), so don’t you think you could do better in your spare time? Of course it takes time and the feeling of success won’t show up that early, but in the end you can be proud of your work.
Of course I could also be completely wrong here, and my understanding of open source is simply escapist.
It’s been very quiet in the Xfce community lately. The traffic on thunar-dev and xfce4-dev is amazingly low. I’m currently the only one to work on Thunar, tho Alexander, Jean-Francois and Brian have expressly declared their interest to help earlier. In addition the Thunar website project seems to be fast asleep.
Well, I’m not in a hurry. I’m wondering because 3-4 weeks ago, many people were offended at me for taking a break from the public. And now I’m still working on it alone, like I did 3-4 weeks ago. Maybe the debate was just full of hot air.
Concerning the Xfce Debian packages: We receive quite a lot of mails recently, asking for the status of the Xfce Debian packages. The Xfce 4.2 stable branch is now maintained by Ubuntu people. We will provide new packages once Xfce 4.4.0 enters ALPHA/BETA stage. People using plain Debian should consider upgrading to Ubuntu or using the so called official Xfce Debian packages (dunno how up-to-date or usable they are, tho).
You could also try the Xfce 4.2.2 packages for Debian, prepared by Mario Izquierdo, which are based on our Xfce 4.2.1.1 packages. His repository is available here.
