On Sun, Nov 7, 2010 at 1:33 PM, Kai Sterker <kai.ster...@gmail.com> 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 _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/adonthell-devel