search

sublimehq / sublime_text

Issue tracker for Sublime Text
https://www.sublimetext.com
803 stars 39 forks source link

Unable to close a window or perform other actions when reload popup exists in background #1703

Open pik opened 7 years ago

pik commented 7 years ago

Summary

Just switched from the dev version to the nightly (3131) after several core-dumps. I am Unable to close the ChangeLog window.

Linux 4.10.8-1-ARCH Openbox 3.6.1 xorg-server 1.19.3-1 Sublime Text Build 3131

edit: I suspect the problem is the behavior of the reload popup prompts, which are not always brought to the front by all window-managers, but grab the signal for the Sublime text window (for all of them?) making it impossible to perform other actions.

keith-hall commented 7 years ago

Can you press Esc multiple times to close the (non-visible) reload prompts and eventually the changelog?

pik commented 7 years ago

That's correct, since the popup grabs all the signals it will also handle escape but if the popup is not visually present (for example it might be on a different desktop from where I am viewing the ChangeLog) than the user has no way to know this and simply has an editor that has stopped responding (as far as all visual indication is concerned).

Properly I think that per-file reload should not use a window-manager based pop-up and avoid this problem entirely. (related: https://github.com/SublimeTextIssues/Core/issues/1088)

wbond commented 7 years ago

It sounds like some window managers are choosing to act in a user-unfriendly way?

pik commented 7 years ago

It sounds like some window managers are choosing to act in a user-unfriendly way?

How exactly is this window managers being unfriendly? Don't generate pop-ups from inactive desktops just because you got an inotify event. Other text-editors can handle file reloads without doing it...

wbond commented 7 years ago

Don't generate pop-ups from inactive desktops just because you got an inotify event. Other text-editors can reload files without doing it...

The window manager should be able to put a child window/dialog in front of other windows in the application…

wbond commented 7 years ago

Just the concept that it will allow a dialog block user interaction, but not raise it to the foreground sounds broken to me.

pik commented 7 years ago

I haven't had to deal with GTK signaling for a while, but most probably this is related to the fact that sublime runs one process for multiple windows - so a single popup grabs signals for all the windows, this is almost certainly not a window manager issue but bad application code.

wbond commented 7 years ago

Well, I don't think we currently have plans to build a new UI paradigm to replace the concept of OS dialogs. They serve the purpose we need right now of preventing the user from manipulating a file why we are waiting for them to choose an option for reverting/reloading a file.

At some point I'll look into see if there is some gtk call we need to make to have this work for the window managers that currently are allowing dialogs to be hidden behind other windows.

pik commented 7 years ago

Okay, let's suppose I had a smarter window manager (although I should add that no other applications seem to have this problem), I'm using a terminal on desktop 2 and switch branches in one of my projects, suddenly the sublime-text editor in desktop 4 prompts me to reload files; in this case should the window manager relocate me to desktop 4 so I can hit 10 reload or cancel buttons in a window which is currently totally unrelated to my workflow?

To me that sounds like just as bad of an experience, it seems that the answer should be not making dialogs that grab signals at the application level for window / tab specific events, especially when you have multiple windows running as separate threads in one process.

This by the way also applies to other application level dialogs as well: such as the open-file menu just not in the painfully obnoxious way of locking the user out of the window GUI without previous user interaction as with the reload dialogs (for example Firefox doesn't do this: if I hit file-open in one window it doesn't block all my other Firefox windows etc.)

jkaniuk commented 4 years ago

Bumping up, as it is quite annoying. It happens to me very frequently as I have few projects opened and I am changing files via cli git underneath.

Dialog in one window should not freeze all other windows.

version: 3.2.2, 3211 Debian GNU/Linux 4.19.67 amd64 X.Org 1:7.7+19