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

[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]

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

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.

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.

[Yona-TYT]

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

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

Actually 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.

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

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.