Touch Friendly UI

[An_dz]

So I started messing with the Simutrans code. I'm working on a Touch friendly interface. I've been working on this for some time and it has enough dialogs done. I also translated some German comments to English.

The goal is make Simutrans interface touchable but also enhance it for non-touchable devices. I know ӔO have a surface pro, but his screen is '208dpi' while mine is '101dpi'. He can try disabling High DPI settings in compatibility tab in file properties. (Simutrans will probably look blurry, but buttons will have the right size)

Some features

• Open main menu buttons only if clicked and released in same button
• Main menu scrollable with click-drag when window size is smaller than menu
• Enlarged buttons, checkboxes, title bar and other elements for touch devices.
• Rearranged windows to be usable from 320x480 (iPhone 1 size/iPhone DPI may be a problem).
• Depot window is way smaller, giving more area for the map.
• Changed fixed numbers that represented title bar height to its variable D_TITLEBAR_HEIGHT
• Translated some German comments to English (Some that I could understand), plus fixed some typos for English
• Run title bar button (gadget) action only if clicked and released in same button (gadget)
• Window will rollup (minimize) with double click in title bar too
• Changed some bottom bar info when screen is smaller to fit the required info and don't overlap text
• Changed the banner text colors, I think they are more readable and soft.

Somewhat complete dialogs, some are still buggy: (dialogs outside this list are totally incomplete or almost)

• Banner
• Main Menu (Options) - Image2
• New World
• Climates
• Network (online) game
• AI options
• Citylist
• Convoy
• Depot
• Stations
• Company Colors (when window width is too small)
• Player list
• Signal spacing
• Sound settings
• Station facing selector
• Traffic light

Little todo list:

• IPhone Landscape mode
• main menu don't move on window resize - werkzeug_waehler
• break text in halt_info and convoi_info
• add capacity bars in halt_info

Download
You'll need a new menu skin, place the file menus.WindowSkin.pak in skins folder (will only work for paks without Window Skins in pak folder). For pak96.comic, copy menus.WindowSkin96.pak to pak96.comic folder.
When you go play standard Simutrans, remove the new skin files.

New window skin
Window GDI executable
Patch file

[Dwachs]

Nice Gratulations for making a patch

Some comments from the top of my head:

(1) Could create a branch off aburch/master at github? This could make it easier to merge parts of your code, see (2)

(2) These translations can very well be submitted to trunk, if you supply a separate patch for this. Imho header should not be touched, they should be unified for the whole project in one go.

(3) It would be much more convenient and would increase merge chance and maintainability if you could use the constants in gui_frame.* and just increase / double their value. Then you do not have magic multipliers scattered through the code. And one could make this constants configurable by user / pakset without modifying the code.

[Markohs]

Nice work!

I'd point a few ideas/concepts:

* You already know for sure but file load/save dialogs look very weird now, that needs fixing:



* Even this changes make for sure the game way more playable in touch screens, the visual elements look certainly too big for a desktop computer screen. Using constant macro definitions of sizes looks like a too unflexible way to implement this, maybe it's time to layout all those sizes in a "theme" concept and be able to switch it in-game? We can't trust for example a Windows 8 machine not being a touchpad nowadays, distributing two executables one for desktop and another for pad might not be a good solution. Can't we extend the "theme" concept in simutrans fto make it more flexible?

* Dwachs suggests making this variable dimiensions configurable in each pak. I'd go farther and create a "theme" concept, that whould be applicable to the game. So you can install paks *AND* themes. A theme designed for touachpads, another for maybe phones and another for desktop computers. And being able to switch them on the fly, in-game.

[VS]

Absolutely +1 for all Markohs points. Extending skins to include the numbers for layout and everything else would be just great Of course, a question is who will write all that? So I'm just saying this would be nice...

[Markohs]

I volunteer to implement this once I finish the world slopes code, but if anyone wants to implement it ofc I don't have any problem finding other project to do. I also fancy having a look to Ters last OpenGL code and try to extend it.

