News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

GUI containers with auto repositioning&resizing for its contents.

Started by wackdone, July 11, 2012, 05:56:22 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

wackdone

I wrote two GUI containers (inheriting gui_container_t),
which holds some geometric policy and constraints of its contents (gui_komponente),
and does repositioning/resizing of contents when the container is resized.

These will make it easy to implement fancy-zoomable windows in Simutrans.
I'm using these for Timetable Viewer in my extension, TTT.

gui_packedlayout_t: (IS-A gui_container_t)
  It lines contents along either horizontal or vertical orientation.
  Contents may stretch to fit available space (if specified).
  The container can insert inter-component separation gap and container's border.

gui_gridlayout_t : (IS-A gui_container_t)
  It places contents at grid-based position. Each component in the container has
  coordinate on the grid (as a x-y pair of rational number)
  spanning width/height (as a w-h pair of rational)
  and some flags to control alignment, filling (resize component to fit it's span),...

Sample images are attached in this article.
These are view of same program. 1st is resized to minimum. 2nd is resize larger.
We can see that components are moved and zoomed while resizing of the top window.
Upper half of the window is layouted by gui_gridlayout_t.
Bottom button bar is layouted horizontally by gui_packedlayou_t.
And whole of the window is layouted vertically by gui_packedlayout_t.

Current code and sample usage will be attached latter article.

wackdone

Attached file is an archive of current code.
contents are:
  gui/comopnents/
    gui_packedlayout.{cc,h}     container with H/V packing layout.
    gui_gridlayout.{cc,h}          container with grid-based layout.
  gui/
    sample_layout_view.{cc,h}   sample code using there containers (output is show in images attached above)


There are many To-Be-Considered matters in the code.
class name, separation of classes, ...
class definitions of rational number, it may not be right place/file in source tree.
Why use rational number?  Why not use floating point real number?
and blah, blah, blah...

It will make more flexible architecture to separate 'container' and 'layouter'.
But the separation makes codes more complex, and may make the program runs with more instruction steps.
I think, GUI is not 'most important part' of the simulation, so this extent may be good enough.