main layout, scrollbars

[stengel]

The main page should have some containers (rectangles) for

• main button groups:
  • file new / load / save / export
  • game tree creation mode buttons: tree / players / info sets / moves / payoffs
  • output creation: equilibrium computation [future extension: other graphical displays]
  • settings, preferences
• the main tree drawing canvas (let's call it that even if we use SVG)
• the strategic form matrix layout canvas

Q: what happens when tree and strategic form become large? Options:

• expanding the canvas which gets scrollbars
• shrinking the tree/matrix and letting the user zoom in with the browser; this can only work with SVG because SMALLER fonts etc. will not zoom well when pixel-based; also, the other containers would also grow when using the browser zoom

I think the following is best: the drawing parameters of representing a tree or matrix are fixed irrespective of game size (but can be changed in preferences, or automatically adjusted e.g. for large numbers in payoff cells). These fixed parameters are:

• node diameter, level distance between nodes, height of information sets, line thickness (separate for the info set ovals)
• font sizes
• box size of a cell in strategic form

When the graphics is exported to XFIG, which I still want, it is also useful to have the same parameters such as line thickness irrespective of tree size. XFIG is an SVG format.

These "standard" dimensions have then to be mapped to the canvas, which requires scaling.

Currently, GTE offers zoom facilities. The resulting behaviour is nice, except that it also changes the proportion of the tree (it tends to get narrower when it grows) which I would prefer to control separately.

Proposed solution, to be tested:

The main canvas has a standard minimum size (which normally fills the browser windows except when that is too small), and grows in defined steps when the tree grows bigger (defined steps so as to avoid re-sizing the canvas for every small increase of a larger game tree). The browser takes care of creating the scroll bars for the entire page to avoid multiple confusing scrollbars.

[alfongj]

Regarding the last paragraph, it is possible to make it so the browser creates scroll bars for the canvas only, and not the whole page.

I believe this may be better than having scroll bars in the entire page (we can avoid these completely to avoid confusing scrollbars), as in the case that the game grew too much, it could be very inconvenient to click on the top toolbar buttons, if a lot of upwards scrolling needs to be done in order to reach them.

[stengel]

OK, the only thing I doubt is that we can avoid double scrollbars if a user presses the browser-magnify button. So far we never had really big trees.

[alfongj]

Oh, I understand your concern now.

I just thought about something that could be useful to address this case, however. There is a CSS property, zoom which, if applied to an html element, it applies a given zoom level to it, in the same way the browser would apply its zooming to a whole page when you press the zoom buttons.

If we decided to go for SVG, what we could do is to keep the zoom buttons from the old interface (and possibly create keyboard shortcuts for them too), and when pressed, just increase or decrease the zoom level of the "canvas" (i.e., the container of all the SVGs that represented the tree. This way we can avoid zooming the full page (including buttons, title, etc), and thus avoid having extra scrollbars around the full page.

[hvk3]

Would something like this work for zoom and pan? http://bl.ocks.org/benzguo/4370043