So today I updated my system and seen that the new nmap version features a totally new frontend, written in Python with pygtk. While this bothres me a bit because I had to install the pygtk package with its siblings, I actually find this an interesting and useful change.
I say this because, well, frontends don’t need to be fast or to have a tight memory usage pattern; most of the times, frontends only have to take care of user interaction, and the user interaction is neither cpu, nor memory, nor I/O bound, it’s user bound.
Scripting languages don’t usually suffer from architecture problems, like endianness of variables, or missing definitions or include files moved around; well, the base interpreter does suffer from these problems, but it’s one package instead of every package.
Also, scripting languages usually makes it easier for users to change the frontends if they need, which is certainly an advantage for the part of the program – the frontend, as said – that faces the user.
This made me think about writing a new Valgrind frontend; my language of choice would certainly be Ruby, the problem is: which GUI libraries would I be using?
An year ago I was dead set on Korundum, KDE’s Ruby bindings, but I don’t think this is feasible now. The reason is of course tightly related to the KDE4 development: writing on Korundum makes little sense, considering that the focus is now KDE4, but KDE4 itself is too young to write the frontend using that. Plus there is one big problem with QtRuby: the Qt3 and Qt4 Ruby bindings install the same shared object, with different APIs, making a Qt3 Ruby program incompatible with a system where Qt4 Ruby is installed. And writing the frontend in pure Qt4… I’m not sure about that.
The alternative is to use ruby-gtk2. Even if I don’t like the GTK C interface myself, the Ruby version seems nicer to me. And with Nimbus I can finally stand GTK2 interfaces. I should probably try this out, it might be good enough to go.
Actually, with little work it’s likely that I could write a pure-Ruby abstraction for a valgrind frontend, and then two interfaces, one in GTK2 and one in Qt4. This is another nice part of scripting languages: you usually have the basic set of objects not being part of the libraries used (QString, GString, …) and you can more easily share code between Qt, GTK, NCurses, whatever you want.
So, anyway.. I need something to keep my mind busy tonight, as I’m having some real-life trouble (no, not health trouble, just… love trouble :/), so I’ll probably start tonight to work on something.
I should probably not say this seeing how long it takes to get wxGTK updated in the Gentoo tree….. :-(Have you tried the ruby interface to wxWidgets?? It’s called wxRuby. I never worked with it as I don’t use Ruby, but it might be something to look at.ps) Reason that I suggest is that under C++ I find the wxWidgets framework clearer then QT. It might be similar for the ruby-bindings.
I’ve mixed Qt3 and Qt4 QtRuby together for years. There’s no reason they can’t co-exist on the same system….
Installed? Last time I tried the ebuilds installed the same object files, one writing over the other.Sure I could install them manually (and I did for a while) and then choose with -I which one to load, but it’s not really the best of ways.
I happily use both qtruby and qt4-qtruby on my system at the same time, installed, from ebuilds. If you’re having that kind of behaviour, it must be some sort of bug that I’m unaware of. Please do let me know if that’s the case.
One framework I’ve been wanting to try out lately is “shoes”:http://code.whytheluckystif… . I don’t think we have it packaged yet, but it shouldn’t be too hard.