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?
I am currently working on a fork of GNOME that replaces the broken UI concepts from Windows with sound UI concepts from the macintosh (e.g. alt command keys instead of ctrl, global menubar, obeyance of fitts law, etc). So far, I've gotten it to the point where recompiling code that uses gnomeui macros produces mac shortcuts, gets rid of those underline accelerators that clutter menus (yes, I'll come up with a better non-mouse solution), and puts the cancel button in dialogs on the left and ok on the right, as is consistent with the western concept of negatives being on the left and positive being on the right. Cancel and OK should be replaced with more descriptive terms, but first things first. As for the problems with consistency between applications, I'm also working on "porting" (for lack of a better term) the code of many GNOME programs to a usable and consistent state. All menus, keyboard shortcuts, dialogs, for similar features will be consistent across apps. I'm screwing with people's code because they didn't screw with it enough.
Why am I doing this? Isn't forking counterproductive? Of course it is. But I am very greatly disturbed by Miguel et. al duplicating many of Microsoft's UI mistakes. When Microsoft designed the windows UI, they made a lot of decisions that were based on being different from(and in some cases, the exact of opposite) apple. The problem with this was that Apple put many years of HCI research into the design of the MacOS UI. By doing the exact opposite of apple of what apple did, Microsoft was going directly against interface designs that were scientifically proven in usability labs to be more effective, efficient, and intuitive. For example, it has been proven that an application menubar at the top edge of the screen can be accessed much faster than a menubar on the window of each application. This is not UI dogma or personal opinion, it's proven fact. But microsoft didn't care about end user's experience, they cared about their legal status. So they ended up throwing efficiency and usability out the door and doing the opposite of what was proven to work. The list goes on an on, ad nauseum. And when GNOME blindly copies the Microsoft (Where do you think the "Exit" menu item came from? The 'Q' in ctrl+q stands for something), they are perpetuating UI mistakes that need to be put to rest. GNOME should be about creating and designing new and improved user interfaces, not perpetuating bad decisions made in the past. I won't be party to putting users through another 10 years of UI misery to keep backwards compatibility with a backwards design.
I'm not saying that my ultimate goal is blindly copying MacOS. The mac interface certainly can be greatly improved upon. But I believe that when a UI builds on someone else's design, that someone else should be someone who knew what the hell he was doing. Microsoft does not fit that description, and Apple fits it better than anyone else who has yet come along.
I know that talk is cheap until you back it up with code, so no one will probably take me seriously. But it won't be too far into the future that I'll post a devel version of the modified gnome-libs and gnome-core on freshmeat. This UI insanity has to be stopped.
In five seconds the PenguinCow revolution will begin...
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
I think I am speaking for the large number of GTK+ users when I ask for a more modern default look for the toolkit. As it stands, GTK+ is a mish-mash of Motif, MacOS and Windows. I'm sorry, but even the QT/KDE look is more original in places. If GTK+ is going to make it big, some serious work needs to go into improving the usabilility of the widgets, as well as the API (I want to see a standardised C++ API for GTK+!)
Not quite what you're looking for, but a start: GTKSwing.
Actually, better yet is Java-Gnome.
Amazing what you can find on Google with a couple of well chosen keywords, isn't it?
--
--
The Internet is the Suppository of All Knowledge. You get it in the end.
Perhaps you should RTFL. The GPL states:
[emphasis is mine]That makes it pretty clear that the GPL does not restrict you from running the program. If you don't want to copy, modify, or redistribute the software you can just ignore the GPL, because it applies only to those areas.
There's no point in questioning authority if you aren't going to listen to the answers.
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.