Re: [platform-swt-dev] SWT/GTK and Gnome Summit

["Mike Wilson" <Mike_Wilson@xxxxxxx>]

Yes. The thing is though, from the point of view of the SWT team, we are trying to do something reasonable, which we *have* been able to implement on other GUIs, which is turning out to be extremely difficult in GTK. We're looking for either better ways to implement this in GTK (it wouldn't be the first time we missed something obvious) or improvements to be made in the GTK code base to support the kinds of things we are trying to do. After all, there's nothing which would inherently "blow that to hell" between frigging with the Z-order and double buffering. The widgets simply need to know when to recompute their buffers.

McQ.

Seth Nickell <snickell@xxxxxxxxxxxx> Sent by: platform-swt-dev-admin@xxxxxxxxxxx 07/18/2002 12:29 AM Please respond to platform-swt-dev

To:        platform-swt-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [platform-swt-dev] SWT/GTK and Gnome Summit

> Another problem is overlapping and z-order.  Overlapping widgets are very 
> common in Eclipse.  Several Eclipse UI features are implemented by 
> shuffling the z-order of things (e.g., switching perspectives). Obviously, 
> this is not the UI style GTK creators had in mind.  Widgets in a typical 
> GTK app never overlap.  GTK does not provide facilities to directly 
> control the z-order.  We solve this by having an X window with every 
> widget's "top handle", and calling X directly to control the z-order.

This causes a major problem, namely the flashing and screen redraw
problems Eclipse experiences when you switch perspectives, move tool
panes, etc (at least, I believe this is where the problem lies after
hunting for a couple hours). GTK2 is double buffered, very important to
perceptions of speed and how "comfortable" software is to use, and
manually tweaking the z-order blows that to hell.

I used the Windows version of Eclipse for the first time a couple days
ago, and the difference blew me away. The Windows version came across as
much more polished and visually smooth. Initially I thought it was a
performance issue (Win32 JDK/JIT tends to be faster), but after poking
around a bit I realized it was largely the crazy redraw problems
(problems that would basically disappear with double buffering).

-Seth

_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev