The International Simutrans Forum

 

Author Topic: Automatic gui patch  (Read 3529 times)

0 Members and 1 Guest are viewing this topic.

Offline Dwachs

  • DevTeam, Coder/patcher
  • Administrator
  • *
  • Posts: 4493
  • Languages: EN, DE, AT
Re: Automatic gui patch
« Reply #70 on: December 01, 2018, 03:48:18 PM »
Thanks for testing!
  • Possibly has nothing to do with your patch: The rectangle in the map that shows you where you are gets distorted if a corner is outside the map.
Has nothing to do with the patch. This happens if the rectangle is on hilly terrain, it is distorted to get an approximation of part of the map is visible.
  • Inspection windows, which could not be rescaled before, now can. However, line breaks don't change, so making the box broader does not help with long text.
Line breaks are from translations. I will remove possibility to resize.
  • In the factory window on the details-tab, when you expand the window, lines of text get longer. However, if you make the window smaller, they don't change.
Noted.
  • You are now able to drag a dialog so far down it's title disappears behind the bottom info line, but you can't grab them once they are there. Same is true with the ticker, which also displays artifacts as already mentioned. I'm not entirely sure how I would get my messages-dialog back in the visible playing field, any ideas? I did not test that yet :(
I hope that this has nothing to do with the patch. Does this happen for trunk as well?
  • In the dialog to build an industry, the list of industries does not scale it's wideness. Technically, the info to the right doesn't either, but that's only visible if it's so short a scrollbar appears, and I'm not sure that side is even required to scale at all.
I am not sure whether I understand you correctly: you want the window not be resizable? Or you want the columns in the window to scale their width?
  • In the dialog to build a curiosity, descriptive text does not auto-break. (also that's one of the worst "initial window sizes", see below)
Changed the patch to break the text.
  • Changing the sorting in the goods-list makes it so it does not spread over the window size anymore.
I do not understand: after changing sort order what goes wrong?
  • In the finance window, when you click with the mouse in the graph to see older values, the value flickers.
I cannot reproduce.
  • If you change the station names to be displayed in yellow with a square of the player color to the left, the square reaches into the name if the font is larger then the default. [I mean, I never used that, and I don't know anyone who does, and the outlines of the yellow text are naturally disgusting at that size anyway, but it's there, so it needs to be supported]
Sure its a bug. But not in the patch :) will fix it.
  • Changing font sizes is very funky. If I'm on a ttf font on scale 19 and change it to 18 (using the scroll wheel, not sure if that affects anything) the font actually becomes bigger. It becomes smaller when I go to 17, and then smaller once again when I go up to 18.
  • Also, would it be possible to keep font selection when changing languages, or is that impossible due to non-latin writing systems?
Fixed in next version of patch.
  • The build-industry dialog changes it's wideness automatically according to the building preview, which now features the complete building. One should be aware that there are ridiculously large buildings: In P192C, it's the oremine with 6x6, which causes that dialog to fill more than half of my screen (3840*2160). I really like the full-view buildings and would even ask to display upper layers and frontimages, but only if there was a way to restrict them in size. Would it be possible to define a minimum area of a tile-sized square and not draw any part of the building outside that area, making the appearence in the smallest window similar to how it was before, but show more of the building if the window is rescaled?
You are right. Will think about this.
  • Maybe that's already possible via themes by now, but I really think there should be a "GUI-Scaling-Factor" that changes the default size of dialogs. I used the largest font size (18 - see above) and the larger theme to open the goods list, and in the initial window size I only saw pax and mail, and of those not the weight. The goods list does not retain size, so I always have to resize it for it to be of any use.
There is no initial window size. The windows are opened at their smallest possible size, which is not ideal.
  • Similarly, some elements drawn by the game would need scaling as well. Eg. in the finance window, it would make sense to use a two-pixel line and larger dots, or the lines of goods waiting in a station in the overworld.
This should be possible with a theme (not sure)

Offline Dwachs

  • DevTeam, Coder/patcher
  • Administrator
  • *
  • Posts: 4493
  • Languages: EN, DE, AT
Re: Automatic gui patch
« Reply #71 on: December 01, 2018, 04:34:58 PM »
Fixed some of the bugs mentioned above in trunk r8646: black preview in server selection window, glitch when displaying station names with boxes, font reset when closing language dialog, moving windows out of view.

