Automatic GUI patch from Standard

[Phystam]

Hello/
Now we can see a lot of GUI improvement projects like Ves and Ranran are doing using "obsolete" workflow in Standard. I know that that is a very difficult project since the Extended GUI code is greatly changed so far from Standard one. But it is also worthwhile to do it since future workflow would become easier than the present one, and it also solves the length difference problem among languages that Ranran is facing.
This change is based on Standard code, so I think that maybe this work should be done by A.Carlotti, right? If this change does affect only the GUI code, another coder could do that too.

[jamespetts]

In principle, this is a worthwhile thing to do; but it depends on coder time availability. A. Carlotti has not been very active recently, I note; and it is of course up to him what, if anything, that he works on in what order. My own priorities are bug fixing and balance critical features.

[Ves]

Does anyone know more precisely *what* actually changed in Standard? Has the very fundamentics of the GUI been redone, things like gui_button_t, gui_combobox_t etc, or can those elements be reused, and just defined in another way?

Would it be possible to port the basics over to extended with the old and new existing together, so we can update the windows when we go along?

[Mariculous]

Here is the commit that incorporated the new GUI to standard.
https://github.com/aburch/simutrans/commit/bf40a838a16f950ba9dd7e0447573e520934b1c3

As expected this seems like A LOT has been changed there.
Furthermore, from the Makefile it seems some GUI components were added whilst many remained, thus a coexistence of both is quite unlikely.
I did not have a look at changes of the components themselves however and won't do such kind of investigation before the second half auf February.

[Ves]

Whop, that was a massive commit, thanks for linking! How would anyone even start this task!?

Btw, it is interresting to see how some of the new GUI is done. It seems (from a very far away glance) a bit simpler than the existing GUI, would you think so as well? I have not played Standard in ages, so Im not sure what difference it makes in the game.

What advantages does the new GUI give against the old one? Except scaling and tuch screen friendly?

[Mariculous]

Except scaling and tuch screen friendly?

It's scaling and touch screen friendly
Many windows were reorganised using multiple tabs to better work with small displays and reduce the kind of annoying window spamming.
E.g. there is no convoy detail window, it's just another tab of the convoy window.

Some GUIs became even worse due to nonsense scaling imho but most of them ae fine.
Windows that do some strange nonsense scaling imho are the display setting and the network window. Maybe there are some more.

I can't say much about it from a technical perspective.
There seem to be some new components and I have read the UI is slightly easyer to code because one does not have to take care about the scaling.

[Ves]

It's scaling and touch screen friendly

Haha, well ok 

[prissi]

It is easier to program, more like a spread sheet. For example the new sound setting window.

Code Select Expand


sound_frame_t::sound_frame_t()
  : gui_frame_t( translator::translate("Sound settings") ),
    sound_volume_scrollbar(scrollbar_t::horizontal),
