News:

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

[Patch] CHG: do not close sticky windows when pressing ESC

Started by koroal, December 01, 2022, 10:46:32 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

koroal

Currently, the pin icon in window's title bar only prevents it from getting closed when using Backspace to close all windows. In my experience, it is not very intuitive (it took me significant time to figure out what exactly the icon does) nor it is very useful (because one still can accidentally close an important window by hitting Escape when trying to close another window and not noticing that the important window is focused instead).

I suppose, the current implementation has its reasons and was done like that on purpose. Still, I would like to propose at least to consider changing this behavior. In my opinion, that would make the pin functionality more obvious and more useful.

This patch prevents pinned windows from getting closed by Escape. They can still be closed without unpinning by clicking the [X] title bar button, or by right-clicking their corresponding toolbar icon.

Yona-TYT

I have always wanted to give a double purpose to that "pin icon", in my opinion it is not very useful.

The double purpose would be to avoid accidental closing (which it already does) and always fix the window to the top so that it is always in sight, that is something that in my opinion would be more useful. ;) 

koroal

Quote from: Yona-TYT on December 01, 2022, 12:03:47 PMfix the window to the top so that it is always in sight
That would probably be non-trivial to implement properly (probably from both the UI standpoint and the code standpoint). Though it is hard for me to say anything about the matter as I am quite bad with designing GUIs.

I am not even so sure anymore about the change I have proposed here. After playing the game for a few more days and getting more used to the GUI, I have now started to see how the current implementation may have its advantages. Namely, it allows to close pinned windows more easily when they are no longer needed. In exchange, one needs to be more mindful about using Escape and not to try to use it to clear up the screen quickly (one should probably use Backspace for that) or to cancel the current selected tool (one should use A instead, but I often made such a mistake at first).

In the end, I think this type of change needs to be more carefully thought out first.

Ranran

Quote from: koroal on December 03, 2022, 06:48:34 PMThat would probably be non-trivial to implement properly (probably from both the UI standpoint and the code standpoint). Though it is hard for me to say anything about the matter as I am quite bad with designing GUIs.

I am not even so sure anymore about the change I have proposed here. After playing the game for a few more days and getting more used to the GUI, I have now started to see how the current implementation may have its advantages. Namely, it allows to close pinned windows more easily when they are no longer needed. In exchange, one needs to be more mindful about using Escape and not to try to use it to clear up the screen quickly (one should probably use Backspace for that) or to cancel the current selected tool (one should use A instead, but I often made such a mistake at first).

In the end, I think this type of change needs to be more carefully thought out first.
Once upon a time, the standard had the following arguments:
https://forum.simutrans.com/index.php/topic,20442.msg192234.html

In extended a locked button was created and separated from pinned. I don't know if the functionality you have in mind is the same, but if so it may be possible to backport from extended.
https://forum.simutrans.com/index.php/topic,20984.msg196559.html
Note that the patch was incomplete at the time and some fixes were added later.
There are cases where a window must be forced to close even when it is locked, and those cases should be handled appropriately.
There may be differences between standard and extended in this respect.

