[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: Fix for main map scrollbars
- From: Havoc Pennington <hp redhat com>
- To: gtk-app-devel-list redhat com
- cc: freeciv-dev freeciv org
- Subject: Re: Fix for main map scrollbars
- Date: Sun, 1 Aug 1999 22:31:54 -0700 (PDT)
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.
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.
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().
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.
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.
Havoc
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]