DeLi Linux Wiki

DeLi Linux uses only lightweight software - so far, so good. But we have a major problem, when it comes to lightweight toolkits, aka widget sets. In the Linux world there are two major toolkits - Qt and Gtk.

Most of DeLi's apps are still using Gtk version 1.x. It's quite lightweight and there are still some applications which have Gtk 1.x support. But the number of this applications is decreasing. Far most of the applications are using Gtk 2.x now.

There is, of course, a problem with Gtk 2.x - it's bloated, and so is Qt. I estimate that a Gtk 2.x application eats approx. 5 MB more memory than its Gtk 1.x pendant.

What's wrong with FLTK, Fox, etc. ?

Technically, there is nothing wrong with this existing lightweight toolkits, but practically.

First problem is, that there are too few applications that are using this toolkits. On freshmeat there are 31 hits for “fltk” and 25 hits for “fox”, opposed to 1508 apps listed for Gtk and 625 for Qt.

But it is getting even worse: There are too many incompatible versions for fltk and fox. Fox 1.4 is incompatible with 1.6, and fltk 1.x is of course, incompatible with fltk 2.x, and additionally there is fltk-utf8 (used by XD640) and eftlk (used by EDE - the Equinox Desktop Environment).

It doesn't make much sense to use lightweight toolkits if you must install four or five of them - because together they will eat more memory then one of the major bloated toolkits.

So, what can we do?

The only successfull thing to do would be the uClibc-approach - to desing a toolkit library which is compatible with one of the major toolkits, but which is lightweight. This way we can use hundreds of apps and still have lightweight software.

The logical choice would be Gtk. We have Gtk 1.x on which we can build on. The goal should be to have a lightweight toolkit which is fully Gtk 2.x compatible but needs not more memory then Gtk 1.x.

Searching a name for this toolkit, I found out that “lgtk” (“lightweight”), “ugtk” (like in uClibc), and “mgtk” (“micro”) is already occupied. But “small” isn't.

So, the working title for this project will be sGTK.

Developing sGTK is of course the hardest thing to do. I'm not exactly a die-hard C-coder, but I know a little bit of programming.

First, we must find out, what the differences between the Gtk 1.x and 2.x API are.

The next step is to implement this API in GTK 1.x and strip as much bloat as possible. At the same time we must try to strip any possible bloat from Gtk 1.x as well, because the more stuff we add to Gtk 1.x, the more bloated it will became, and our goal is to use as few memory as Gtk 1.x.

When we finally have a first version that builds we can try to build simple Gtk 2.x apps and link them against sGTK.

This should be the first steps.

If you are willing to help in this project, please do not hesitate to contact me or leave a comment on this page.