Re: [gtk-list] Re: GraphicsExpose (was Re: About the About Box)

[Owen Taylor <owt1 cornell edu>]

Tim Janik <Tim.Janik@Hamburg.Netsurf.DE> writes

> now, after we changed the default case for GraphicsExpose events in
> the GC initialization, we can only receive GraphicsExpose/NoExpose if
> the app/widget write explicitely requests them. therefore we should
> provide him with these events. providing a function that automatically
> does the event translation (rectangle adjustment), then makes the actual
> handling of these events just a matter of calling it and then treating
> the event like a normal expose event.
> but, applications that have their own way of handling GraphicsExpose/
> NoExpose still need to have access to the original event type.
> GemVt as an example will do it's own handling, this is neccessary
> because of the rapid scrolling speed that is neccessary (though not
> provided yet) for a terminal.

Hmmm, I'd rather put the intelligence in GTK where it could benefit
all widgets that needed it. I suppose a case could be made that
a VT widget should be optimized to handle many rapid 1 line scrolling
events in the same direction (xterm has such support, turned off
by default, possibly because it doesn't work in all cases) but I'm
not convinced that that it will be that much more efficient than
a good general routine.

It is a slippery slope - as with many things there is a temptation
to export all of X into GDK, but once you've done that you've
lost on both ends:

  You have all the complexity of X, and
  You have an extra layer slowing things down.

(BTW, it is pretty easy to do as well as an xterm without multiScroll
turned on using my current system, though what I've put in the
Text widget isn't that good. Let me know if you want details.)

Regards,
                                        Owen