Riding EDE on SunStudio

Note: this is not tutorial about how to compile EDE 1.x on SunStudio compiler, but impressions after compiling ede2 module (EDE 2.0).

As I wrote before, edelib and FLTK works fine with SunStudio 12 compiler. Of course, since I didn't tried edelib on this compiler for some time, some small tweaks were needed; these were mostly setting correct path to the compiler and runtime libraries (and preventing linkage with gcc libraries). Now, these steps are nicely documented in INSTALL files that comes with edelib.

So, after compiling edelib and FLTK (did I say how you must compile FLTK on SunStudio too?), EDE came. Procedure was mostly the same, except I had to hardcode fltk-config path in the configure script.

This was mandatory since configure would pick up system's fltk-config (FLTK compiled with gcc), not the one compiled with SunStudio (I placed this one in /opt/fltk-sun). This got me nice TODO to add --with-fltk-path in configure script, the same flag edelib has for these purposes.

So, before I fired jam, I disabled compiling edewm, ede-panel and efiler. edewm and ede-panel are still on eFLTK and didn't compiled eFLTK with sun's compiler. On other hand, Vedran didn't have time to update efiler on the latest edelib changes, so, generally speaking, efiler is and will be in uncompileable state for some time (I'll have to motivate him to fix this, because I don't like when repo code can't be compiled).

Compiling went fine; few small errors popped up (explicit casting to const char**, nothing serious) and a bunch of warnings, which is good :) Although I tend to compile edelib and ede with -Wall and -pedantic flags, gcc didn't complained so far.

As usually, I got a few Anachronism-istic warnings and a few vairable shadow-ings. The one was pretty interesting and I'm curious how gcc didn't catch it.

MessageBox::set_input() was implemented like this:

void MessageBox::set_input(const char* txt) {
  if(inpt)
      inpt->value(txt);
}

but MessageBox had txt as private member too. Of course, gcc was smart and got my intention, but I would much prefer some warning here. +1 for SunStudio!

Now, to save me from these from-time-to-time-remember-to-compile-with-this-or-that, I'm planning to setup buildbot with the nightly builds. Before some time, I played with CDash (via their public service), where I had to instruct edelib to generate cdash-like test result output.

I don't know what happened; few times I couldn't submit results probably because server went offline and after that, I couldn't even login to edelib CDash account (I just checked now; seems edelib is still there :)).

But, I will try to stick with the buildbot this time. CDash is CMake centric and buildbot does not need special output files to figure out were builds or tests successfull of not. There are more things to say, but since their concepts are pretty different, comparaison wouldn't be fair.

edelib-new-icon-theme merged

Title speaks for itself :)

Why we needed a new icon loader? Well, because we needed it :P. IconTheme class was way too much monolithic; there you had icon snarfer from the theme, some kind of caching facility to reduce access() and everything that packed in a singleton class. Not bad for some basic usage.

I wanted some things beyond that, mainly to allow dynamic icons reload when the icon theme was changed during desktop session. You know, telling "Please restart your desktop" just because you changed icon theme reminds me on Win 95 days. Don't get me wrong; I'm not fond of the GNOME's instant-apply-on-the-click approach either, but let we leave "Please restart..." way for some serious stuff :)

Also, one thing itched me a lot: checks after icon was fetched. We had before:

String path = IconTheme::get("foo-icon", ...);
if(path.empty()) {
  /* try to get "empty" icon */
  path = IconTheme::get("empty", ...);
  if(path.empty())
     /* bail */
}

Fl_Image* img = Fl_Shared_Image::get(path.c_str());
if(!img)
  /* bail */

/* finally load it */
widget->image(img);

I already lost inspiration to load some icons.

Now, by introducing IconLoader, things are reduced to this:

IconLoader::set(widget, "foo-icon", ...);

Much better.

This introduces a lot of benefits; first it reduces the code, then it will automatically update widget's image when icon theme was changed (for this Window class must be used) and, most important, allow me to explore efficient ways of icon loading (or whatever) without going in each program and update the changes.

Of course, this solution is not perfect. There is no way to track when widget or image was destroyed (except beeing inside FLTK), so, from time to time, it is good to call IconLoader::repoll() to update internal tracker. This thing is only needed when the large number of widgets or icons are loaded or destroyed in the short period.

IconTheme is still there; now is class related to the only one thing: loading icon theme and it's metadata. This allows loading two different themes in the same time (for example, to fetch descriptions, sample icons and etc.).

Someone will notice similarities with KIconTheme and KIconLoader from kdelibs. That is because I had pretty blur idea how it should be done, so I peeked a little bit how expirienced guys did it. Except similar class and method names, everything else is different.

edelib-new-icon-theme branch also introduced some improvements in Window and MimeType classes (like using user defined icons for mime types).

By the way, recently someone send me a link on discussion from Wolvix forum. Thank you!

NetworkManager sux (or not)

Last night I installed Fedora 10 (actually, I had it on my VirtualBox, but this time I wanted it on the disk), so that was a perfect time to test NetworkManager. I like when they said: "The most important pieces of NetworkManager are desktop-environment and distribution agnostic": gives me some neat ideas :D

Anyway, in my case, I have a wireless card that needed to be connected via xDSL. Nothing complicated, but...

I'm not sure was it fault due NetworkManager or GNOME's fronted, but I couldn't make it to see wireless card in "Hardware Device" tab; strange, since the card was regularly recognized in main hardware section.

So, after some searching (and more searching), I found out how NetworkManager is still a young project, with a plenty of time for improvements :). That send me to the good old terminal and "pppoe-setup".

edelib-new-icon-theme branch

The new icon theme code is on the road, and there is edelib-new-icon-theme branch (I haven't commited changes yet). This change will break a lot of things, but it is better to do that now, than later.

Reasons for these changes will be, hopefully, typed soon :)

Playing with D-BUS service autostart

Offtopic: a small undocumented issue in edelib about registering unique D-BUS name was fixed in the repo. I'm not sure how I missed this; probably I was thinking that native dbus_bus_request_name() will do all the work, but it turns out that it is much more powerfull than simply name request. Check out D-BUS docs about it (read that part few times, they complicated a little bit with explaination ;)).

D-BUS service autostart (I'm using word "autostart", but docs are saying "start"; feels much more natural) is one very cool D-BUS feature (probably inspired with CORBA), where D-BUS would start a service provider on demand. E.g. you have org.example.Test service implemented in test-daemon, but you don't want to run in in the background all the time, only when is really needed. As D-BUS specs prescribes, you simply create an .desktop like file, ends it with .service (preferring way is to use service-like name, e.g. org.example.Test.service) and put in D-BUS service directory. Now, when you first time conntact this service, test-daemon would be spawned and apps would happily starts to consume org.example.Test.

So, following this, I added Startup Notification support in ede-launch-sn, a small helper tool for ede-launch command I quickly constructed just for this; ede-launch would connect on org.equinoxproject.StartupNotify and call StartupNotify member, initiating notification sequence. Then ede-launch-sn would terminate that sequence after some timeout.

Startup Notification listener is not implemented yet, so notification is only seen in window managers (or environments) that has support for it.

I didn't put the code on the repo because I still didn't figure out should we need another service in the background and/or how could it be nicely blended in ede-launch command.

slacky.eu

Totally by accident, searching for Valgrind package for one of my (still not yet up to date) Slackwares 12.0 (yes, I'm lazy to compile it), I stumbled on this site by the Italian Slackware Community.

They have a large package repository (everything you won't find on official CDs/DVD), and guess, there is EDE package too. Awesome!

Go slacky.eu, go :)