[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: Fix for main map scrollbars
- From: Daniel Burrows <Daniel_Burrows brown edu>
- To: gtk-app-devel-list redhat com
- Cc: freeciv-dev freeciv org
- Subject: Re: Fix for main map scrollbars
- Date: Mon, 2 Aug 1999 07:13:55 -0400
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]