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!
Thursday, July 9, 2009
Friday, July 3, 2009
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.
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.
Wednesday, July 1, 2009
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.
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.
Subscribe to:
Posts (Atom)