New session manager

  • May 21, 2004
  • Benedikt

I’ve been working on a new session manager for about three months to fix the shortcomings of the old session manager. The code has now finally made its way into CVS. Its not yet in production state, but its already usable. The new version is completly incompatible with the old one, that counts for session save format – which is now plain text – as well as for splash themes. Old themes won’t no longer work with the new session manager. Francois is currently working on splash themes. I will wait for him to tell me whats missing until I declare the new format stable.

Besides that, the file system layout of the session manager has changed. It follows the XDG basedir spec now, that says, you’ll find the session data files in ~/.cache/sessions/ and the configuration in ~/.config/xfce4-session/ (the global config can be found in $sysconfdir/xdg/xfce4-session).

There are currently several options to customize xfce4-session, where most of them are “hidden options”, that is they are not changable from the settings dialog. I don’t want too much options in the GUI, to not confuse new users. The question is now, what options are important and what are “geek options”. If you have any opinion on this, please let me. Also if anybody thinks, there should be an option to customize behaviour ABC, please send mail to xfce4-dev.

The shutdown code was changed to be sudo-only. That is, if you use plain xfce4-session, you’ll need to have sudo installed to shutdown/reboot the computer, see README for details. Packagers can easily change this to use distribution specific methods, by replacing xfsm-shutdown-helper.c with their code.

And last but not least, multiple sessions are now supported (a nice side effect of the new design). I’ll add “realtime checkpoint” support soon. This will allow you to instantly switch between sessions – or “checkpoints” in this context – without having to relogin (the problem here is, how to handle non session aware applications).

So, for the brave, go to get your copy from CVS – and no, there’s no version available for the 4.0 branch, since xfce4-session makes heavy use of new features in libxfce4util. As usual, send bug reports and feature requests using the bug tracker or mailing to xfce4-dev.


Header file naming in XFce libs

  • February 3, 2004
  • Benedikt

While integrating the about dialog in libxfcegui4 I realized that we have three different naming schemes for public gobject header files in the base libs:

1. In libxfce4util we have a class named “XfceDesktopEntry” with a file name of xfce_desktop_entry.h

2. In libxfcegui4 we have classes whose names start with “Xfce” in files, like XfceFrameBox, in files named xfce_framebox.h (notice no ‘_’ between Frame and Box).

3. In libxfcegui4 there are also the Netk class, for example NetkClassGroup, with an interface file named netk-class-group.h

Should there be one consistent naming scheme for all public interface headers in XFce? I would prefer the third alternative, as this seems to be the standard. That way I no longer need to look into the include dirs how the header file is named, instead I can just get the header file name from looking at the class name.

Thoughts on compile times

  • February 2, 2004
  • Benedikt

First of all, heres the oblique printf(“Hello world”).

Now, while we are all trying hard to make XFce a fast application suite – and in the not so far future maybe a development plattform as well – nobody seems to care about compile times. Today I had to update my system due to a bug in the POSIX thread wrapper. Because of updated libpthread I had to recompile glib/atk/gtk etc. and finally recompile all of xfce from the beginning. I noticed that it takes quite some time to compile everything (on modern hardware, except for the slow IDE disk drives, but thats another story). Nevertheless it left me wondering why XFce takes so long to compile (I usually only recompile only the necessary stuff, most of the time only the stuff I’m currently working on, so I haven’t recognized so far), since we have only few files compared to say KDE or Gnome. Being a C++ programmer in real life I know how to optimize C++ compile times: Include only whats necessary and keep your interface files small! Besides producing good designs (application design, not GUI design) and writing working code, this is one of the most important rules in midsize to large C++ projects, because it saves you and your testing crew hours of recompiling and makes interface errors easier to locate (esp. when you make heavy use of templates).

Now, looking at XFce code, it seems we have all started with the same stupid Gtk+ tutorial :-), cause we all simple include gtk/gtk.h, glib.h, etc. which imports the whole Gtk+/Glib/etc. interface descriptions into each of our source files, that says, the compiler has to parse all of the Gtk+/Glib/etc. interface code, which means increased compile times (today lexer/parser is at around O(n^3) plus preprocessor plus symbol tables plus …). In addition to increased compile times, we get additional sources of errors. I remember gcc reporting an error about something totally stupid in gtkcurve.h, which is part of the Gtk+ interface, but gtkcurve.h was ok. The error was caused by a typo I had in one of my preprocessor macro names that led to an invalid substitution in gtkcurve.h.

So, to conclude, maybe we could make use of pratical techniques to optimize the compile times in XFce.

The next step then, would be to make configure run faster, but thats really a story of its own, if possible :-)