Re: [AD] new GUI focus selection algorithm

[Eric Botcazou <ebotcazou@xxxxxxxxxx>]

> Ok, the attached patch implements it. Instead of using 0x10000 when
> wrapping around at the edges, I used SCREEN_W and SCREEN_H - since we
> already know that 'screen' is the bitmap the GUI is drawn to, I think
> this is quite a safe assumption about the GUI size.

What does this buy us? Nothing I'd say, and now we have further tied the GUI 
engine to the screen bitmap.

> The behavior from the collision algorithm can be closer to the original
> in case dialogs are ordered in left aligned columns, which probably is
> the case quite often. The new distance formula will cause jumps to
> another column quite easily, like:
>
> AAA
> BBB
>     E
> CCC F
> DDD G
>
> Here, going down from B will jump to E and not to C like in the
> collision approach, and also in the original formula. And in general,
> the closest distance jumps around too much for my taste, also jumping
> over other buttons:
>
>     CCC
>   BBB
> AAA     DDD
>
> Going right from A jumps to C, since B is not to the right of A. The
> collision approach of course never can jump and would go to D, and
> somehow behaves more predictable, at least to me :) And as Sven's circle
> example shows, there will always be unreachable buttons, since we have
> only 4 arrow keys, for unlimited possible directions to the next
> rectangle.

Two remarks:
- I think that using the Euclidean distance is too costly in terms of ratio 
benefit/overhead. After all, all distances are (mathematically) equivalent 
and we don't care if our circles look like squares :-)
- You should introduce a compile-time parameter in the distance formula so 
that we can tweak the relative weight of the two axes.

-- 
Eric Botcazou