Header file naming in XFce libs
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
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 :-)
Xfdesktop
Hello,
now that we have a new member in the crew named kelnos Xfdesktop is improving daily. If you’re a straight followner of the discussions on the list you might even have his latest patch which finally brings icons to XFce’s desktop (Not that we need it ;-). Other things like different backgrounds for different workspaces and CDE’ish application icons are planned. For now kelnos’ primary goal is to get the desktop menu integration into his current code. Well well .. good luck! I can’t wait to see those CDE application icons ;-)
Apart from that this new blog rocks .. and so does it’s creator Francois. Did he actually tell you that we’re (or better: He) playing with animations for the XFce website to illustrate the way certain parts of XFce work? Its gonna be in flash .. and I can tell ya .. its so awesome.
Right, enough for this first test ..
Hello world!
Here is a new toy to play with!
The goal of this site is to provide yet-another-way to communicate for the XFce developers and contributors community, but a less serious one. We already have the XFce main website, which provides official news, resources, documentation, screenshots etc… But because of its multi-languages support, and because of the choice of easy portability that prevailed in its original specifications, xfce.org is quite static. So I guess it was a bit frustrating for XFce developers not being able to post even a little news on it. Thanks to Bachman, XFce users have their own successful forum (more than 470 registered users!). The wikiweb provided by Biju Chacko is the place to suggest new features for XFce. And of course we also have the mailing-lists. This weblog is not intended to be *solely* XFce-centered, even if it sets up a good tool to centralize XFce related (but “unofficial”) informations, and discuss some ideas. But it could be a good place to post an unrelated interesting/funny link too, or to recommend the latest CD of your favorite deathmetal band :P
– You have to be registered to post.
– You have to be on XFce credits list to be registered. Ask the webmaster.
– When you post, choose to allow/disallow comments.
Thanks to Auke and Chuck!
Enjoy!