Re: Plans for drawing in GDK-1.4.

[Owen Taylor <otaylor redhat com>]

Elliott Hughes <Elliott.Hughes@genedata.com> writes:

> Owen Taylor <otaylor@redhat.com> wrote:
> > How does this help? Double buffering wouldn't decrease the amount
> > of time until the newly scrolled-in areas are updated as far
> > as I can see.
> 
> no, but it will improve the appearance. as you note on your web page,
> it's not speed that's the problem, it's perceived quality, and flicker plays
> a large part in this perception.

Double buffering only helps for scrolling if we make a change to
set a background pixmap of 'None' while scrolling. Otherwise, 
when you scroll, areas get cleared to the background color 
by the X server before being refreshed, and you get flicker
even if the update in one pass. (This is very obvious with
Mozilla which double-buffers all drawing and flickers like
crazy while scrolling.)
 
> > Just because there is a scroll-window call doesn't mean that scrolling
> > is generic. A widget would have to keep track of the coordinate
> > offsets.
> 
> my contention is that scrolling is almost ubiquitous, particularly in
> user-written widgets. there aren't many little widgets not already
> available, so widget writers will almost certainly have to deal with
> scrolling. i accept that they'll have to take the scroll offsets into
> account, but i find it unfortunate that they have to write the
> set_scroll_adjustments code each time.
> 
> > The whole point of not putting set_scroll_adjustments into GtkWidget
> > was to avoid bloating the GtkWidget interface with yet more signals.
> 
> how about in GtkDrawingArea then? because it actually has a window,
> this tends to be more convenient for the widget writer than direct use of
> GtkWidget.
> 
> > Adding support for interfaces to GtkObject is still in the plans
> > for 1.4, and set_scroll_adjustments is a prime target for making
> > an interface.
> 
> i just have the feeling that the current situation is less convenient than
> it could be. i don't much mind how it gets resolved, as long as it does.

I don't see scrolling as ubiquitous - most cases in which I've written
a custom control for an application, with GtkDrawingArea,
or as a from-scratch widget, I haven't needed scrolling.

But even if scrolling was ubiquitously needed, the way to add scrolling
to a non-scrolling widget is to add it to a GtkViewport; just as
the way to add a border to a borderless widget is to add it to
a GtkFrame, or the way to add alignment to a non-aligneable widget
is to add it to a GtkAlignment. ("The decorator pattern" for those
so inclined).

Remember that simply having the ability to scroll the window doesn't
make you a scrollable widget. You need the ability to define the
scrollable region, and you need to keep track of the scroll offsets
when drawing. GtkViewport hides these details from the widget
writer in a way that adding scrolling directly to GtkWidget could
not.

And if I manage to do all I plan to do with hiding the 16-bit nature
of X, it should be possible to use GtkViewport even for widgets
that need to scroll over a > 16bit range.

Admittedly, having GtkViewport as the default scrolling method
forces people using the toolkit to know about the difference
between scrollable and non-scrollable widgets, but I think that
is a manageable concept when well documented.

Thanks for your comments. Hopefully I'll have some of this implemented
soon.

Regards,
                                        Owen