Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Author Topic: Request - Menus that adapt to screne size  (Read 348 times)

paxanadu

  • Bay Watcher
    • View Profile
Request - Menus that adapt to screne size
« on: May 07, 2010, 06:07:46 pm »
What happens when you play on a 1920x1080 screen?  Your menus don't get bigger, you still must scroll and scroll and scroll to get at the menu item you want.

If the menus, instead of being "fixed", too into account just how big (i.e. "high") the screen is, larger screens would allow much more bigger lists to be displayed.
Logged

zagibu

  • Bay Watcher
    • View Profile
Re: Request - Menus that adapt to screne size
« Reply #1 on: May 07, 2010, 06:53:06 pm »
Yeah, Toady already has the information in init.txt about how many tiles there are horizontally and vertically, so it shouldn't be too hard to implement.
Logged
99 barrels of beer in the pile
99 barrels of beer!
If some dwarves know the way to the pile
0 barrels of beer in the pile!

paxanadu

  • Bay Watcher
    • View Profile
Re: Request - Menus that adapt to screne size
« Reply #2 on: May 07, 2010, 07:20:21 pm »
Exactly.

Well, as far as "not too hard" goes, it would depend a lot on how those menus were coded. 

If they all share the same code but that code is perfectly modular:

say menu structure is itself something defined in .txt files so that:

1) the called-functionality of menu elements (in game functions that do tings like setting labor, renaming dwarves, etc.), sometimes called an API (application programming interface),
2) the user interface structure of the menu elements presentation (in which order and sub-orders and lists and columns the menus elements are positioned relative to each other),
3) and the actual way that the user interface works (the GUI -- how the user interacts with "a list column", without specifying WHAT is in that column) , 

are all separates modules of the application, then it should be *relatively* more or less easy to do -- only the actual GUI fonctionality would need an update and a single change would sweep all over the game. 

Bit if Today doesn't do touch OOP (object oriented programming) and *each* menu is hardcoded completely separately (i.e. say there is such things as a function to display the designations menu, which takes charge of displaying that menu, with its specific elements, in their specific order, and treating user input to directly call the relevant sub-functions that changes variables and values in the game), well then the interior functionality, the API, and the GUI would all 3 be an unextricably meshed mess and changing the whole thing would be much faster than changing each component, in which case I guess we'll have to wait for the next major menu rehaul then...

Logged