News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

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

Started by Ranran, June 28, 2020, 10:06:51 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

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

Quote from: Ranran on June 28, 2020, 10:06:51 AM
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?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ranran

Quote from: jamespetts on June 28, 2020, 10:13:54 AMIs 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?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

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

freddyhayward

Quote from: prissi on June 30, 2020, 11:37:16 AM
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

Quote from: freddyhayward on June 30, 2020, 03:28:11 PMI 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

Quote from: Ranran on June 30, 2020, 06:06:36 PMThere 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?

Sirius

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

Quote from: freddyhayward on June 30, 2020, 10:37:11 PMand 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

Quote from: prissi on July 01, 2020, 01:56:27 PMEven 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.

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


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

I didn't know how to solve this.