News:

Simutrans Chat Room
Where cool people of Simutrans can meet up.

Automatic gui patch

Started by Dwachs, June 03, 2018, 03:30:42 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Dwachs

Thanks for testing!
Quote from: Leartin on December 01, 2018, 01:04:59 PM
  • 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.
Quote from: Leartin on December 01, 2018, 01:04:59 PM
  • 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.
Quote from: Leartin on December 01, 2018, 01:04:59 PM
  • 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.
Quote from: Leartin on December 01, 2018, 01:04:59 PM
  • 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?
Quote from: Leartin on December 01, 2018, 01:04:59 PM
  • 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?
Quote from: Leartin on December 01, 2018, 01:04:59 PM
  • 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.
Quote from: Leartin on December 01, 2018, 01:04:59 PM
  • 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?
Quote from: Leartin on December 01, 2018, 01:04:59 PM
  • In the finance window, when you click with the mouse in the graph to see older values, the value flickers.
I cannot reproduce.
Quote from: Leartin on December 01, 2018, 01:04:59 PM
  • 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.
Quote from: Leartin on December 01, 2018, 01:04:59 PM
  • 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.
Quote from: Leartin on December 01, 2018, 01:04:59 PM
  • 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.
Quote from: Leartin on December 01, 2018, 01:04:59 PM
  • 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.
Quote from: Leartin on December 01, 2018, 01:04:59 PM
  • 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)
Parsley, sage, rosemary, and maggikraut.

Dwachs

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.
Parsley, sage, rosemary, and maggikraut.

Leartin

Quote from: Dwachs on December 01, 2018, 03:48:18 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.

Quote from: Dwachs on December 01, 2018, 03:48:18 PMI 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.

Quote from: Dwachs on December 01, 2018, 03:48:18 PMI 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.

Quote from: Dwachs on December 01, 2018, 03:48:18 PMI 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.

Dwachs

Quote from: Leartin on December 01, 2018, 04:52:32 PMSee 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.
Parsley, sage, rosemary, and maggikraut.

Leartin

Quote from: Dwachs on December 01, 2018, 06:53:19 PM
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.

Leartin

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?


prissi

#76
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 ... )

Dwachs

@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.
Parsley, sage, rosemary, and maggikraut.

Dwachs

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?
Parsley, sage, rosemary, and maggikraut.

Leartin

#79
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.



EDIT: Another tiny thing: with large fonts, it can happen that the colored line above station names that indicates empty/used/overfilled is within the text.

Yona-TYT

Three details:

1 Clicking on the window preview box does not work.
2 The list in the schedule window should not start at "0".

3 The stops / stations are not marked when the "schedule" window is open.

Dwachs

Here is a new version. I fixed all the bugs mentioned in your tests above. Now the patch remembers size of windows. If in trunk, it will save these to settings.xml as well.

Some windows still need some love (new world, map editor building dialogues). But otherwise the patch is finished. As people are busy writing gui patches now, which are incompatible with this one, I would like to commit this rather sooner than later.

Windows executable (does not save windowsize to settings.xml to not kill your savegames): https://simutrans-germany.com/files/upload/sim-gdi-autogui-8650.zip

Patch: https://simutrans-germany.com/files/upload/scalable-gui-8650.zip
Parsley, sage, rosemary, and maggikraut.

Yona-TYT

The "Month wait time" values are not displayed well.

You should also add a drop-down menu, as you do in other filters.





Another detail in this filter.

Yona-TYT

I know I'm a little out of topic, but I'm having problems with the display settings window, it's too big for my laptop, I would be very happy to see some solution to this.   :-[

Regards!.

Dwachs

Any ideas how to proceed? I would like to commit the current version of the patch.

Then ugly windows can be redesigned. There is also the problem of how to determine the size of windows. Currently, the size of display is ignored almost completely, but should be taken into account.
Parsley, sage, rosemary, and maggikraut.

Yona-TYT

Quote from: Dwachs on January 31, 2019, 08:05:08 PMAny ideas how to proceed? I would like to commit the current version of the patch.

It would be good to solve the problem with large windows, some users (just like me) are going to have problems using the interface.

Dwachs

Yes true, but this patch cannot solve all the issues at once. It is one step towards a complete solution. I have the impression that people expect that this patch fixes all gui issues once and for all. This is not the case ofc.

As to you problems with large windows: There is almost no logic in the program to deal with window size depending on screen size. This is another patch.
Parsley, sage, rosemary, and maggikraut.

prissi


Leartin

I'm for submitting as well.
I mean, the actual work this patch was supposed to do is done, there is a system now.
Adjusting dialogs so they can harvest full potential of the new system is somewhat seperate, and perhaps an easier task.

Yona-TYT

Quote from: Leartin on February 01, 2019, 04:01:53 PMI'm for submitting as well. I mean, the actual work this patch was supposed to do is done, there is a system now. Adjusting dialogs so they can harvest full potential of the new system is somewhat seperate, and perhaps an easier task.
I think it's reasonable, I'll be waiting for this then.  ;)

Dwachs

Parsley, sage, rosemary, and maggikraut.

ceeac

Quote from: Dwachs on February 02, 2019, 04:56:03 PMsubmitted, in r8653

Compilation fails for me with GCC8 and DEBUG=3, OPTIMISE=1, PROFILE=2 in config.default with the following message:

