[Freeciv-Dev] (no subject)

[dspeyer@xxxxxxxxxxxxxxxxxxxxx (root)]

I'm replying to both of you at once, I hope you don't mind ;)

kevin@xxxxxxxxxxxxxx,Internet writes:
>Mike Kaufman <mkaufman@xxxxxxxxxxxxxx> wrote:
>> On Sat, Aug 04, 2001 at 06:17:11PM -0400, Daniel Speyer wrote:
>> > Here is my proposed fix to the isometric scrollbar bug.  It does away
>with
>> > the scrollbars entirely and replaces them with eight buttons.  This
>is,
>> > IMO, much more elegant than scrollbars.  It also solves the
>difficulty I
>> > had when I first began using isometric of matching what happens on
>the big
>> 
>
>> hmm, I couldn't comment on its elegance, but either you must be
>> working on an extremely fast computer, or your implementation is
>> broken. I'm working on a PII 266 and scrolling is _incredibly_
>> slow. I hardly ever use the scrollbars anyway, I just click to
>> center map. This is mainly why I'm skeptical of your solution. When
>> I do use scrollbars, it's to move the map a _long_ way very
>> quickly. I can't seem to do that with your buttons. Also I have to
>> click for a relative long, uncomfortable time to get the screen to
>> move period (which I imagine is caused by your use of the idle
>> function (why oh why), and also why the canvas inches along bit by
>> bit while I'm not clicking anything--very annoying).
>
>I think I've addressed all these issues with my patch.  See my
>response to Daniel elsewhere in this thread.
>

Using timeouts instead of gtk_idle is definitely a good idea (I now see I have 
yet to really learn GTK).  If the performance isn't improved enough on old 
hardware (maybe I should start developing on my brother's PII-200 ;) ) then we 
could add a small multiplier factor in map_scroll.

>> Also, the fact that you ring the canvas with buttons reduces the
>> screen real estate. That's just one more thing for those of us
>> without 21in monitors.
>
>I suppose this could be done with a button matrix located somewhere
>near the map...
>
I don't think the screen-space loss is significant (I'm running on a 15" 
monitor (1024x768), not maximizing the windows.)  I just ran a scrollbarred and 
a scrollbuttoned client side-by-side, and the loss isn't much.  It might be 
worth tweaking padding and font size, thouh, especially for the top and bottom 
buttons.
>> I think that if the reason you wanted this is the "inconsistency"
>> between map canvas and overview canvas, instead maybe attempt to
>> rotate the overview canvas.
>
>I think the reason he wanted this is because the original scrollbars
>would move the map at a 45 degree angle relative to the scrollbar
>direction, which is not at all intuitive.  But I'll let him speak for
>himself.  :-)

The 45 degree issue is the main reason.  I also wanted to deal with the problem 
of unalinement and treaty negotiation (actual dialog: "let's put the border 
running north south from the wheat/river" "which way is north?")

>
>Actually, I rather like his solution.  Wonder if there's a way we
>could make this into a runtime option or something...
>

A runtime option would be easy enough.  Just declare both sets of variables and 
callback functions, then put a big if/else in gui_main.c.   We'd have to add 
some way to switch between them, probably a command line argument, but that 
wouldn't be too bad.

>
>-- 
>Kevin Brown           kevin@xxxxxxxxxxxxxx
>
>    It's really hard to define what "unexpected behavior" means when
>you're
>                       talking about Windows.
>
>

--Daniel Speyer
Firmware: instructions to a computer
Software: instructions to a computer that the user can change
If you don't have the source, it's not software.