The International Simutrans Forum

Development => Patches & Projects => Topic started by: Dwachs on June 03, 2018, 03:30:42 PM

Title: Automatic gui patch
Post by: Dwachs on June 03, 2018, 03:30:42 PM
The idea of this patch is that the gui windows does all positioning and sizing of components themselves:
-- all components define minimal size that is necessary to draw them
-- they also define max_size if they can be drawn larger than minsize
The positioning and sizing is done by table-classes. That is, the windows are defined by nested tables, much like html tables decades ago...

In this way, changes of font and theme can be done without closing windows (in theory). All the theme parameters are only used in the component classes. They define the sizes of the components, everything else is done automatically.

This is all work in progress. Only the following windows are changed: new world, climate settings, settings window, the file selection dialogs (load, save, scenario, font, theme...), display settings, sound settings, go-to-tool, main menu.

Not done:
-- elements in tables that span multiple columns for better alignement of buttons.
-- force table columns to have width relative to each other

Edit: Patch attached.

Edit2: here http://files.simutrans.com/index.php/s/e89716JpNKBvcqr is a compiled file for windows (sim-automatic-gui.exe)
Title: Re: Automatic gui patch
Post by: Yona-TYT on June 03, 2018, 10:36:07 PM
It looks very good, I can not wait to see all the windows with their elements aligned correctly, greetings! and great work !.  ;D
Title: Re: Automatic gui patch
Post by: An_dz on June 04, 2018, 11:37:42 PM
I had the time to check it out today and it's very cool. Here's what I think should be changed.

1) Element heights should be compared to LINESPACE in gui_theme_t when theme is loaded or font-size is changed instead of on every element definition.
2) Elements resizing if their texts are larger than their sizes break layouts unless all other elements resize at the same time. Check image.
3) Elements returning sizes with sums with D_(H|V)_SPACE is wrong. The right margin won't be correct.
4) Some elements have magic numbers. +2, +4 should not be there.
5) Why some places subtract 1 from scr_size::inf and others don't?
Title: Re: Automatic gui patch
Post by: Dwachs on June 05, 2018, 06:17:12 AM
Thank you for testing!

1) yes, you are right. This should be done after this patch is committed. One of the points of the patch is to separate all these theme-constants away from the gui objects. Such that changing the component definitions is enough.
2) Will have to test. What did you do to get this picture? Edit: I suspect the screenshot is from current trunk, not patched (?)
3) Which elements you refer to? Some elements use this to define some internal distance to boundary (text in buttons).
4) Which elements? I suppose gui_label_stationname_t, which is a new helper element class, but all the magic is already in the existing code. I have to take what I find. I agree, magic numbers should not be there. But this is not the point of the patch.
5) This is not well documented:
-- min_size == the size this element needs and gets
-- max_size > min_size: if the table cell of the element is larger than min_size, then the element is enlarged up to max-size.
-- max_size == scr_size::inf-1 means the element can be enlarged arbitrarily, but it will only be enlarged up to min-size of surrounding elements (e.g. buttons filling the cell in a  button table)
-- max_size == scr_size::inf means the element can be enlarged arbitrarily (like scroll_panes), and they will be enlarged if possible
Title: Re: Automatic gui patch
Post by: An_dz on June 05, 2018, 02:01:49 PM
2. Nothing, just applied your patch on trunk. The below code shows that width is the width of the text.
case box:
case roundbox: {
scr_coord_val w = translated_text ?  2*D_H_SPACE + proportional_string_width( translated_text ) : 0;
scr_size size(gui_theme_t::gui_button_size.w, max(D_BUTTON_HEIGHT,LINESPACE));
size.w = max(size.w, w);
return size;
}


3. gui_label_t is one, it returns text_width + spacing.

4. numberinput, scrollbar, textinput are some.

5. Thanks
Title: Re: Automatic gui patch
Post by: Dwachs on June 06, 2018, 06:21:41 AM
2) I did some last-minute change which breaks the new-world dialog
3) ok, will remove them
4) magic numbers have to be addressed after this patch is committed.
Title: Re: Automatic gui patch
Post by: An_dz on June 06, 2018, 12:19:25 PM
4) Ok, I can do this, I was already doing it anyway before your patch.
Title: Re: Automatic gui patch
Post by: Dwachs on June 06, 2018, 09:22:22 PM
Here is a modification: some simple windows like language selection also use new scheme. The broken new-world dialogue should be fixed.