music_volume_scrollbar(scrollbar_t::horizontal)
{
set_table_layout(1,0);

sound_mute_button.init( button_t::square_state, "mute sound");
sound_mute_button.pressed = sound_get_mute();
add_component(&sound_mute_button);
sound_mute_button.add_listener( this );

add_table(2,0);
{
// Sound volume label
new_component<gui_label_t>( "Sound volume:" );

sound_volume_scrollbar.set_knob( L_KNOB_SIZE, 255 + L_KNOB_SIZE );
sound_volume_scrollbar.set_knob_offset( sound_get_global_volume() );
sound_volume_scrollbar.set_scroll_discrete( false );
sound_volume_scrollbar.add_listener( this );
add_component( &sound_volume_scrollbar );

new_component<gui_label_t>( "Sound range:" );

sound_range.set_value( env_t::sound_distance_scaling);
sound_range.set_limits( 1, 32 );
sound_range.add_listener(this);
// sound_range.set_tooltip( "Lower values mean more local sounds" )
add_component(&sound_range);

for( int i = 0; i < MAX_SOUND_TYPES; i++ ) {
new_component<gui_label_t>( specific_volume_names[i] );

specific_volume_scrollbar[ i ] = new scrollbar_t( scrollbar_t::horizontal );
specific_volume_scrollbar[i]->set_knob( L_KNOB_SIZE, 255 + L_KNOB_SIZE );
specific_volume_scrollbar[i]->set_knob_offset( sound_get_specific_volume((sound_type_t)i) );
specific_volume_scrollbar[i]->set_scroll_discrete( false );
specific_volume_scrollbar[i]->add_listener( this );
add_component( specific_volume_scrollbar[i] );
}
}
end_table();

new_component<gui_divider_t>();

// Music
music_mute_button.init( button_t::square_state, "disable midi");
music_mute_button.pressed = midi_get_mute();
music_mute_button.add_listener( this );
add_component(&music_mute_button);

add_table(2,0);
{
new_component<gui_label_t>( "Music volume:" );

music_volume_scrollbar.set_knob( L_KNOB_SIZE, 255 + L_KNOB_SIZE );
music_volume_scrollbar.set_knob_offset( sound_get_midi_volume() );
music_volume_scrollbar.set_scroll_discrete( false );
music_volume_scrollbar.add_listener( this );
add_component( &music_volume_scrollbar );
}
end_table();

// song selection
new_component<gui_label_t>( "Currently playing:" );

add_table( 3, 1 );
{
previous_song_button.set_typ( button_t::arrowleft );
previous_song_button.add_listener( this );
add_component( &previous_song_button );

next_song_button.set_typ( button_t::arrowright );
next_song_button.add_listener( this );
add_component( &next_song_button );

add_component( &song_name_label );
update_song_name();
}
end_table();

shuffle_song_button.init( button_t::square_state, "shuffle midis" );
shuffle_song_button.pressed = sound_get_shuffle_midi();
shuffle_song_button.add_listener(this);
add_component(&shuffle_song_button);

set_resizemode(diagonal_resize);
reset_min_windowsize();
}


The components are the same as the old one, just the positioning is different.

For instance set_table_layout(1,0) make a dialog with a single row. But then I later need two rows, so I write add_table(2,0) .... end_table(); No fiddeling with offsets - it will work with almost any button and font size, and with an string length.

Still, even standard has one old dialog, the line window. This is actually four sub-windows, and probably should change into the selection area and three tabs. (Not done yet). But conversion is fairly straight forwards, as soon as one stops to force things. (Ok, there is an empty element to have some space reservation without showing something.)

There were also some follow-on patches, i.e. the conversion of the display settings, or that the tabs are going to the border of the windows. Still, you can still use the old windows too. Just will be looking weird sometimes.

[Ves]

Thank you Prissi for the explanation (and sorry for the late response).

So it is pretty much only the positioning that is different from the old way you say? Looking at your example, I see the initiazion as we are used to for sound_mute_button (except the positioning, which I assume is taken care of entirely by set_table_layout(x,y)).

But then you make a lable just by doing the new_component<gui_label_t>( "Sound volume:" ); Can all components be created like this?

You have hardcoded some sizes in sound_volume_scrollbar.set_knob( L_KNOB_SIZE, 255 + L_KNOB_SIZE ); Do we still need to specify hardcoded sizes or is this just a remnant?

Thank you for your help with this!

[prissi]

The scrollbar has no predetermined width: Hence it is hardcoded.

About new_component<>() and new_componenet_span<>(..,number_of_rows_from_?this_componenet);

You can add most components. If case if you need a listener, you do;
button_t *b = new_component<button_t>()
b->init();
b->add_listener(this);
...

[Ves]

Ok thank you, much appreciated.

Is it possible to do this also within containers, which is not a gui_frame_t? If so, how? It tells me set_table_layout(1, 0) (and all other relevant parameters) are not defined, even though I did include gui_frame.h".

edit:

To describe what I want to do.
I want to fetch a container which is defined in another place. Much like the depot_frame fetches the gui_convoy_assembler. Looking through gui_convoy_assembler, it appears that all sizes and so are hardcoded, not utilizing the new GUI?

[prissi]

This automatic gui work not on gui_container_t, but gui_alinged_contaner_t. The new gui will need sometimes some more space. But it is easier to program, since it is justliek a spread sheet and avoids working with pixels here and there.