[prissi]

Many dialogues are already scaleable using the constants from gui_frame. Hajos current IronBite uses them everywhere and did almost the same. Most of the list windows are missing, but they are anyway in for an overhaul. Thus the actual work might be even less.

However, there are two main settings (apart from icons, which were scaleable for ages). Those are the LINESPACE and BUTTON_HEIGHT stuff in gui_frame as mentioned by Dwachs. In order to properly support LINESPACE, the usage of the freetype library should be really considered, as it would result in proper font sizes for larger GUI elements.

However, this really forbids magic constants (like you did for the display of the status line for instance) and requires dynamic resizing (and caching).

The magic constants can be very easily set by simuconf.tab. One could easily add a dialoge at start time that (when the new version was detecteded) ask first if this is a touch device and only then for the language. Even paks could be replaced afterwards. Just close all dialogues and reopen them.

But I still see a problem with the GUI: How do you build rails? It was difficult enough with the old click start/click end, when one actually saw the tiles the cursor was on. How do this now? And how to scroll with a single finger. Surely drag and click has to go too.

[TurfIt]

Random thoughts:

Why add a 'main menu'. It's just yet another screen to click through.

The depot window was slightly shrunk in the overhaul I did. This patch makes it even bigger than before. Vertically that is; The complaint has always been it was too tall...

convoi -> convoy is not a valid translation. I can't really think of a nice simple English word substitution for convoi here. But convoy is most definitely wrong.

Translation strings were specifically left as "Power: %4d kW\n" rather than being split to "Power:" and "%4d KW" after much discussion on the subject...

I see several spots where this patch simply changes a fixed size to a different one. All size/positioning constants need to be moved to variables, and all sizing/positioning calc based on those and actual get_size calls of the elements. Things have been slowly moving this way, but as I'm sure you've discovered, it's rather tedious, and hence slow work.

[An_dz]

(1) Could create a branch off aburch/master at github? This could make it easier to merge parts of your code, see (2)

Sure, just branched Simutrans code in GitHub.

(2) These translations can very well be submitted to trunk, if you supply a separate patch for this. Imho header should not be touched, they should be unified for the whole project in one go.

You prefer a patch file or a GitHub pull request?

(3) It would be much more convenient and would increase merge chance and maintainability if you could use the constants in gui_frame.* and just increase / double their value. Then you do not have magic multipliers scattered through the code. And one could make this constants configurable by user / pakset without modifying the code.

I see several spots where this patch simply changes a fixed size to a different one. All size/positioning constants need to be moved to variables, and all sizing/positioning calc based on those and actual get_size calls of the elements. Things have been slowly moving this way, but as I'm sure you've discovered, it's rather tedious, and hence slow work.

I changed a lot of values to gui_frame.* Constants, specially for setting margins. Some windows I changed the height calculation for set_fenstergroesse() using a 'y' variable. There are some parts, specially for setting widths, that still use fixed numbers.

* You already know for sure but file load/save dialogs look very weird now, that needs fixing:

Yes, that's why I included a list with the dialogs that have enough changes.

* Even this changes make for sure the game way more playable in touch screens, the visual elements look certainly too big for a desktop computer screen.

I like the big buttons even for my non-touch laptop, but that's me. I think they are easier to click with a mouse now.

Using constant macro definitions of sizes looks like a too unflexible way to implement this, maybe it's time to layout all those sizes in a "theme" concept and be able to switch it in-game? We can't trust for example a Windows 8 machine not being a touchpad nowadays, distributing two executables one for desktop and another for pad might not be a good solution. Can't we extend the "theme" concept in simutrans fto make it more flexible?

* Dwachs suggests making this variable dimiensions configurable in each pak. I'd go farther and create a "theme" concept, that whould be applicable to the game. So you can install paks *AND* themes. A theme designed for touachpads, another for maybe phones and another for desktop computers. And being able to switch them on the fly, in-game.

