(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.
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.