[BUG] Selector does not take priority of up and down keys on some dialogs

[Ranran]

I previously reported an issue where the up and down keys conflict with map scrolling while selecting a selector, ↑↓
This is an extended-specific bug, and I've found it to be present in some dialogs.

Standard had no such problems.

The dialog I've confirmed this bug is below: ↓
- depot dialog
- replace dialog
- change price dialog

[jamespetts]

I previously reported an issue where the up and down keys conflict with map scrolling while selecting a selector, ↑↓
This is an extended-specific bug, and I've found it to be present in some dialogs.

Standard had no such problems.

The dialog I've confirmed this bug is below: ↓
- depot dialog
- replace dialog
- change price dialog

Thank you for the report. Is this general to Extended, or is it caused by a pakset specific key-mapping configuration in menuconf.tab?

[Ranran]

Is this general to Extended, or is it caused by a pakset specific key-mapping configuration in menuconf.tab?

I think it is general to Extended.

I checked with 64size-pakset and found one of its possibilities.


The things that should originally be on the front side are on the back side, so I think that we may not have acquired the priority right.

[jamespetts]

That is odd - I do not think that I have changed anything in this regard; I wonder whether this is as a result of an old partial implementation of Standard UI features, or an old bug fix from Standard not applied to Extended?

[Ranran]

For the depot and replace dialog I fixed an overlap issue. Please check pull request #205.

I didn't know how to fix the other dialogs... (´・ω・｀)
I think the order in which it is written will affect it.

Dialogs that still have problems thus have overlapping issue.

[jamespetts]

Thank you for that - that is much appreciated.

If anyone has any solutions for the remaining issues, that would be very helpful.

[prissi]

Incorporation the scalable GUI foundations will help ... (Duck away) Especially comboboxes saw a lot of effort to allow more overlapping.

[freddyhayward]

Incorporation the scalable GUI foundations will help ... (Duck away) Especially comboboxes saw a lot of effort to allow more overlapping.

I had a look at the GUI overhaul commit and tried to merge it... there were hundreds, potentially thousands of conflicts often with no obvious resolution. It seems the codebases have diverged too much.

[Ranran]

I had a look at the GUI overhaul commit and tried to merge it... there were hundreds, potentially thousands of conflicts often with no obvious resolution. It seems the codebases have diverged too much.

There are many other minor differences besides the GUI changes I was involved with. Some dialogs are not in the standard.
I think it takes a lot of work to fully capture and incorporate them.

[freddyhayward]

There are many other minor differences besides the GUI changes I was involved with. Some dialogs are not in the standard.
I think it takes a lot of work to fully capture and incorporate them.

I have a lot of spare time in the next few weeks, and wonder what the path forward is for the extended GUI. Clearly, standard have made good changes worth emulating, but it is too difficult to merge them directly. Should we instead attempt a separate overhaul guided by the same principles?

[Mariculous]

Hmmm...
It should be attempted to merge the underlying new "framework", i.e. the layout manager and components, further dialogues that didn't change too much, finally manually overhauling the dialogues where merging is not suitable.

[Ranran]

and wonder what the path forward is for the extended GUI.

Focusing only on changing the GUI layout code, regarding extended-specific GUI or GUI that is significantly different from standard I think it will take the same effort as Dwachs implemented it in standard.
If you do that, I think it's bettert to first prepare an empty GUI. Anyway, once we have to get the new drawing system working properly.
Do GUI relocations one by one in the branch where it was achieved. I can help with any changes I have made.
As such, I think GUI overhaul will be a large-scale project.

I think that phystam is already working on it, but I think it is better to incorporate this commit before overhauling the GUI.
https://github.com/aburch/simutrans/commit/93971dbf152f69f9bb62d7889255cf460a398fd7

[prissi]

The GUI part in gui/components.cc and the changes to container and gui_frame are not much dependent on the drawing system the windows are using. The can go first without touching most of the actual windows.

Even in Standard, the line window and depot window mostly uses the old code. But a few changes may be needed indeed, so it is probably a long term project. But without it, extended will no longer be able to merge standard patches whenever they contain GUI code.

[Ranran]

Even in Standard, the line window and depot window mostly uses the old code. But a few changes may be needed indeed, so it is probably a long term project. But without it, extended will no longer be able to merge standard patches whenever they contain GUI code.

I think the depot dialog code has changed significantly from standard to share code with replace dialog when extended created the replace feature.
I actually failed to incorporate the depot filter patch for standard into extended.
I think that extending/adding some functionality always carries such a risk.

[prissi]

Of course. What I was saying is that standard depot window uses the old scaling routinges and the overlapping comboboxes work there.

[Ranran]

I think the bug has been fixed for the depot dialog.
The problem remains when trying to add a combo box on the fly.
It's in vehicle_class_manager and line_class_manager. It is an extended specific dialog.

Code Select Expand


slist_tpl<gui_combobox_t *> pass_class_sel;
slist_tpl<gui_combobox_t *> mail_class_sel;


Code Select Expand


gui_combobox_t *class_selector = new (nothrow) gui_combobox_t();

I didn't know how to solve this.