It's a nice idea but needs hard work. One of the crappiest point are the High DPI screens. How's the best approach for giving the same size in cm for a button in any screen? I think Microsoft have an article giving some ideas, I'll see if I can find it again.

But I still see a problem with the GUI: How do you build rails? It was difficult enough with the old click start/click end, when one actually saw the tiles the cursor was on. How do this now? And how to scroll with a single finger. Surely drag and click has to go too.

Not having a touch screen device makes hard to know the actual behavior and how to change it, specially for scrolling.

Why add a 'main menu'. It's just yet another screen to click through.

The options page already have all the needed commands (New/load/save/scenario/online). I wanted to make the banner smaller.

The depot window was slightly shrunk in the overhaul I did. This patch makes it even bigger than before. Vertically that is; The complaint has always been it was too tall...

Maybe because it was to long too. - And I wanted it to fit a phone screen.

convoi -> convoy is not a valid translation. I can't really think of a nice simple English word substitution for convoi here. But convoy is most definitely wrong.

I'll revert/delete.

Translation strings were specifically left as "Power: %4d kW\n" rather than being split to "Power:" and "%4d KW" after much discussion on the subject...

I split so values are right aligned.

[Markohs]

The magic constants can be very easily set by simuconf.tab. One could easily add a dialoge at start time that (when the new version was detecteded) ask first if this is a touch device and only then for the language. Even paks could be replaced afterwards. Just close all dialogues and reopen them.

This imho it's a too simple solution. I'd say this values need to be dynamically changed and have to be treated as something different thnan game settings. I'd treat them as a "theme", or "skin" or "lookandfeel" concept, that whould be described on a different .tab, .xml or whatever format is chosen, but a differnt one.

About LINESPACE  and the freetype library you mentioned too, I think you are completely right and we should explore it. It *might* fix problems with non-latin lenaguages like thai I've read around that I'm not completely sure it has been fixed or not, and prolly other aspects of the game will be improved too.

EDIT: Elaborating this a bit more: this settings can be implemented with the already implementation of .tab files, no need to reinventing the wheel but imho have to be treated sightly different than current settings in the sense that the user should be able to select some preset settings and apply them in a whole ideally without the need of a game restart.

[prissi]

When saying simuconf.tab like, it could be another file. Dynamic resizing is not a big problem. One would just close everything and open it again. (Positions are already remebered, and dialogue save/load functionality is also on board.)

About power and values: You shoudl be aware that right aligned values may look fine to you but depending on font and language those may ratehr look wierd. Especially when there is a large distance between the power (or whatever) and the unit. Power (and most other) are only two Kanji at all.

[Markohs]

Yes prissi, it can be another .tab file. The idea is implementing whatever it's necessary to make the user able ti select wich .tab file he wants to read (in-game, and if possible displaying a pretty name, not "desktop.tab", "pad.tab" but "Pad Theme" and "Desktop default theme" and so on), and fill all the values that .tab file contains. Basically a widget to select wich theme has to be applied, so simutrans opens the .tab, and loads all its values. Optionally you can allow the user to modify that values individually himself too, and ofc load/save them as you pointed out.

I'd put those files in config/themes or something similar, and userdir directory too, to easen the installation of different themes. This whould be a good way to go imho, and ofc, being able to switch the skin used on-the-fly (I think this is not possible atm, but I might be wrong).

[prissi]

In priciple all image paks could be overloaded after creation of the world. In practice it collides with the landscape code, since it assumes the last images are the one generated by the landscape code.

But lets worry about this when we finally reach a working stage. For this any patch should be broken down, i.e. only using the existing constants (or maybe introducing one or two more at maximum) to get dialoges looking right at all sizes.

And again, line window and all list windows will get an overhaul soon.

[Markohs]

Yes, we better talk about that later ofc.