Offline Leartin

  • Devotee
  • *
  • Posts: 1079
  • PAK-DEV P192C
  • Languages: DE, EN
Re: Automatic gui patch
« Reply #72 on: December 01, 2018, 04:52:32 PM »
Line breaks are from translations. I will remove possibility to resize.
See attachment. If large text and a large pakset are combined, long words like "Passagieraufkommen" don't fit anymore. It's the same old curse that plagues p192c before, now fueled by large text.

I hope that this has nothing to do with the patch. Does this happen for trunk as well?
I only compared with R8600, where it is not possible to drag a dialog behind the bar, it would always stick a few pixels out.

I am not sure whether I understand you correctly: you want the window not be resizable? Or you want the columns in the window to scale their width?
For the left side, the list of object already scales a bit, but only up to the longest word in the list, which seems strange to me. I would expect it to either not scale at all and require the space it needs as a minimum, or if it does scale not to have a max size at which it stops. And if it really has to stop scaling, at least stay at the left, rather than the center of the column, so switching between translation and object-name is less awkward.

I do not understand: after changing sort order what goes wrong?
If you resize the window, the columns all spread out evenly. But if you then change the order, the columns go back to their smallest possible size. See attachments.

Offline Dwachs

  • DevTeam, Coder/patcher
  • Administrator
  • *
  • Posts: 4493
  • Languages: EN, DE, AT
Re: Automatic gui patch
« Reply #73 on: December 01, 2018, 06:53:19 PM »
See attachment. If large text and a large pakset are combined, long words like "Passagieraufkommen" don't fit anymore. It's the same old curse that plagues p192c before, now fueled by large text.
What would be a solution to this? One can make the window at least such large that no words are broken.

Offline Leartin

  • Devotee
  • *
  • Posts: 1079
  • PAK-DEV P192C
  • Languages: DE, EN
Re: Automatic gui patch
« Reply #74 on: December 02, 2018, 09:57:35 AM »
What would be a solution to this? One can make the window at least such large that no words are broken.
I don't think there is an automatic solution. Even if "Passagieraufkommen" is not broken, it still wouldn't be ideal if the actual value is in the next line; and there is a nice uniformity with those dialogs all having the same width.
Note that this problem only exists for dialogs which may contain long text intended to be broken, like descriptions. Dialogs which only contain single words at a time, like the display menu already scale automatically to not have any broken words.

I see three possible solutions:
1) Again, the "GUI-scaling-setting". You said windows always start at their minimum size, but for those tiny dialogs, the minimum size isn't determined by the actual text length, but by a magic number that used to work with the default font. Allow that number to be tweaked via settings or theme, if you use a larger font, you adjust your GUI-scaling such that as much text fits in as before.
2.) Same as #1, but instead of an additional setting, it reuses the selected font size. If you use 18pt-font, scale the magic numbers by 1.8, anticipating that the font will need 1.8 times the space of the original font (which is 11pt, but it's easier to calculate with 10)
3.) Best solution I can think of: The game could remember resized windows . It already does that for the map, although not between sessions (?). This way, it would be most customizable for players - whenever a window looks strange to them, they resize it, and next time it looks exactly as they want it to look.

Offline Leartin

  • Devotee
  • *
  • Posts: 1079
  • PAK-DEV P192C
  • Languages: DE, EN
Re: Automatic gui patch
« Reply #75 on: December 02, 2018, 01:41:47 PM »
Another tiny one: The selection arrows are placed to the right based on how much space the text needs, but the positioning only considers the text shown when the dialog is opened. Select a longer option from there, and text will clip the arrow.

Though this selection is inconsistent by itself. In every other case where the arrows are used, it's also a dropdown-box where you can choose from. (eg Filter in the depot) or just numbers; otherwise it's a button that flips states (eg. sell-append-front in the depot). Perhaps it might be best to simply eradicate this kind of selection altogether and replace it with one of the other two choices?


Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9309
  • Languages: De,EN,JP
Re: Automatic gui patch
« Reply #76 on: December 03, 2018, 05:32:06 AM »
That was a quick hack from the time when only a single combobox was possible and they were cumbersome to use; maybe indeed a combobox would be best here.

