Re: [Adonthell-devel] User interface open items

[Kai Sterker]

On Tue, Feb 14, 2012 at 12:27 PM, StyxD <address@hidden> wrote:

> Yeah, it seems mapview-relative coordinates would simplify things a
> lot for widgets bound to map objects. I was doing the translation
> manually, but with more widgets that would soon become cumbersome.
>
> It would also solve the problem of widgets going out of sync with the
> mapview once and for all.
>
> I suppose it could be done with a bool variable in manager_child and a
> mapview variable in window_manager. I'm not sure what would set the
> latter - is changing mapviews managed by schedules?

I could imagine that the window_manager could become responsible for
drawing (and updating) the mapview. Maybe handle it as a special kind
of window that could be added to the window_manager (since in theory
it would be possible to have multiple mapviews). Then any
mapview-relative windows would have to be drawn once for each mapview
they would be visible in. That would best match the design around the
separation of map, renderer and mapview. All information about size
and position of a mapview would be available in the window_manager.

Mapviews will normally be added from scripts (although right now a
single mapview is hardcoded in world::area_manager). I.e. when you
start a new game from the main menu, an initial mapview would get
generated at the end of an intro script. Saving a game could save
(part of) the window_manager state and automatically restore the
mapview on loading. Spell or item scripts could open additional,
temporary, mapviews (like using a telescope or watching the world
through another creature's eyes).

But the initial mapview would probably never change once set (unless
maybe some cut-scene script would remove it while showing). The map
displayed by the mapview could change, however, although right now the
idea is to have everything on the same map. Also, with the current
implementation, all mapviews would have to display the same map.

So maybe mapview-relative windows need to be bound to a specific map
or rather mapobject. Since mapobjects know the map they are on, this
could be used to decide if a given relative window is relevant for the
active map. And should we ever have a 1:1 relation between map and
mapview, this would still continue to work.


> Also, we'd need to consider, whether the mapview should be optional in
> window_manager, so that it would still work in cases when there's no
> mapview, like main menu. It would probably mean some kind of exception
> should be returned when the user tries to add a mapview-relative
> window when the mapview is not set.

Or the window_manager would simply skip drawing any mapview-relative
window when no mapview is available.

That would give us something like the following:

window_manager contains a list of mapview windows.
window_manager contains a list of mapview-relative windows, bound to a
specific mapobject
window_manager contains a list of regular windows.

Drawing will then first loop over the mapviews. For each mapview it
would loop over the mapview-relative windows and draw them, if they
are visible in the given view.
Finally, after all mapviews and mapview-relative windows are drawn, it
loops over the regular windows.

That should give exactly the z-order one would expect and keep all the
flexibility that was initially planned. (I guess area_manager has
somewhat taken away that flexibility, which wasn't really intented.)

Kai