[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fix for main map scrollbars



On Sun, Aug 01, 1999 at 10:31:54PM -0700, Havoc Pennington was heard to say:
> 
> On Sun, 1 Aug 1999, Daniel Burrows wrote:
> > 
> >   A few days ago I posted a message on freeciv-dev about the problem of getting
> > the scrollbars to correctly reposition themselves when using the GTKStep
> > theme engine.  I'm still working on the more general solution to the problem
> > (making a 'real' Freeciv map widget, perhaps derived from the Viewport class?)
> > but I think I have an interim solution.  It seems to generate a gratuitous
> > GTK+ warning, I'm not sure what to do about this :/ -- but everything looks to
> > me like it works fine (and the scrollbars are in the right place! :) )
> >
> >   This patch removes the explicit creation of scrollbars and instead creates a
> > scrolled window, giving it the adjustments used to fiddle with the map canvas'
> > location.  We then add the map canvas directly to the scrolled window (instead
> > of using gtk_scrolled_window_add_with_viewport).  This works beautifully.
> >
> 
> OK, the real problem here is that GTKStep is broken - there is no correct
> way to move both scrollbar arrows to the same end or widen the scrollbars,
> and it must use a sicko hack. Gtk themes just aren't flexible enough to do
> what they want to do.

  Hm, ok.  I took a look at the source, what they do is override the
size_allocation signal in various global class structures.  I don't know if
I'd go so far as to say 'sicko' but it's definitely a hack :)

> So, I would not insert hacks into freeciv or Gtk in order to work around
> GtkStep, instead we just need to increase the flexibility of themes
> eventually.

  I agree that that's the correct solution in the long-term.

> Re: this specific patch; I assume the warning you get is that you need to
> use add_with_viewport? The correct fix is probably to write a custom
> widget (perhaps derived from GtkDrawingArea) that has a
> set_scroll_adjustments signal and places the ID of that signal in 
> the set_scroll_adjustments_signal field of GtkWidgetClass in the class
> init function. If your widget being scrolled is a drawing area, you
> need to use add_with_viewport().

  Yes.  Previously we were packing scrollbars next to a drawing area (the map)
manually, then attaching to the adjustments of the scrollbars and performing
scrolling ourselves.  I just rewired it to use the ScrolledWindow's adjustments.
As you say below, putting the drawing window in a viewport is too inefficient.

> This is a bit inefficient though; because you're keeping the entire
> virtual map size in RAM, in fact two copies (the backing pixmap), even if
> only a small part of it is visible. The alternative is to keep the size of
> the drawing area to the visible area, and then only draw the visible part
> of the map (read the adjustment values manually to determine your
> offsets). In other words, when the scroll adjustments change, change what
> you draw onto a small drawing area instead of changing which part of a
> large drawing area is visible via the GtkViewport.
>
> I suspect freeciv is already doing this, and that's why it works without
> the viewport. But you shouldn't use a scrolled window in this case unless
> you write a custom widget.

  So..to write a scrollable widget I just have to create a
set_scroll_adjustments signal handler?  I was concerned that I'd have to derive
from the Viewport, which is a container (I don't need/want a container) and
might not be very good as a standalone widget.  (I also want the map widget to
be able to exist without a scrolled window..I think that this way all I have
to do is to check whether someone used set_scroll_adjustments)
  I'm aiming to eventually rewrite the map code into a widget, I just wanted to
see if there was another (simple) solution.
 
> Conceivably Gtk 1.4 could have a scrolled window that does what you want,
> but you don't want to apply this patch to a Gtk 1.2 application.

  Well, it works.. *ducks*

  But ok, I guess I'll go the long way around and do it the Right Way..

  (incidentally, are any Freeciv people reading this?  freeciv-dev seems to be
   bouncing my mails..)

  Daniel

-- 
The only thing worse than infinite recursion is infinite recursion.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]