===> LD  build/default/sim
/usr/bin/ld: build/default/gui/goods_stats_t.o: in function `goods_stats_t::update_goodslist(vector_tpl<goods_desc_t const*>, int)':
/home/ceeac/Projects/code/simutrans/gui/goods_stats_t.cc:40: undefined reference to `goods_stats_t::welt'
/usr/bin/ld: build/default/gui/halt_info.o: in function `gui_departure_board_t::update_departures()':
/home/ceeac/Projects/code/simutrans/gui/halt_info.cc:450: undefined reference to `gui_departure_board_t::welt'
/usr/bin/ld: /home/ceeac/Projects/code/simutrans/gui/halt_info.cc:450: undefined reference to `gui_departure_board_t::welt'
/usr/bin/ld: /home/ceeac/Projects/code/simutrans/gui/halt_info.cc:465: undefined reference to `gui_departure_board_t::welt'
collect2: error: ld returned 1 exit status
make: *** [common.mk:22: build/default/sim] Error 1

captain crunch

The applied GUI patch works for me, but it looks a bit ugly in places like lists, where there is too much left indentation and vertical space. Also in the save/load dialogs the "x" button for file deletion is quite wide, one could spell "delete" in its place.

Quote from: ceeac on February 02, 2019, 10:21:55 PM
Compilation fails for me with GCC8
You might have object files (*.o) from a previous compilation run, that are missing those symbols introduced with the GUI code.
If this is the case, try to "make clean" your source directory before running "make" again.

Dwachs

#93
@ceeac please try with r8661.

@captain crunch: delete button should be smaller with r8663. As to these lists: can you please be more specific? Please open a new bug report.
Parsley, sage, rosemary, and maggikraut.

ceeac

@Dwachs: Still does not work:

===> LD  build/default/sim
/usr/bin/ld: build/default/gui/goods_stats_t.o: in function `goods_stats_t::update_goodslist(vector_tpl<goods_desc_t const*>, int)':
/home/ceeac/Projects/code/simutrans/gui/goods_stats_t.cc:40: undefined reference to `goods_stats_t::welt'
collect2: error: ld returned 1 exit status
make: *** [common.mk:22: build/default/sim] Error 1

Dwachs

missed this one. please check r8664
Parsley, sage, rosemary, and maggikraut.

prissi

Thank you for your big effort. I tested it with a big font, and it improved usability a lot.

This patch compiles with MSVC but fails when opening a depot frame. The reason is that the initializers are not in the right order of declaration. GCC seems to reorder them as needed, but MSVC does not. I have tested the dialogues after compiling with MSVC, but I may have missed one. The headquarter info does not show up, or rather the frame appears for one second without content.

Some optical things: With a large font, the line management lower right side scroll pane is overlapped slightly by the left. Also there seems clipping issues with scrolling. And the comboboxes (i.e. for player selection, have half a line extra space at the bottom.) Also the depot seems to have a lot of extra space at the bottom.

What I find still not solved too well, is that the scrollboxes and tabs are not hitting the window borders. Maybe there can be a flag "fullwidth" for elements to force them to zero spacing to their surrounding. Also it looks weird, when the scrollbar is in the middle of a box (like for the station list). and the wasted space with the minimap is just annoying for people with larger maps.

And now suggestions: Since the factory and convoi details are now integrated into the factory info frame (which I like very much), I think it would make sense to move the halt details into the halt frame as well, since it now uses tabs anyway. (Even though now I lost the ability to see the departure board and waiting pax simultaneously, the tab based design is probably much better despite being modal).

Dwachs

Depot and line management window are *not* patched yet.

What does 'Depot frame fails to open' mean? It crashes?

Have to check your other comments tonight.

Edit: saw your commit now. Did this fix the supposed crash with depots? Strange that gcc did not issue a warning
Parsley, sage, rosemary, and maggikraut.

prissi

I think there is -lWreorder or so needed for GCC to warn. According to standard, the initialisation i in the order in the classes, derived first, and from to bottom. Hence GCC must do some different order, because the scrolly asks for sizes during initialisation, which would fail for initialised containers/componenets. Anyway, that was easy to solve, once I found the cause.

ceeac

Quote from: prissi on February 05, 2019, 03:10:05 PMI think there is -lWreorder or so needed for GCC to warn.
The -Wreorder warning is enabled by -Wall which is already enabled by default in the Makefile.

DrSuperGood

Dwachs I had to revert R8665 due to a potentially fatal dangling pointer. The pakset selector dialog is not fixed.

Details are in the commit.
QuoteRevert R8665. The dir_entry delete button is referenced separately by the button_frame member of savegame_frame. The method of replacement used by R8665 results in button_frame holding a dangling pointer and so can cause a crash when button_frame is drawn. One must either update the existing delete button of dir_entry, or add new methods to savegame_frame which consistently add and remove delete buttons.

Dwachs

@DrSuperGood: thanks for spotting. Should be better now (r8671)

Also the headquarter window should now work properly (r8672)
Parsley, sage, rosemary, and maggikraut.

prissi

#102
I integrated the line/convoi connections details into the halt window in r8719. (First try with the new system, so I may have triggered bugs.)

EDIT: But I still think it would be great if there is a flag for scrollpanes and tabs (or even an alternative adding routine) so the cam be added as wide a the dialoge and for scrollpanes as wide and a high as the remaning space.

Dwachs

For the table based layout, gui components are put into the (imaginary) table cells in the order they are added to the container. That is, if you remove or insert one component all following components will be shifted one cell (even across rows). I fixed the station-info layout in r8725.

For those margins: I have to think about a solution.
Parsley, sage, rosemary, and maggikraut.

prissi

Thanks for correction my stumbles. I wonder, if a similar approach with tab would not be appropriate for the line management too. Top stays line selection and the three modifier buttons, but in the bottom three tabs, containing stops, convois, and statistics.

When testing on a high res display and increasing font size to 17 or larger, then many windows open with unusuable size. But I still need to find where to look for that.