adonthell-devel
[Top][All Lists]
Advanced

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

Re: [Adonthell-devel] Re: Some optimization ideas


From: Kai Sterker
Subject: Re: [Adonthell-devel] Re: Some optimization ideas
Date: Sun, 6 Mar 2011 12:35:24 +0100

On Sun, Mar 6, 2011 at 11:35 AM, Josh Glover <address@hidden> wrote:

>> Aside from the glyph caching, there are some more things to fix up too:
>
> I might have a bit of time today to work on something small, if you
> can point me at it. :)

Most things that come to mind aren't really small. But among the
useful and possibly not that big open items are

* GUI Python wrappers: they need an update for the newly added GUI
classes and some testing. I.e. writing some GUI code in Python and
check that it works. See src/python-wrappers/adonthell/py_gui.i

Or, if checking out details of SWIG is too much work already, there is
still some more work left on the GUI side. This may require some
thought, but I wonder if might need a list_item widget that is
basically a layout with the purpose of grouping several other widgets.
A regular layout would pass focus to one of its children. So only one
of its children would be properly indicating focus and navigation
would be strange. Also, you wouldn't be able to "select" such an item,
as layouts don't react to the appropriate key. Only buttons do.

The reason I'm thinking about such a widget are both the dialogue
window and the load/save screen.

For the dialogue window, I wanted to display a number next to the
player choices, so that pressing that number on the keyboard would
also select that choice. To make it look better than with the current
test dialogue (worldtest -g ../../adonthell/test data), the number and
the player choice need to be different labels, but grouped as a single
item in the list.

For the load/save screen, in v0.3 we have the thumbnail, the timestamp
and an editable description of the saved game grouped together in a
list. Again, I don't think that's something we can do right now.

What should do the trick is inheriting from gui::layout, with a
customized focus handling. (override layout::focus, layout::unfocus),
a callback to notify of selection like in gui::button, and possibly an
override of layout::draw to draw all children as if they had the focus
if the list_item itself has the focus.

Updating the conversation widget with separated number and player
choice label would be a nice testcase.

Kai



reply via email to

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