[Adonthell-devel] Re: Scrolling

[Kai Sterker]

On Sun, Nov 7, 2010 at 1:33 PM, Kai Sterker <address@hidden> wrote:

> Starting with that simple premise, I'd model it like a viewport in
> Java. In terms of our GUI class hierarchy, it would be a layout that
> can have exactly one child (another layout). Being a layout itself, it
> can act as a toplevel window, reducing the amount of nesting that
> would become necessary otherwise.

First (working) code is checked in. Quite a few things changed, so
better do a complete recompile. Then test with worldtest -g
../../adonthell/test data and talk to the NPC.

As you see, there are no actual scrollbars yet and you cannot get back
to the very top of the view once you scrolled down a bit. Since I'll
want to rewrite the conversation dialog in Python anyway, I didn't
invest much time in changing it now.

Next bit is actually rendering the scrollbars. Not quite sure yet
whether to add the scrollbar rendering to the decoration class (and
thus the style XML files), or rather keep it separate.

As I envision a scrollbar as a separate widget (possibly with two
child buttons in the future for mouse scrolling), I might implement a
special scrollbar_decoration that uses the normal background and
border gfx for the fixed scrollbar backdrop and adds another set of
images for the dynamic slider.


Another thought I'm playing with is adding a list_layout that's more
suited to display out list of dialogue options (and similar sets, like
saved game slots and such). Unlike the layout base class which
requires absolute positioning of all its elements, it should arrange
them automatically, either top to bottom or left to right. Also should
wrap around the selection once you moved past the beginning/end of the
list.

OTOH, I kinda wanted to keep the GUI stuff lean and simple. Just don't
know if its better to go with fewer, more flexible classes or rather
have more specialized classes. Right now I'm leaning more towards the
latter, as it keeps the implementation of the individual widgets /
layouts simpler.


And finally, it occurred to me, that we do not have an "image" widget
yet. So no way to display NPC portraits or thumbnails for the saved
games. Again the question, update the label class to hold an optional
image, implement a set_background method in the base widget class and
simply "fake" an actual image widget that way, or implement a true
image widget (as we had in v0.3). Guess I might go with #2. Might be
useful to dynamically change the background of any widget. And it only
adds one additional method to the API :-).


Opinions and ideas welcome, as usual. Testing too. And not to forget
actual new and nice GUI designs and graphics :-)

Kai