Better netinstall

During perod while I was setting up moin and preparing a stuff for the new web pages, I took some time and rewrote NetInstall script (Note: link to netinstall can be changed in the mean time).

Previous netinstall, used to build EDE 1.1 and 1.2 was written in shell. I got inspiration for it from GWARE's install script (or there were another project, can't remember).

Shell version worked as expected; after few tunings even worked on FreeBSD (probably on OpenBSD too), but the drawback was the shell itself. Is already known how shell scripts can easily become unportable, especially if you get used on some very cool "bash-isms".

To make the story shorter, the new version is re-written in python, so using this script should not be a problem, since python comes with every distro and is often installed by default. Originally I wanted to do it in perl (to refresh my knowledge), but the final version emerged from one of the quick mockups I did in python and redoing that again would be a waste of time. I will leave perl for something else.

Shots of shell tools are not fancy, but everyone would like to see them anyway, so here is the one:


So what was done here? Well, netinstall is not static tool any more (read this as: "with stored package data") and contrary to the previous shell version, it can be downloaded and used multiple times.

Package information and details (a.k.a. metadata) are stored in separate files (named config files) and are downloaded from EDE web server. For example, here is how looks like default file. Nothing complicated.

But, the main "pro" of this approach is ability do build different EDE versions (or build EDE in few different ways), with a single tool. For example, by default, netinstall will build EDE 1.2, downloading eFLTK and correct EDE packages.

If you want to play a little bit with 2.0 version, you just type:

./netinstall --config ede-2.0.cfg

and voila; everything needed will be downloaded, compiled, patched if needed and installed. On other hand, if you don't have FLTK already installed, using:

./netinstall --config ede-2.0-full.cfg

will even download FLTK and compile it and install it, besides other EDE packages.

I know how how someone will try to compare it with Jhbuild and ask why I didn't use it first, but Jhbuild is way from netinstall goals. Jhbuild is kitchen sink that can do a lot of things, but you need to install it first, bootstrap it and perform some magic. In the mean time you could already download and manualy compile all EDE dependencies :P

I want netinstall to keep "download-and-run-it" spirit, with as less as possible hassle for user. That is the main goal.

Anyway, documentation needs to be completed and the code needs to be tested a little bit more.

Hooked on Isis

I really got hooked on Isis and their Oceanic and Panopticon albums. Still didn't listen the rest of their discography until I study these two as much as possible.

Heck, I even installed good ol' xmms because audacious equalizer makes absolutely pathetic sound on anything better than ordinary speakers.

Currently MoinMoin-ing...

Yep, I'm messing with MoinMoin last few days. I'm planning to replace current EDE web pages with it for easier content management.

Buildbot is running :)

I set up buildbot on http://build.equinox-project.org. It is scheduled to do nightly builds, downloading and compiling both edelib and ede2 modules, with execution of edelib unittests.

Builds are done on Slack 12.0, FreeBSD 5.3 and NetBSD 4.0.1.

To be honest, I set it up few months ago just to see how it will work and behave. Amazing tool!

Menus with icons

I just commited the new menu "system" in edelib trunk (actually, it is not really new, but forked FLTK menu code).

FLTK menus are fine, fast and works well. But there are few missing pieces, like custom icons in menu items. Actually, you can set an icon, but menu item label will not be shown, since that icon will be considered as label. Strange decision. Also, setting icons with custom sizes is not possible.

On other hand, extending menu code in FLTK is pretty impossible. One of the most important part of FLTK menus, Fl_Menu_Item, can't be inherited to allow custom item draws, so if do you even the smallest change in this class, you'll have to pull all Fl_Menu_* code and change it to use your Fl_Menu_Item modification. Pretty scary, isn't.

So, you know why it is forked :). Also, this is not the only reason. With this comes greater flexibility in future extending, adding custom drawing effects, improve scheming ability or similar things. Besides, I planned to use them for ede-panel, and these menus has to be little bit "more" than plain FLTK menus.

Here is how it looks like:


I know, nothing fancy and looks like menus in any other toolkit. And that is the point :). Also, icons with different sizes can be used, aligning their labels nicely. It doesn't look pretty and hardly anyone will use icons with non-uniform sizes, but follows FLTK way where each menu item could have different label size, font or color.


Contrary to Qt style (where you always have gap from the left size, no matter was icon used or not in the menu item), I took Gtk approach: if there is no icon, there will be no gap (like it is shown in above submenu). This gives some kind of FLTK "compatible" feeling.

Application code should not be changed considerably either. Instead Fl_Menu_Item or Fl_Menu_Bar, putting edelib::MenuItem or edelib::MenuBar will do the job allowing to use FLUID generated menus without much of the trouble.

New bug report tool

Last few days I spent working on this tool: a small tool that will make life easier for those who would like to quickly report bugs on our Bugzilla (named ede-bug-report, nothing fancy ;)). Those familiary with bug-buddy from GNOME will know what I'm talking about :)

Anyway, this development was my first expirience with xmlrpc-c library. For those who do not knows, Bugzilla exposes own API via XMLRPC protocol so if you have the right libraries (or enough bravery to write your own), you can nicely access it without using browser (with consulting Bugzilla API documentation, of course).

I can summarize using xmlrpc-c with two words: very painful. I had to rewrite bugzilla client three times, mostly due bad xmlrpc-c documentation. The first time (maybe this shouldn't be counted) was client emerged from my playground with Bugzilla API. This client was synchronous and was pretty unusable with GUI, but was working.

Second try was with xmlrpc-c asynchronous API, and after a few days of guessing how things should work (because documentation is horribly bad in this part), I managed to get it running. At least I though it.

Somehow, xmlrpc-c asynchronous API badly manage cookie sessions so after loggin in, submitting bug wasn't posssible and Bugzilla would report how I'm not logged in. I'm not sure is this due this library or I was doing something wrong (hardly since you have only few async functions and is pretty hard to get things wrong :P) but I couldn't get it running in any way.

And, at the end, the third try was/is synchronous client with threading. Although I'm not a big fan of threading, using threads was very joyable comparing to horrible xmlrpc-c async API. Damnit, you can't even cancel requests with it, so if you try to shut down the client forcefully, you'll get assertion straigth from the library.

Asside from these internal stuff, I tried to keep client's GUI pretty minimal. When I get those bug report dialogs with tons of input fields, I lose desire to report the bug, no matter how critical it was. Few fields and let developers sort it as they like, right :). Here is the shot:


Next is to make it work together with ede-crasher, so when something crashes, users get an option to report it in the same time. And move it from the branches in the trunk, of course.