News:

Want to praise Simutrans?
Your feedback is important for us ;D.

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

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

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ranran(retired)

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
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

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(retired)

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.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

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(retired)

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.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

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(retired)

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.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

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?

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(retired)

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
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

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(retired)

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.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

prissi

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

Ranran(retired)

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.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)