Re: GtkDrawingArea within a GtkScrolledWindow problem

[Havoc Pennington <hp redhat com>]

"Norman Black" <stonybrk ix netcom com> writes: 
> The scroll bars never show themselves no matter what I set the adjustment
> ranges to. I had the scrolled window create the adjustments on its "new"
> call. The drawing area is always whatever size the window is, so it is never
> "bigger" than the scrolled window. I do not want any of the viewport "big
> window peeking through a little window" as this is probably wasteful (huge
> window) and I need a very large range, beyond what an X window can handle.
>
> I assume a scrolled window only displays scroll bars if the child is bigger
> than it is? How does it determine when to show/hide the scroll bars?
>
> What are the ramifications of having the drawing area "request" a size to
> make the scrolled window to behave a certain way. I would assume that the
> "allocation" that follows would be big and then therefore have X
> limitations.
>
> A GtkCList works with scrolled windows, and supposedly does not has the X
> window size limitation. How does it do this?
>
> I can use the ALWAYS policy since the scroll bars display their set ranges
> properly, and then switch to AUTOMATIC or NEVER when the scroll range
> warrants and the scrolled window will remove the scrollbar. This is fine,
> but if I can get it more automatic, then even better.

The much easier thing to do is to use GtkLayout instead of
GtkDrawingArea. This will also give you smoother scrolling. Here you
may need to either gtk_signal_connect_after() or
gtk_signal_emit_stop_by_name() or do a subclass to keep the default
expose/draw handlers from running, or to be sure your drawing code
runs after them. (The default handlers just blank the layout to the
background color). Also, you need to draw to layout->bin_window, not
widget->window. But otherwise you can just use it as a drawing area.
bin_window is part of the trick GtkLayout uses to get infinite
scrolling with child widgets.

GtkLayout does an infinite (well, 32-bit) scrolling region for you.
All you really need to do is handle draws and exposes, and when
scrolls occur GtkLayout will call your draw/expose handlers for the
newly-visible area. You set the finite size of the scrolling region
with gtk_layout_set_size().

GtkLayout has two members xoffset and yoffset. These are the position
of the bin_window in the scrolling region. When drawing to the
bin_window, you need to offset your logical coordinates by that amount
(i.e. if you are drawing at logical x coordinate 10, but bin_window
has xoffset 3, you need to draw at coordinate 7 of the bin_window).

Summary:

 a) gtk_layout_set_size() the layout to the size you want

 b) connect a drawing handler to the expose and draw signals of the layout
    - In the draw/expose handlers, use gtk_signal_emit_stop_by_name() 
      to keep the default handlers from running. (you could also 
      write a subclass or let the default handlers run before your 
      handlers by using connect_after.)
    - In the expose handler, if event->window != layout->bin_window,
      ignore the event (layout is a widget with two windows).
    - The exposed area received in your draw/expose handlers
      is in bin_window coordinates. To convert to logical 
      scroll region coordinates, add layout->xoffset or layout->yoffset.

 c) put the layout in a scrolled window with policy AUTOMATIC, and
    call set_size() anytime your logical scroll area changes.

To scroll programmatically, set the adjustment values to the top-left
pixel in logical scroll region coordinates with
gtk_adjustment_set_value().

Of course you can use a backing pixmap as you would with a drawing area.

Havoc