The inspection window linebreaks are created on the fly, they are not from translation. If your house would have a useful description, "Passaieraufkommen" would have been below the image and not broken apart. Hence a reflow is entirely possible when resizing. The gui_fixedwidth_textarea_t just need to know its new size ...

But I liked the idea of the current code that there is a configurable default window size, which windows are all opened initially. Maybe this would be a useful simuconf.tab default parameter (like the font ... )
« Last Edit: December 03, 2018, 05:57:02 AM by prissi »

Offline Dwachs

  • DevTeam, Coder/patcher
  • Administrator
  • *
  • Posts: 4493
  • Languages: EN, DE, AT
Re: Automatic gui patch
« Reply #77 on: December 06, 2018, 04:55:30 PM »
@Leartin: converted these arrow-selection to drop-down selection.

I still have to think about those flow-text containers.

Also, I like the idea to save the window size for each type of window and use it next time such a window is opened.

Offline Dwachs

  • DevTeam, Coder/patcher
  • Administrator
  • *
  • Posts: 4493
  • Languages: EN, DE, AT
Re: Automatic gui patch
« Reply #78 on: Today at 07:46:35 AM »
Did anybody test the patch with non-European languages like Japanese/Chinese?

The idea of the patch was that the program can figure out itself what initial size of any dialogue window should be. Still there is the problem with text elements: How to determine the size of flow text elements? I.e. elements that can adapt to any width?

Offline Leartin

  • Devotee
  • *
  • Posts: 1079
  • PAK-DEV P192C
  • Languages: DE, EN
Re: Automatic gui patch
« Reply #79 on: Today at 12:12:12 PM »
I did test with Korean for a bit, but did not see any specific problem.

I was under the impression that the patch should allow rescaling in general, by determining the minimum size of each element for it to not cause trouble. For flow text elements, the minimum size would technically be "enough to show one letter and a scrollbar".

This is a different issue from the size that windows should be opened. Personally, I think saving the user-set window sizes during gameplay is actually enough. My thinking here is that whenever someone starts the game for the first time, it would always start with the small theme and the old, unscalable font. We already have the sizes pre-patch to get an idea of how large windows with that font and small theme should be. Those would be used as the initial values for the saved window sizes.

That being said it still needs exploring about how to allocate space within a window. It seems to me that flow text would have priority over other elements, meaning that if extra space is available, it would be always used to expand the area for the flow text first, meaning elements that contain flow text would have priority as well. Every other element would then use the full space available to it, which is currently not done everywhere:
When you have a station window open and add an extension such that the capacity rises enough to require another digit, there is not enough room and you get three dots (...) instead, but it's fine if you reopen the window. So I assume the space allocated for that line ends at the minimum required space when you open it and does not get reallocated if the text changes. But I fail to see why not the full space up to the image on the right becomes reserved for that text.
When you start a new game, all the boxes for numbers have the same size, except for the city size. Since it's a two-column design, only the largest box size matters, so if all boxes had the same size, you would lose not a single pixel of space for text, and only gain uniformity. But more upsetting is the field for the map number, which has  a minimum size smaller then the largest number you could put in, and rescales when you make the window larger, even though there would have been space for it before. Especially since the map preview does not change it's shape when you change the map size. I can't quite make sense of that behaviour.

A bit more complicated would be the "place citybuilding" dialog, you currently have a two-column layout with even-sized columns, whenever one expands, the other does as well. Since you have flow text in the right column, I'd suggest that resizing the window should instead only expand the right column with that flow text, leaving the left one in it's minimum size. But since the preview now shows the whole building, it would not work as well with multi-tile buildings like curiosities. However, this could be solved by rearrange elements. Put both the list of objects AND the filter options for which elements to show in the list in the left column, above the list. This would make sense anyway, since those belong together. Then, you can place the preview on the bottom of the right column, beneath the buildings information.
This would go back to my idea from before: "Would it be possible to define a minimum area of a tile-sized square and not draw any part of the building outside that area, making the appearence in the smallest window similar to how it was before, but show more of the building if the window is rescaled?" In other words: Treat the preview image as if it was flow text, just without scroll bars.

I attached mockups. The first one is just the arrangement, the second is when there is less vertical space - for the flow text, scrollbars appear, and the image is reduced to 192px height with extra "cutoff"-lines. Same would happen to the sides with larger buildings.