Does anybody need the text-input field in the load-theme window? Without looking in the code, I have no idea, what should be entered there.

Edit: patch is broken. Will post new one later
Title: Re: Automatic gui patch
Post by: An_dz on June 06, 2018, 09:48:45 PM
Quote from: Dwachs on June 06, 2018, 09:22:22 PM
Does anybody need the text-input field in the load-theme window? Without looking in the code, I have no idea, what should be entered there.
No, that's why current trunk doesn't have one. Your patch introduced it, the same happens on the pakset selector screen.
Title: Re: Automatic gui patch
Post by: Dwachs on June 07, 2018, 05:47:08 AM
:) then the solution is easy
Title: Re: Automatic gui patch
Post by: Dwachs on June 08, 2018, 06:54:53 AM
I am currently working on the factory window. This is one of the worst dialogues to put into the new framework. Lots of magic button alignment against text buffers.

I would to convert the window in the following way. Currently, the 'Statistics' button opens a field with charts and many buttons. After button press the button jumps away. The 'Details' buttons opens a new window with some text about the particular factory type. Instead of these two buttons I would like to introduce three tabs:
-- 'Connections' all the connections to other factories, cities, stops
-- 'Statistics' the statistics and colored buttons
-- 'Details' the factory description

What do you think?
Title: Re: Automatic gui patch
Post by: An_dz on June 08, 2018, 01:35:17 PM
Sounds good, less windows to deal with.
Title: Re: Automatic gui patch
Post by: Dwachs on June 08, 2018, 05:12:42 PM
Here is a snapshot of the internally reworked factory window.  The indicators for production boost will be shown with semi-transparent black outline image when not active, full colored when active. Still some way to go. The connection info is now a table with a lot of cells, not produced by magic interplay of a large text buffer and luckily placed images. (Only exception is the halt list, this is still text buffer based but good for now)
Title: Re: Automatic gui patch
Post by: Yona-TYT on June 08, 2018, 05:34:40 PM
Can you send an executable to test?
Title: Re: Automatic gui patch
Post by: Dwachs on June 09, 2018, 03:06:32 PM
Here is an update: factory window is fully reworked

Windows executable
http://files.simutrans.com/index.php/s/e89716JpNKBvcqr

Patch
http://files.simutrans.com/index.php/s/2uJNLjYYnP1wUmS
Title: Re: Automatic gui patch
Post by: prissi on June 10, 2018, 12:00:21 PM
I am very much pleased with this design and the idea behind. I will do a release as soon as possible (the stable has really many bad bugs concerning network play and ship routing with channels). Just after this I will try to contribute as well.

At least some of the list windows has been switched to the scrolled list, which woul make those easier as well.
Title: Re: Automatic gui patch
Post by: Yona-TYT on June 10, 2018, 12:49:03 PM
@Dwachs
Can you also touch up the screen settings window ?.

https://forum.simutrans.com/index.php/topic,18195.msg172951.html#msg172951
Title: Re: Automatic gui patch
Post by: Dwachs on June 18, 2018, 05:59:32 PM
Here is a new version. Following windows were changed: minimap, enlarge map, convoy info, the small object info windows.

Patch: http://files.simutrans.com/index.php/s/l7867hyVyEXqDbD
Windows Exe: http://files.simutrans.com/index.php/s/e89716JpNKBvcqr

