[Freeciv-Dev] Re: Scrollbars [patch]

[Kevin Brown <kevin@xxxxxxxxxxxxxx>]

Mike Kaufman <mkaufman@xxxxxxxxxxxxxx> wrote:
> you've got a gtk problem in your patch. It's spewing GTK-CRITICALs.

Are they Gtk-CRITICALs or GLib-CRITICALS?  I think I know what's
causing the latter (it says "assertion 'tag > 0' failed", right?) and
am fixing it, but I haven't seen the former.  If they're
Gtk-CRITICALs, could you send me the text so I can figure it out?

> On Sun, Aug 05, 2001 at 05:31:15AM -0700, Kevin Brown wrote:
> > Mike Kaufman <mkaufman@xxxxxxxxxxxxxx> wrote:
> > > mouse, I want the map to stop moving _now_. Not in a second, but
> > > right then.
> > 
> > Okay.  I think I've figured out how to make this happen.  Try the
> > patch I've supplied below and let me know what you think.
> 
> yes, this patch seems to have solved this, which is good, but you
> haven't solved my concerns that it takes ~10sec to move any distance
> on the map

That long???  I don't seem to have that problem, even on my remote
Xvnc session.  What kind of hardware are you running on, if I might
ask?  What's the geometry of the map you're using?

I wonder if I sent you the right patch... :-)

> and it's still choppy. 

I'm beginning to wonder if it's even possible to address this.  The
method I'm using measures how long it takes to do an update.  In your
case, that time must be relatively high for it to be choppy like that
(it's targeting a certain movement speed, in tiles/sec, so if the time
it takes to do an update is too long, it has to compensate by moving
multiple tiles per update).  It's the same way on my Xvnc setup.  I've
looked at the code that the scrollbars use, and what they do doesn't
appear to be any different than what I'm doing, so I don't see how
they can possibly be "smooth" unless you're moving them slowly.  When
you move them quickly, I think gtk just reports their position between
updates, so slowness in updating the map will cause gtk to report
scrollbar movement less frequently.  But that should make the movement
"choppy" also, except that you may be moving the scrollbar fast enough
that you don't really notice.  Beats me.

I think the nature of scrollbars is a little different than the nature
of movement buttons.  I'm beginning to think the choppiness you're
seeing is unavoidable.

> I think that until these latter
> concerns are addressed, it should not be applied. 

I don't think it should be applied until I get the code in to make
them a command line option.  I think the scrollbars should still be
the default, if only because that's what people are used to right now.

> I do like the idea
> of doing a scroll on right button press, with a center_map on right
> click. That seems elegant to me. It addresses economy of mouse
> movement, precision, with (i think) fewer lines of code. I believe
> that GTK will register events outside the gtk_window (i.e. is you
> end the button press off the civclient window, GTK will handle it
> correctly, someone correct me if I'm wrong).

I have my doubts about the smoothness, but I guess there's no way to
know unless someone tries it out.

But your primary beef with the scroll buttons is that you can't use it
to do large movements over the map economically.  If you do a
speed-based movement (based, for instance, on the distance of the
mouse pointer from its location when you clicked) then you'll get the
same choppiness that you're encountering now.  If you set it up so
that you use the mouse to "drag" the map, then the distance you can
move the map is limited to the size of your screen (or the size of the
window, or the size of the map, depending on the limitations of GTK),
which would be probably be unacceptable to you, given that you seem to
want to use these mechanisms to move across the entire map.

One possibility I can think of is to magnify the size of the mouse
movement while dragging by, say, (tiles_in_map/tiles_visible), so
dragging the mouse, say, horizontally from one end of the visible map
to the other would cause the map to scroll one map width.  But this
would almost certainly be overly sensitive when the visible map
viewport is small in comparison with the size of the map.

Any other ideas, then?  Looks like the best option might be to fix the
scrollbars in isometric mode and then implement 1:1 map dragging with
the right mouse button.


I'm all for giving the user options, so I'll fix the patch so that it
activates the buttons when given a command line option.  That way you
can use scrollbars if you'd like.  I'd still like you to test out the
buttons if that's okay with you.  :-)

-- 
Kevin Brown                                           kevin@xxxxxxxxxxxxxx

    It's really hard to define what "unexpected behavior" means when you're
                       talking about Windows.