Complete.Org: Mailing Lists: Archives: freeciv-dev: September 2003:
[Freeciv-Dev] Re: Focus woes (PR#3390)
Home

[Freeciv-Dev] Re: Focus woes (PR#3390)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: ChrisK@xxxxxxxx
Subject: [Freeciv-Dev] Re: Focus woes (PR#3390)
From: "Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 16 Sep 2003 18:51:56 -0700
Reply-to: rt@xxxxxxxxxxxxxx

Per I. Mathisen wrote:
> # 3390: (per) Focus lost [open]
> # 1679: (vasc) Active unit not centered after eXplore [stalled]
> # 2324: (pagnin) Unit not in Focus [open]
> 
> We have some unresolved focus bugs that I think we should have a look at.
> #1679 contains some code that was judged too ugly to include, even though
> it fixed one problem, and maybe could fix the others as well.
> 
> I need some advice on how to proceed on this. I have tested #3390 and
> found that this bug is still present. I think the other two are as well.

This also relates to PR#4683 (allow pauses in client-side goto), which 
also has focus problems.

We need a consistent and clean method for determining which unit is 
focused.  This should

1.  Not prematurely advance the focus (this generally results in it 
being returned later, and the view jumps).
2.  Not keep the focus when it should be advanced.
3.  Not depend on the server doing the events in any particular order 
(as PR#1679 discusses).
4.  But the server can send us more data (like a punit->waiting value 
for client-side goto) to tell us what the unit is currently doing.

This should have been thought out better when fast-focus was done, but 
it wasn't so we have to do it now.  Doing this logic at the client is 
advantagous in many ways, but is much harder and more bug-prone.

jason




[Prev in Thread] Current Thread [Next in Thread]