The locked button required for the theme can also be reused from extended. The letters "l" and "L" are used when the locked icon is missing, but that doesn't really matter as the same is true for other existing gadget buttons.
pak.256やpak.nipponのような複数タイル市内建築物があるpakセットはextendedではちゃんと遊べません。それどころかextendedの追い越し機能はバグまみれで修正が難しくなっており、都市機能および道路機能というゲーム土台部分を壊し、開発作業&コードメンテナンスの足かせになっている。それは最終的にプレイヤーの損失に他ならない。その原因は全て1人の日本人=ひめし@himeshi_hob(THleaderH)によるもの。再びフォーラムの先輩方のアドバイスをガン無視し、結局ほとんど修正されないままExtendedに実装されてしまった。彼は問題を認識しつつ5年以上放置して今なおOTRPの開発を続けている。あまりにも身勝手で無責任。日本の人達はそういう事実にちゃんと目を向けるべき (´・ω・`)

Yona-TYT

Actually this is the behavior I'm looking for which is very useful for me: ;)

Quote from: Ranran(Hibernating) on December 08, 2022, 10:07:26 AMOnce upon a time, the standard had the following arguments:
https://forum.simutrans.com/index.php/topic,20442.msg192234.html ....
Your project is also very interesting, I am very sorry that it was never implemented in standard.  :-[

Ranran

Quote from: Yona-TYT on December 08, 2022, 12:25:14 PMActually this is the behavior I'm looking for which is very useful for me:
I challenged myself to implement this feature. I was able to get it working to some extent.
However, I disagree with the implementation of this, but posting to the standard board for reference.

Preview of testing in extended:


Change commit (for extended):
https://github.com/Ranran-the-JuicyPork/simutrans-exp/commit/0d47d6428764e5c0642d0baa7ebf6a52494d2baf

Due to a conflict with r10503 it seems difficult to merge this change into standard as-is.

It seems very inconvenient to share features with sticky. So this may need to be a new gadget button.
I think such a feature would be useful for things like playing videos, but I don't understand the usefulness of this feature in simutrans. Something like a small convoy window with just a view, for example, would be useful.
If you have a large window on top, you may not notice when a smaller window opens behind it.
Therefore, I think that it is necessary to automatically control the optimum opening position. I haven't coded anything like that.
Another issue. The Esc key will try to kill the frontmost window.
In other words, those who are intentionally placed in the forefront are executed preferentially. I found this very annoying in my opinion. If you want to kill a window that is not in the foreground, you cannot kill it with Esc, so there is a possibility of accidentally shooting the foremost window.
However the close gadget works fine. So you have no choice but to push it, but the frontmost window may be blocking you from doing so.
I think this behavior will confuse the players a lot.

However, I'm posting this in the hope that it will spark discussion.
pak.256やpak.nipponのような複数タイル市内建築物があるpakセットはextendedではちゃんと遊べません。それどころかextendedの追い越し機能はバグまみれで修正が難しくなっており、都市機能および道路機能というゲーム土台部分を壊し、開発作業&コードメンテナンスの足かせになっている。それは最終的にプレイヤーの損失に他ならない。その原因は全て1人の日本人=ひめし@himeshi_hob(THleaderH)によるもの。再びフォーラムの先輩方のアドバイスをガン無視し、結局ほとんど修正されないままExtendedに実装されてしまった。彼は問題を認識しつつ5年以上放置して今なおOTRPの開発を続けている。あまりにも身勝手で無責任。日本の人達はそういう事実にちゃんと目を向けるべき (´・ω・`)

Yona-TYT

For me it is very useful, for example if I am using a tool and I open multiple windows, it is always good to have that toolbar always in front.

And if the window obstructs the view of another, then one just has to double click on the title bar to minimize.

Maybe it's a matter of adapting and getting used to it, don't you think?.

Ranran

As far as I know, the window that is fixed to the front is a window such as a video playback window. There is usually only one. Otherwise it will not be "frontmost".
Sticky can be set for multiple windows, and if they don't overlap, it's hard to know which one is the foremost.
Therefore, it is very difficult to grasp which window the Esc key affects. For example, many toolbars that do not overlap.
I think these issues should be properly addressed when implementing this feature.
pak.256やpak.nipponのような複数タイル市内建築物があるpakセットはextendedではちゃんと遊べません。それどころかextendedの追い越し機能はバグまみれで修正が難しくなっており、都市機能および道路機能というゲーム土台部分を壊し、開発作業&コードメンテナンスの足かせになっている。それは最終的にプレイヤーの損失に他ならない。その原因は全て1人の日本人=ひめし@himeshi_hob(THleaderH)によるもの。再びフォーラムの先輩方のアドバイスをガン無視し、結局ほとんど修正されないままExtendedに実装されてしまった。彼は問題を認識しつつ5年以上放置して今なおOTRPの開発を続けている。あまりにも身勝手で無責任。日本の人達はそういう事実にちゃんと目を向けるべき (´・ω・`)