Anyway if skin paks have a fixed number of items that *must* include, we can make some new functions to be able to switch and load/unload them dynamically, this is not really hard. I can understand switching paks is very difficult almost impossible, but changing skin is very doable.

But yes, you are right.

EDIT: As this discussion it's related to the new GUI I'd propose something:

* All contant definitions need to be moved to a variable in settings_t:: or umgebung_t:: , or whatever you consider necessary.
* This variables should start with a common prefix, I'd say gui_settings_*

This will ease design and implement whatever we fancy doing later easier.

[Max-Max]

Ohh geee....

I'm doing the same thing.
After the advice from Markho, Jamespetts and neorden I moved over my work to the standard Simutrans. I just finished the transfer and continued...

I'm implementing all the aspects of

D_MARGIN_XXX
D_X_SPC
D_BUTTON_XXX
D_TITLEBAR_HEIGHT
LINESPACE
scrollbar_t::BAR_SIZE

...and some new...

D_GADGET_SIZE
D_ARROW_SIZE

It works with buttons on the left and right.

I'm trying to remove all magic numbers and some controls have their local #defines to tweak some parameters within the control itself. I'm also trying to be backward compatible with the current pak sets in regards of aligning the different skin pics.

How many of us are doing the same work in parallell?!?

[Ters]

Maybe you should try to keep right-to-left languages in mind as well. Even if you don't get it working, try not to do something new that makes it harder to do later.

[Markohs]

Yes,  I noticed you were both doing more or less the same but I didn't  pointed that to you because I don't think I should decide what you should do with your own time. :-)

but it would be nice if you both coordinate so you both make complmentary code. there is enough work for you both to split the work.

Personally I'd suggest  one of you focusing the conversion of macro constants into variables and its enumeration anf naming and maybe the other exploring the freetype library usage. You can also implement the theme thing I suggested,   the  in-game skin swap without need of a game restart.  Or something else. I just suggest issues. :-)

[prissi]

I woudl also suggest on going dialogue by dialoge (and some dialogues are already tweaked like that). THat woudl make duplicate work less likely and would also make debugging easier.

[An_dz]

The translations (what I could understand) and fixed typos are committed in GitHub as Dwachs said it would be better:
https://github.com/An-dz/simutrans/commit/f04c0abcca13d70fac817cfce866f5d9d872ae76

Edit:
I included some description of the file at the start of them as a documentation of what the file is about.

[Ranran]

