[Freeciv-Dev] Re: Scrollbars [patch]

[Kevin Brown <kevin@xxxxxxxxxxxxxx>]

Mike Kaufman <mkaufman@xxxxxxxxxxxxxx> wrote:

> in all seriousness, the revised patch is only slightly better that
> Daniel's. You are right, I think, that the direction of movement is
> more intuitive than with the use of scrollbars, but I think that
> these solutions (so far anyway) do more harm than good. Even with
> the new patch, movement across the map using the buttons is _very_
> choppy, whereas with the scrollbars, it's quite smooth. Also, and
> I'm not sure how you'd fix this: when I release the button on the
> 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.

> Think about this in terms of user friendliness: start up a new game
> so your dudes show up as a small colored spot on the overview
> map. move off well into the black. now using the buttons or
> scrollbars, move the map right back to your guys. Don't over or
> undershoot. For me, using the "accelerated scrolling", it's almost
> impossible and takes forever to get there. Using the scrollbars,
> it's trivial and extremely fast. I don't want to do this: hmm, if I
> hold down the mouse button for _just this long_, then the map will
> stop moving just where I want it. which is what it comes down to,
> see my previous post, if I wanted small map movement, I just right
> click to center the map, it's only for long movement which I use the
> scroll features. (maybe we should just waste scrolling altogether
> and make people click on the overview canvas?)  -mike

I suspect different people use the scrollbar for different things.  If
I'm interested in going to a specific spot on the map, I'll just use
the overview canvas as you suggest.  I use the scrollbars (and the
buttons, in the case of the patched version I'm testing) to look
around the area, which is much easier to do with the buttons or
scrollbars than with the canvas.

Of course, another way to do so is to use the centering button (right
mouse button) on the main map.  You can get around pretty quick that
way.

Seems to me that much of this is a matter of personal preference.  But
in any case, feedback from others like yourself on the effectiveness
of a feature like the scroll buttons is very useful.  I agree that it
needs work, and that's why I'm asking for feedback.


Changes for this particular version:

        - Max scroll speed is (map width + map height) / 6
          tiles/second.  So it'll take you roughly 3 seconds on
          average to traverse the length of a map.  Fast enough?

        - The rate of update depends on speed of movement.  The faster
          the speed, the more often the updates, within limits (see
          the next item).  So the scrolling should be as smooth as
          your system can handle.

        - It tries to account for how long it actually takes to update
          the map when figuring out how long to wait before doing the
          next update.  Also tries to use this information to figure
          out by how many tiles to scroll at one time.

        - Uses gdk_flush() after an update.  Otherwise, drawing events
          would be queued up in the X server and you'd get the
          overshoot effect you were talking about.

        - Found that gtk will sometimes lie to you about when a
          buttonpress event occurs (it'll report it more often than it
          should), so I track both presses and releases.  So pressing
          the button multiple times in quick succession should really
          work properly now (and not be off by one or so like it was
          before).


It's not perfect, and I don't know if it's possible to get it that
way.  My test environment consists of a Celeron 466 system with a
Matrox G400 running XFree86 3.3.6, which is a relatively fast graphics
environment (but not blazingly fast), and a remote VNC X session using
the Xvnc X server (which allows X clients to connect to it and
displays to a VNC client).  My VNC client is running on a Celeron 300
overclocked to 450.  The data gets transported over a 100mb
full-duplex connection.  Even so, there's enough data going across the
link that Freeciv under Xvnc is pretty slow, slower than your setup I
dare say.  :-)

Both environments are 32-bit, which certainly doesn't help the speed
any.

Point being, though, that I have both a relatively fast environment
and a rather slow environment to test in.  Hopefully this iteration of
the patch is better than the last.  Let me know what you think.


BTW, the code probably isn't pretty, but I wanted to get the UI bugs
worked out first.  Then I'll make it as elegant as I can.



-- 
Kevin Brown                                           kevin@xxxxxxxxxxxxxx

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

freeciv-1.11.10-gtk-scrollbar.patch
Description: Text document