[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Adonthell-devel] User interface open items

From: Kai Sterker
Subject: Re: [Adonthell-devel] User interface open items
Date: Tue, 21 Feb 2012 10:01:02 +0100

On Mon, Feb 20, 2012 at 11:57 PM, StyxD <address@hidden> wrote:

> Sound nice. So, does that mean the window manager will now be
> responsible for calling mapview::draw?

Yes. Both draw and update.

> By "map", do you mean world::area object?


> I'm not sure if it's a good thing to do. Areas have nothing inherent
> to do with gui elements, and windows aren't objects on the map.
> I imagined that speech bubbles and the like would be bound to objects
> by schedules and user scripts, when necessary.
> If a window was bound to a map or an object, it would still need to
> check the mapview, to see if it should be visible now.

The problem is the relationship between the objects involved. A
world::object is present on exactly one area. But one area could be
present in multiple mapviews (ignoring the somewhat simplistic current
implementation). So if you have a window bound to a character that
might be showing in multiple mapviews, in which of those should it

With my suggestion, it would appear in every mapview. With yours the
creator of the window would have to decide. But would he really know
about all existing mapviews? Or the mapview that will open 2 seconds
from now when the player casts a "distant view" spell?

By binding windows such as bubbles directly to a world::object, the
window manager can figure out if and when and where to draw them. It
would have to keep track of off-screen windows that way, but to a
certain degree it would have to do that anyway, as you can't know
where the player will walk next.

In practice, binding those windows to a mapview would probably be
sufficient for now, and it wouldn't be a big deal to expand that
later. So we might as well start with the simpler solution and change
it once we really have the need for multiple views.


reply via email to

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