[plug] Gdk errors

[Russell Keith-Magee]

> > 4) The support for Xfree 4 extensions (like the render and font
> antialiasing
> > extensions) is pretty abysmal. Whereas QT gets font
> antialiasing through a
> > recompile of the QT library, you have to completely rewrite
> your GTK apps to
> > use Pango, the new antialiased font system. This is an artifact
> of points 2
> > and 3.
>
> Quite a while (six months ago..) GTK 2.0 had been modified (I think by
> eli) to support the render extension on all the standard widgets. I've
> seen screenshots of it a long while ago.

I didn't hear about this one. Must have slipped under the radar. Happy to
stand corrected, though.

> Of course, GTK 2.0 isn't out yet.

Yes, but it will be out Real Soon Now (tm) :-)

The gnome/gtk guys do great things, but they do have a bit of a reputation
for letting deadlines slide... I wouldn't bet the farm on a production
version of GTK+2.0 being available before the end of the year.

> > 5) The UI system isn't threaded at all (although many of the
> libraries are
> > thread safe). Consequently, it is very easy to lock up your UI
> by having a
> > processing routine that doesn't return quickly.
>
> It is possible to write highly threaded GUI applications using the
> Gnome/GTK libraries - eg. evolution.

I didn't say it wasn't possible to write threaded apps - GTK even has a
thread abstraction library to help you do it. However, the default GTK
application (i.e., the approach suggested by the tutorials, etc) is
non-threaded. If you put a sleep(1000) in a button press event handler, the
entire interface will freeze. If you switch desktops away and back, the
interface will appear as a gray rectangle on the screen, as no redraws are
performed while the sleep occurs. Similarly, while the sleep is in progress,
no menus/buttons will react to button presses. As soon as the sleep
completes, the backlog of UI events will be processed.

Java Swing (and IIRC, Qt - but don't quote me on this) runs a separate
thread for UI updates; as a result, the UI is constantly updated, events are
processed as they happen, and slow running business logic code doesn't
impact on the apparent `snappiness' of the interface.

You can get around the problem, and build your own UI thread, but every user
has to invent that wheel - and it's not an easy wheel to invent. The GTK
docs explicitly warn about event processing across threads.

I don't know if this is going to change with GTK+2.0 though...

> I've written only small things with GTK, I'd say the biggest impedence
> to using it is the lack of documentation for the widgets and libraries.
> The documentation is not even up to the level of simple pre-conditions
> and post-conditions in some cases.

This is very true. Although the documentation is automatically generated,
and is theoretically complete, there are a lot of empty documentations
blocks.

There is a workaround though - you download the source, and become adept at
reading it. Not optimal, but on the upside, you do get a very healthy
understanding of how everything works :-)

Russ %-)

********************************************
Russell Keith-Magee
Software Engineer
Calytrix Technologies
Unit 9, EIR Building, Technology Park
PO Box 1173, BENTLEY 6982, Western Australia

Tel: +61 8 9362 5300
Fax: +61 8 9362 5400
Mobile: 0408 928 379