Question: I would like to put the conoy details in an extra tab (not an extra window). What do you think?
Title: Re: Automatic gui patch
Post by: An_dz on June 18, 2018, 08:12:59 PM
Quote from: Dwachs on June 18, 2018, 05:59:32 PM
Question: I would like to put the conoy details in an extra tab (not an extra window). What do you think?
Yes, please. It's more consistent and you hardly need to see that info with the data from the other tabs.
Title: Re: Automatic gui patch
Post by: Yona-TYT on June 18, 2018, 11:49:53 PM
Quote from: Dwachs on June 18, 2018, 05:59:32 PMHere is a new version. Following windows were changed: minimap, enlarge map, convoy info, the small object info windows. Patch: http://files.simutrans.com/index.php/s/l7867hyVyEXqDbD Windows Exe: http://files.simutrans.com/index.php/s/e89716JpNKBvcqr Question: I would like to put the conoy details in an extra tab (not an extra window). What do you think?
I would like the mini-map window to zoom in on the position of the cursor, that would be more intuitive in my humble opinion.  ;)
Title: Re: Automatic gui patch
Post by: An_dz on June 19, 2018, 12:01:04 AM
That's not the scope of this patch, create an extension request thread so we don't forget it.
Title: Re: Automatic gui patch
Post by: Yona-TYT on June 19, 2018, 12:15:33 AM
Quote from: An_dz on June 19, 2018, 12:01:04 AMThat's not the scope of this patch, create an extension request thread so we don't forget it.
I am sorry.  :-[



This work looks great !!.

Two details here:

The buttons are not stretched when enlarging the convoys window.



(https://www.mediafire.com/convkey/42ab/bq4zc4h2s8hhdon6g.jpg)

Here the image says everything.(https://www.mediafire.com/convkey/9990/6tvl6xpcgbuvxy66g.jpg)
Title: Re: Automatic gui patch
Post by: Dwachs on June 19, 2018, 06:04:02 AM
@Yona: Why should these buttons stretch?

Second image: this is indeed a bug. Did you change the size of the window to be smaller than the image?
Title: Re: Automatic gui patch
Post by: An_dz on June 19, 2018, 10:59:13 AM
The patch file seems to be broken, I did not take a close look for what it could be but it's not compiling, clean branch.
Title: Re: Automatic gui patch
Post by: Dwachs on June 19, 2018, 05:22:44 PM
@Yona: have fixed this locally.

@An_dz: Patch compiles for me. Can you post the compile log? How do you compile?
Title: Re: Automatic gui patch
Post by: An_dz on June 19, 2018, 07:46:46 PM
Ok, checked what was the problem and it's complaining at OVERRIDE on speedbar component. You forgot to remove it on the definition and you're using it both in the declaration and definition, the spec says it must be at the declaration, and in definition only if inside the class itself.


In file included from gui/components/../../display/../dataobj/loadsave.h:14:0,
                 from gui/components/../../display/scr_coord.h:5,
                 from gui/components/gui_komponente.h:11,
                 from gui/components/gui_speedbar.h:11,
                 from gui/components/gui_speedbar.cc:10:
gui/components/../../display/../dataobj/../simtypes.h:63:19: error: virt-specifiers in 'get_min_size' not allowed outside a class definition
# define OVERRIDE override
                   ^
gui/components/gui_speedbar.cc:30:47: note: in expansion of macro 'OVERRIDE'
scr_size gui_speedbar_t::get_min_size() const OVERRIDE
                                               ^~~~~~~~
gui/components/../../display/../dataobj/../simtypes.h:63:19: error: virt-specifiers in 'get_max_size' not allowed outside a class definition
# define OVERRIDE override
                   ^
gui/components/gui_speedbar.cc:35:47: note: in expansion of macro 'OVERRIDE'
scr_size gui_speedbar_t::get_max_size() const OVERRIDE
                                               ^~~~~~~~
make: *** [common.mk:51: build/default/gui/components/gui_speedbar.o] Error 1
Title: Re: Automatic gui patch
Post by: Dwachs on June 19, 2018, 08:39:06 PM
Thanks! corrected. This check was not active on my system, had to add -std=c++11 to the CFLAGS.
Title: Re: Automatic gui patch
Post by: An_dz on June 20, 2018, 04:17:57 AM
You must be on GCC4, all my gcc's are v6.0+, the default since then is C++14.
Title: Re: Automatic gui patch
Post by: prissi on June 20, 2018, 12:27:52 PM
I think the tab element (like in convoi info) should have full width, so that the scrollbar is at the right side. A scrollbar shortly away from the border is strange to me.
Title: Re: Automatic gui patch
Post by: Dwachs on June 20, 2018, 02:09:37 PM
@prissi: This is hard to change with the patch, as the scroll-pane is not a component of the window, but deeper in a tree of nested tables and components. Edit: should be possible with some play with margins.
Title: Re: Automatic gui patch
Post by: An_dz on June 20, 2018, 06:20:15 PM
It would need for the scrolls components to touch the bottom and right edges but inside them set the margins for the content.
Title: Re: Automatic gui patch
Post by: Dwachs on June 23, 2018, 11:26:49 AM
Here is a new version. New windows patched: schedule edit and stop info. I also would like to put stop details in a tab instead into new window.

patch: http://files.simutrans.com/index.php/s/NiTP9evFFdRRRFP
exe: http://files.simutrans.com/index.php/s/e89716JpNKBvcqr
Title: Re: Automatic gui patch
Post by: prissi on June 23, 2018, 12:21:29 PM
I am really looking forward on this 4th(!) iteration of new GUI code. I still have to look into the patch, because I think the must be a way to have the tab filling the entire window.
Title: Re: Automatic gui patch
Post by: Dwachs on June 23, 2018, 12:38:33 PM
Quote from: prissi on June 23, 2018, 12:21:29 PMbecause I think the must be a way to have the tab filling the entire window.

You want this to force the scroll-bars to the edge of the window? As the scroll-bars do not scroll the entire window, it makes sense that they are not attached to the window border, imho.
Title: Re: Automatic gui patch
Post by: Dwachs on June 24, 2018, 10:15:27 AM
I am currently working on the finance window. I would like to get rid of the headquarter-stuff there. I would like to implement the following changes:
-- finance window: add button 'Show headquater' (if there is one) 'Build headquarter' (if there is none).
-- new headquarter object window: when clicked on the headquarter, open a new window with the information about the headquarter. Add button 'Upgrade' to this window.
Title: Re: Automatic gui patch
Post by: prissi on June 24, 2018, 11:33:38 AM
I think then one should rather have a company window with a headquarter world view. That windows in a size compatible to the normal ones. Then a tab, one for choosing company color, The statistics tab would have the most important numbers (for me something like profit last month, runnung costs, maintenance, net balance) and a detail button that opens the finance window, and an AI settings tab, and scenario tab with the mission status.

Since the content of the tab makes them appear as different windows, these tabs should go full width (and thus the scrollbar at the border and the content to the botton with now space left.)
Title: Re: Automatic gui patch
Post by: Dwachs on June 24, 2018, 05:16:21 PM
So here is the current state of the patch with respect to the finance window.
Title: Re: Automatic gui patch
Post by: An_dz on June 24, 2018, 09:36:50 PM
Wow, you can even check by transport? Now that's pro.
Title: Re: Automatic gui patch
Post by: Yona-TYT on June 24, 2018, 10:40:29 PM
"Show finance for transport type" At last a description for it is filter, it will be easier to know what it is for.  :P
Title: Re: Automatic gui patch
Post by: Dwachs on June 25, 2018, 06:13:58 AM
Quote from: An_dz on June 24, 2018, 09:36:50 PM
Wow, you can even check by transport? Now that's pro.
this has been added 5 years ago, only the label is new :)
Title: Re: Automatic gui patch
Post by: An_dz on June 25, 2018, 12:36:41 PM
What? Really? I should stop playing on free play :P
Title: Re: Automatic gui patch
Post by: Frank on June 25, 2018, 12:46:08 PM
Quote from: An_dz on June 25, 2018, 12:36:41 PM
What? Really? I should stop playing on free play :P

(https://simutrans-germany.com/translator/data/img/10/finances.txt.png)
Title: Re: Automatic gui patch
Post by: An_dz on June 25, 2018, 06:01:44 PM
@Frank, Now I remember it. It's a little hidden in current releases, that's another reason I totally forgot it.
Title: Re: Automatic gui patch
Post by: Frank on June 25, 2018, 06:37:55 PM
Much of what is there has since been forgotten. Also a lot of what was started once again fell asleep.
Title: Re: Automatic gui patch
Post by: Yona-TYT on June 26, 2018, 01:23:57 AM
I hope you have not forgotten the network filters..... hehehehe  ;D ;D ;D

(https://www.mediafire.com/convkey/c18d/e93jmj4i6bo7bcm6g.jpg)
Title: Re: Automatic gui patch
Post by: Dwachs on September 15, 2018, 09:19:40 AM
I would like to change the gui coordinates scr_coord_val to sint32 (from sint16)? This is to prevent integer overflow in size calculations for long lists.
Title: Re: Automatic gui patch
Post by: prissi on September 15, 2018, 02:45:06 PM
Why not? As long as we can keep the in game corrdinates at 16 bit for all objects ...
Title: Re: Automatic gui patch
Post by: Dwachs on October 13, 2018, 09:51:41 AM
Here is an updated patch. Almost all windows are converted.

Todo list:
- convert all lists, help, depot, line management, message option, server, scenario info.
- catch loading gui data from current savegames (I rewrote the rdwr routines, they are incompatible)
- code cleanup

Patch at https://simutrans-germany.com/files/upload/8608-scalable-gui.zip

Title: [Question] Automatic gui patch
Post by: fam621 on October 13, 2018, 10:48:15 AM
Can this be incorporated into Extended?
Title: Re: Automatic gui patch
Post by: prissi on October 13, 2018, 02:01:56 PM
That will need more work, since quite a few dialogues are different. But usually thing find their way sooner or later. Also, for now it is not fully finished on Stnadard, so experimetnal will take longer, I think.
Title: Re: Automatic gui patch
Post by: Yona-TYT on October 13, 2018, 08:06:19 PM
@dwachs
Can you publish an executable to do some tests?.
Title: Re: Automatic gui patch
Post by: Dwachs on October 14, 2018, 10:24:09 AM
here is a executable for windows https://simutrans-germany.com/files/upload/sim-gdi-autogui-8608.zip
Title: Re: Automatic gui patch
Post by: An_dz on October 15, 2018, 12:33:15 AM
Extended also has lots of completely different UIs, they will require extra work and it makes more sense to wait for this patch to be completed first.
Title: Re: Automatic gui patch
Post by: ACarlotti on October 15, 2018, 03:42:29 PM
I think what will actually happen is that the new gui features will be merged across eventually in the course of merging features (sequentially) from Standard. (Details here (https://forum.simutrans.com/index.php/topic,18156.0.html), I think it will take around a year to get to the gui features being merged.) Then someone will have to convert the rest of the Extended guis in the same manner.
Title: Re: Automatic gui patch
Post by: Dwachs on November 28, 2018, 07:26:30 PM
Here is a new patch. Almost all windows are converted. Still not patched are help window, scenario info, message options, line management, and depot window (which is kind of the boss).

Please test!

https://simutrans-germany.com/files/upload/automatic-gui-r8637.zip
Title: Re: Automatic gui patch
Post by: Yona-TYT on November 28, 2018, 11:41:55 PM
I am very happy to see progress in this great project, I would like an executable to do some tests, greetings!  ....  ;D
Title: Re: Automatic gui patch
Post by: Dwachs on November 29, 2018, 07:24:14 AM
Did/Does the executable in the earlier post above work for you? I will post a more recent version later this day.
Title: Re: Automatic gui patch
Post by: Yona-TYT on November 29, 2018, 10:31:10 AM

If it works, although in my case I must use wine.


And also I have compiled an executable for linux. ;)




I do not know if this has to do with the patch, but an error occurs when trying to change the font size. :o





Title: Re: Automatic gui patch
Post by: Dwachs on November 29, 2018, 12:26:34 PM
Quote from: Yona-TYT on November 29, 2018, 10:31:10 AMI do not know if this has to do with the patch, but an error occurs when trying to change the font size. :o
Can you be more specific? Under what condition which error occurs? And you refer to which version of the patch: your executable with recent patch or the executable in the post above? Will test tonight.
Title: Re: Automatic gui patch
Post by: Dwachs on November 29, 2018, 07:14:25 PM
Here is an updated patch. It contains some small fixes (e.g. load-font window does not trigger assertion)

https://simutrans-germany.com/files/upload/automatic-gui-r8637.zip

Edit: here is a windows executable: https://simutrans-germany.com/files/upload/sim-gdi-autogui-8637.zip
Title: Re: Automatic gui patch
Post by: Yona-TYT on November 29, 2018, 10:54:23 PM

Quote from: Yona-TYT on November 29, 2018, 10:31:10 AMdo not know if this has to do with the patch, but an error occurs when trying to change the font size. :o

I can not replicate this anymore.  :P




I have found two details:

1 The preview of the map in the server window does not work well.

(https://www.mediafire.com/convkey/26e8/347lbpbmudk0s5i6g.jpg)22 The preview on the roads does not appear.(https://www.mediafire.com/convkey/61db/ickkyuyt1tjnl3t6g.jpg)
edi.
3 A blinking bar appears in the filter of the finances window.(https://www.mediafire.com/convkey/6edd/tq6u3zs7q9l8uii6g.jpg)
4 The minimap is not stretched when resizing the window.(https://www.mediafire.com/convkey/9393/s5h2bq10bt2y0hq6g.jpg)
Title: Re: Automatic gui patch
Post by: Leartin on November 30, 2018, 05:02:01 AM
Is it intentional that this executable does not support ttf fonts, while r8600 does? Would be nice to test it with scaled fonts.
Title: Re: Automatic gui patch
Post by: Dwachs on November 30, 2018, 07:14:48 AM
@Yona thanks for testing. Will investigate these things tonight.

@Leartin: That is the point of the patch. That is a failure in my cross compiling setup, it was compiled without this support. Sorry, will post new executable tonight.
Title: Re: Automatic gui patch
Post by: ceeac on November 30, 2018, 03:55:16 PM
Found another bug: When expanding the factory window of a factory with details (e.g. pak128 oil field) to the right, the size of the text area increases, but it does not shrink when making the window smaller again.
Title: Re: Automatic gui patch
Post by: Dwachs on November 30, 2018, 08:19:31 PM
Updated patch. Windows executable should now have truetype font support.

@Yona: Fixed these issues, except (1) which is a trunk bug (happens for graphicless servers)
@ceeac: thanks for the report, not yet fixed.


Patch: https://simutrans-germany.com/files/upload/automatic-gui-r8637.zip

Windows exec: https://simutrans-germany.com/files/upload/sim-gdi-autogui-8637.zip
Title: Re: Automatic gui patch
Post by: Yona-TYT on November 30, 2018, 10:53:43 PM
Some components of the windows are superimposed to the news ticker.  :o
(https://www.mediafire.com/convkey/7583/119c920o6dbisl26g.jpg)

(https://www.mediafire.com/convkey/c698/s06v5sbbsm7xagz6g.jpg)
Title: Re: Automatic gui patch
Post by: Yona-TYT on November 30, 2018, 11:00:28 PM
A curious detail:

A small box appears when the lists are empty, why not remove this box when there is nothing?.
(https://www.mediafire.com/convkey/9a4d/yzq8pr70dqty8md6g.jpg)
Edi.



I also think it would be nice to fill the bottom of the list with a lighter color, as seen in the example image.
(https://www.mediafire.com/convkey/4c28/lilc3pkbm33y3146g.jpg)
Title: Re: Automatic gui patch
Post by: Dwachs on December 01, 2018, 09:13:26 AM
which components are drawn in the ticker region? From your screenshots is looks like title bar and minimap. Thanks for testing
Title: Re: Automatic gui patch
Post by: Yona-TYT on December 01, 2018, 10:10:20 AM
For the moment I've only got those two, I'm going to do more tests in search of others, greetings!... ;)
Title: Re: Automatic gui patch
Post by: Leartin on December 01, 2018, 01:04:59 PM
What I think are bugs:
Title: Re: Automatic gui patch
Post by: Dwachs on December 01, 2018, 03:48:18 PM
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)
Title: Re: Automatic gui patch
Post by: Dwachs 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.
Title: Re: Automatic gui patch
Post by: Leartin on December 01, 2018, 04:52:32 PM
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.
Title: Re: Automatic gui patch
Post by: Dwachs on December 01, 2018, 06:53:19 PM
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.
Title: Re: Automatic gui patch
Post by: Leartin on December 02, 2018, 09:57:35 AM
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.
Title: Re: Automatic gui patch
Post by: Leartin 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?

Title: Re: Automatic gui patch
Post by: prissi 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 ... )
Title: Re: Automatic gui patch
Post by: Dwachs 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.
Title: Re: Automatic gui patch
Post by: Dwachs on December 12, 2018, 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?
Title: Re: Automatic gui patch
Post by: Leartin on December 12, 2018, 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.



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.
Title: Re: Automatic gui patch
Post by: Yona-TYT on December 23, 2018, 11:43:43 AM
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.
Title: Re: Automatic gui patch
Post by: Dwachs on January 06, 2019, 12:10:13 PM
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
Title: Re: Automatic gui patch
Post by: Yona-TYT on January 06, 2019, 01:13:54 PM
The "Month wait time" values are not displayed well.

You should also add a drop-down menu, as you do in other filters.
(https://www.mediafire.com/convkey/1222/t1826mrqrkorc656g.jpg)




Another detail in this filter.
(https://www.mediafire.com/convkey/5476/55ro825xdgbw7qe6g.jpg)
Title: Re: Automatic gui patch
Post by: Yona-TYT on January 06, 2019, 01:36:09 PM
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!.
(https://www.mediafire.com/convkey/0063/jp90hn2bmams4fg6g.jpg)
Title: Re: Automatic gui patch
Post by: Dwachs on January 31, 2019, 08:05:08 PM
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.
Title: Re: Automatic gui patch
Post by: Yona-TYT on January 31, 2019, 11:31:42 PM
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.
Title: Re: Automatic gui patch
Post by: Dwachs on February 01, 2019, 07:22:55 AM
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.
Title: Re: Automatic gui patch
Post by: prissi on February 01, 2019, 08:16:49 AM
I am for submitting.
Title: Re: Automatic gui patch
Post by: Leartin on February 01, 2019, 04:01:53 PM
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.
Title: Re: Automatic gui patch
Post by: Yona-TYT on February 02, 2019, 02:06:40 AM
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.  ;)
Title: Re: Automatic gui patch
Post by: Dwachs on February 02, 2019, 04:56:03 PM
submitted, in r8653
Title: Re: Automatic gui patch
Post by: ceeac on February 02, 2019, 10:21:55 PM
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
Title: Re: Automatic gui patch
Post by: captain crunch on February 03, 2019, 09:56:09 AM
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.
Title: Re: Automatic gui patch
Post by: Dwachs on February 03, 2019, 11:09:00 AM
@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.
Title: Re: Automatic gui patch
Post by: ceeac on February 03, 2019, 11:33:48 AM
@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
Title: Re: Automatic gui patch
Post by: Dwachs on February 03, 2019, 11:40:02 AM
missed this one. please check r8664
Title: Re: Automatic gui patch
Post by: prissi on February 05, 2019, 02:27:51 AM
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).
Title: Re: Automatic gui patch
Post by: Dwachs on February 05, 2019, 09:16:19 AM
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
Title: Re: Automatic gui patch
Post by: prissi on February 05, 2019, 03:10:05 PM
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.
Title: Re: Automatic gui patch
Post by: ceeac on February 05, 2019, 04:12:33 PM
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.
Title: Re: Automatic gui patch
Post by: DrSuperGood on February 05, 2019, 06:09:38 PM
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.
Title: Re: Automatic gui patch
Post by: Dwachs on February 05, 2019, 08:30:36 PM
@DrSuperGood: thanks for spotting. Should be better now (r8671)

Also the headquarter window should now work properly (r8672)
Title: Re: Automatic gui patch
Post by: prissi on March 13, 2019, 07:39:52 AM
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.
Title: Re: Automatic gui patch
Post by: Dwachs on March 13, 2019, 07:53:56 PM
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.
Title: Re: Automatic gui patch
Post by: prissi on March 17, 2019, 12:21:21 PM
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.
Title: Re: Automatic gui patch
Post by: Dwachs on March 18, 2019, 09:09:52 AM
Windows open at minimum size. Then one has to enlarge them manually. The window size is then stored and re-applied when opening the window again.
Title: Re: Automatic gui patch
Post by: prissi on March 18, 2019, 02:22:43 PM
Hmm, but with large font and large buttons, many flowtext windows open so five letters and two lines of text are visible, and the rest is scroll bars and borders. How about open windows with the default width (or larger if needed) from the window settings. It is very practical to have windows with identical width.

If no one objects, I may work on the line management next, to use tabs to halt, convois and statistics.
Title: Re: Automatic gui patch
Post by: Leartin on March 18, 2019, 03:09:07 PM
Quote from: prissi on March 18, 2019, 02:22:43 PM
Hmm, but with large font and large buttons, many flowtext windows open so five letters and two lines of text are visible, and the rest is scroll bars and borders. How about open windows with the default width (or larger if needed) from the window settings. It is very practical to have windows with identical width.

The window sizes should be save- and loadable, for easy transfer to a new computer. The defaults could just be in one of those files, but any player may use a different, personal "default".
Title: Re: Automatic gui patch
Post by: Dwachs on March 18, 2019, 03:31:52 PM
Quote from: Leartin on March 18, 2019, 03:09:07 PM
The window sizes should be save- and loadable, for easy transfer to a new computer.
They are saved in and reloaded from default.xml .