Slashdot Mirror
Dave Mason On GTK+ 2.0, Pango, Gtk And More
Ur@eus writes: "We [at Linuxpower] have just put up an interview with David Mason of Red Hat Labs.
David answers questions on plans for GTK+ 2.0, Pango, GtkFB, GNOME and Orbit 2.0. Lots of interesting info if you want the scoop on
whats moving on the infrastructure front of GTK+ and GNOME." There's a lot here on the immediate future of those projects here, including some information on what features will distinguish GTK 2.0, and unfortunately only a teasing reference to adapting the ultra-cool aRTS project for GNOME. (That in particular makes me drool.)
On this system, all 64 Megs of RAM were consumed by Gnome and X
One of the fastest forms of interprocess communication under Linux is shared memory. However, top reports shared memory use incorrectly. For example, if two programs are loaded into RAM, and each is using 16 MB (8 MB for itself and 8 MB shared between the two), top will report 32 MB in use instead of 24. Under Linux, processes and threads are pretty much the same except that threads share memory; top barfs on multithreaded applications such as Mozilla. When X is running, top also reports your video card's RAM as in use by X and whatever apps are using MIT Shared Memory for their pixmaps.
someone really has to sit down with the GTK and Gnome libraries and start optimizing them for size and speed
Another example of the shared memory bug in top is in libraries. Under Linux, a library's code segment is marked read-only; it can be shared among several processes, making top misreport the memory the library is actually using.
Like Tetris? Like drugs? Ever try combining them?
Will I retire or break 10K?
GTK 2 will have a different default look; to get an idea what it will be like, try the "Raleigh" theme Owen released for GTK 1.2, which is sort of a prototype for the GTK 2 look. It removes some of the Motif-esque ugliness and looks cleaner. Still a simple, fast theme, no MacOS-X snazziness, but of course the point of themes is that you can switch them. ;-) For the default we want something that will be fast over a remote X display (and fast in general), not use too much memory, and reasonably conservative overall.
I think it's fair to say that the primary focus of GTK 2, aside from a few major features (Unicode/Pango, text/tree widgets) was API usability. GTK 2 should be a good bit easier to program. Basically as soon as we notice a FAQ or a question with no good answer on the support mailing lists, we file a Bugzilla bug and try to fix that problem via API enhancements. Better to eliminate the need to ask a question than to add it to the FAQ.
There are also various end-user usability enhancements, such as improved focus handling, etc.
Specific suggestions are welcome in Bugzilla.
Doh, I meant http://www.gtk.org/~otaylor/gtk/ui
He who knows not, and knows he knows not is a wise man
There's absolutely no reason why the user the GNOME and KDE projects are aiming for will pick all their applications based on toolkit. In fact, far more likely is that they will piock them based on quality.
Unfortunately, GTK and QT loook different. Consistency is one of the key ways of getting a user used to your system. There's no reason why a user should change the look and feel of half their application from one program, and the other half
with another.
Once that occurs, both projects should write a common set of human unterface guidelines and hash out a set of common controls, UI standards, etc. This may (will) mean modifications to the toolkits to support the samre variety of widgets.
The GNOME team should focus on making KDE applets integrate into their desktop. The KDE team should focus on making GNOME apps behave the same.
Both projects are doing fine. Unfortunately, both projects are enhancing the Linux desktop at the same time they are damaging it. MOst people don't realize Windows uses two toolkits - but over time, MFC and Borlands VCL have merged to look and feel acactly the same. Nobody undertands the value of a style guide when the first app is produced. When the second m thirs, and forth app is produced they do. Consistency is important
Unfortunately both teams seem to have no idea about this, from my investigations and discussion with various GNOME developers and one KDE developer. This is the biggest problem with GNOME and KDE.
AFAIK there are no efforts to fix it.