This is my thoughts rather than a request as I never play simutrans on a touch screen.
I think that simutrans has some specifications that are conscious of playing on the touch panel. (And after a google search on touch panel simutrans, I arrived at this thread, so I'll post it here.)
I was playing Japanese smartphone games as usual and noticed that simutrans's current UI is a bad design that is not very suitable for touch panel operation.

Normally, the touch panel menu is placed at the bottom.
This is because the main screen is not hidden by your fingers or palm when you operate it.
Certainly older games often had menus on top.
However, even in recent simulation games for personal computers, it has become a common style to place the menu bar at the bottom.
And information is often placed on the upper side. simutrans is the opposite.

In my opinion, if simutrans really wants a touch panel-friendly design, I think it would be better to be able to place the menu at the bottom. (And move the info bar up)

I think that such an option is kind to people who play with the touch screen.

[prissi]

Thank you for the suggestion. That is rather easy. I will look into it.

We just need someone who make Simutrans SDL2 ready. There seems no easy way to do that. Maybe Cmake can help.

[Roboron]

Certainly older games often had menus on top.
However, even in recent simulation games for personal computers, it has become a common style to place the menu bar at the bottom.
And information is often placed on the upper side. simutrans is the opposite.

While having the bar at the bottom is definitely an improvement, changing it to the right (or left, if you are left-handed) is also more mobile-friendly.The lack of vertical space is a deal breaker here. While playing Simutrans on my Pinephone, I can't fully see some of the windows (e.g. the ones with graphs) because there's not enough vertical space (unless I rotate the phone), and moving the toolbar to the side can make a difference there (I also suggested in the past moving the info view to a separate tab).

An example is TheoTown, a city-building game for touch devices (later ported to PC).

[Isaac Eiland-Hall]

Would it even be decently possible to be able to choose a horizontal or vertical menu via an option somewhere?

[prissi]

r9796 add a configurable toolbar position (either simuconf.tab or with GUI under the display settings).

[Ranran]

Thank you for implementing it. It seems to be working fine. There is no doubt that it is a good improvement for those who play on the touch panel.

One thing I'm curious about is that, unlike my original suggestion, moving the menu bar down doesn't move the bottom bar up.
So if you place the menu bar below, there's an information bar just below it, which in my opinion feels a bit weird in design. (´・ω・｀)


One interesting point is that it may be possible to create a design with transparent buttons and bar backgrounds on the main menu bar.

An example is TheoTown, a city-building game for touch devices (later ported to PC).

So can we make something like the example Roboron presented with a menu on the left?

[prissi]

There has been some effort to do not waste drawing on the area behind the menu bar and thus the clipping in simview would need to stay the same for all orientations. But that is not so difficult. However, most bars needs vertical or horizontal scrolling, and thus holes would probably confuse rather the users.

Keeping the status bar at the bottom was just my lazy decision. Feel free to change it ...

[Ranran]

It seems to be working fine.

I was merging this into Extended and testing it, but I may have found a bug.


(1) Change the menu bar vertically. In my case, the vertical screen is short, so the entire menu bar is scrollable. So scroll it down.
(2) Then change it horizontally with the menu bar scrolled
(3) The button orientation is broken and I can't scroll. Also, some buttons cannot be pressed because the entire bar is not displayed.


The green locomotive button on the far left is not the first button originally.

I would appreciate it if you could check it as it may not have been merged correctly.

[Ranran]

Keeping the status bar at the bottom was just my lazy decision. Feel free to change it ...

I've tried changing the status bar to move up when the menu is at the bottom.

EDIT:
Revised the patch file.

Would it be better to make this an additional option?

[prissi]

Maybe, but I think there are rather too much options that just confuse people.

Somehow the patch did not apply in all hunks. Also, I think the toolbar clipping is already taken place by set_tooltip();

Incorporated, thank you.

r9805 also fixes the problem of wrong position after changing vertical to horizontal.

[Ranran]

r9805 also fixes the problem of wrong position after changing vertical to horizontal.

I tested it again, but I suspect that in the horizontal direction, only the image is now aligned to the "right edge".
There is a blank space on the left side, and the behavior and the position of the button image do not match.
It seems to work normally only when the screen width is narrower than the entire scroll bar.

This is the case when the window width is wide.

Pressing the left edge of the blank opens the settings dialog, but the floppy disk icon that originally opens it is in a different location.
The tooltip is in the correct position.
I tried deleting the setting file, deleting the save, etc., but I couldn't normalize it. I would appreciate it if you could check it.

[Roboron]

Additionally to what Ranran said, I can't see the mouse over any window nor the toolbar (it is still shown in the main view though)

[prissi]

Mouse issue: which OS, which backend. The mouse should be only an issue for Allegro builds (and those are not working right now I think).

[Roboron]

Mouse issue: which OS, which backend.

Linux SDL2.

EDIT. I tried again and this time it did show. False alarm?

[prissi]

Since the mouse is only drawn by Simutrans itself for the Allegro lib, I think that might have been a false alarm. However, SDL is very sensitive to the actual window size, so I would not exclude a possible error in an unlucky combination. However, I have just tried SDL2 build on WIndows (for r9811) and v\everything worked as intended, including scrolling the bars.

[Ranran]

At least it hasn't been fixed yet in my environment.

As already explained, there seems to be a problem with the toolbar image being right-aligned when the screen width is wider than the toolbar width.

Code Select Expand


if (wx < display_get_width()) {
tool_icon_disp_start = tool_icon_disp_end < tool_icon_width ? 0 : tool_icon_disp_end - tool_icon_width;
offset.x = display_get_width() - (tools.get_count() - tool_icon_disp_start) * env_t::iconsize.w;

The code apparently intends to be right-aligned the toolbar image offset when toolbar width smaller than screen width. I've fixed it and tested it, and it seems to work fine.
I attach the patch. Please confirm it.



And another problem:
If the dialog tries to move beyond the left or top edge, it will be SWALLOEWED to another dimension and will not reappear on the game screen until simutrans is rebooted.
The top edge is a dangerous trap that can trap noobs, especially if the toolbar is vertical.
When "the mouse cursor" that grabs the dialog moves to coordinate<0 (left or top outside of game window), the entire dialog suddenly disappears.

Perhaps a similar process may be required if the toolbar is at the bottom.



And one more issue:
The scrollable arrow on the toolbar is always displayed with the right and down arrows, regardless of whether it is scrollable or not.
It misleads players into recognizing whether the toolbar is scrollable.

[prissi]

OK, I hd not wide enough screens to find this. But offset.x is a pixel offset and tool_icon_disp_start is a counter of the first entry. Hmm.
EDIT: You had found the right place. FIxed in r9812.

The zooming to different dimensions is there longer, but it became now easier to do it. (Solution is closing everything with backspace and reopen.)

EDIT: at least for windows, the zooming is a windows error. According to docomentation the HIWORD(lParam) contains the y-coordinate. But HIWORD returns a WORD (uint16) while the relative mouse coordinate returned by windows can be negative. Hence the y coordinate could contain 65540 and higher ... Hopefully solved on r9813 at least for GDI. SDL returns an sint32 according to definitions.

[Roboron]

When I click the button to change the toolbar position for the first time, the second time I click it it does nothing (it doesn't even show the click animation), so I have to click a third time to actually change the toolbar position again.

It doesn't happen if I click somewhere else mouse the mouse slightly between the first click and the second.

Also, a question: Is there any reason this has been implemented as a button instead of a combobox(top, right, bottom, left)?

[ceeac]

Another bug: Since r9805, the headless server crashes immediately after startup with a division by zero error.

Code Select Expand


gui/tool_selector.cc:300:81: runtime error: division by zero
    #0 0x116fe3c in tool_selector_t::draw(scr_coord, scr_size) /home/ceeac/Projects/code/simutrans/gui/tool_selector.cc:300:81
    #1 0x111cb3f in win_display_flush(double) /home/ceeac/Projects/code/simutrans/gui/simwin.cc:1740:13
    #2 0x19e1f86 in intr_refresh_display(bool) /home/ceeac/Projects/code/simutrans/simintr.cc:83:3
    #3 0x1c37dd7 in karte_t::sync_step(unsigned int, bool, bool) /home/ceeac/Projects/code/simutrans/simworld.cc:3693:3
    #4 0x19e23ef in interrupt_check(char const*) /home/ceeac/Projects/code/simutrans/simintr.cc:114:17
    #5 0x1c92e1e in karte_t::interactive(unsigned int) /home/ceeac/Projects/code/simutrans/simworld.cc:7309:5
    #6 0x1a109dc in simu_main(int, char**) /home/ceeac/Projects/code/simutrans/simmain.cc:1585:9
    #7 0x1e9d9f1 in sysmain(int, char**) /home/ceeac/Projects/code/simutrans/sys/simsys.cc:1125:9
    #8 0x1fd4311 in main /home/ceeac/Projects/code/simutrans/sys/simsys_posix.cc:190:9
    #9 0x7fba843270b2 in __libc_start_main /build/glibc-YbNSs7/glibc-2.31/csu/../csu/libc-start.c:308:16
    #10 0x42c72d in _start (/media/ceeac/Projects/code/simutrans/build/client/sim+0x42c72d)


[ceeac]

The bug from the last post should be fixed in r9901.