wayfire icon indicating copy to clipboard operation
wayfire copied to clipboard

Minimized dialogs reappear

Open solarkraft opened this issue 4 years ago • 8 comments

Describe the bug When a popup window is minimized it reappears, but it's not possible to interact with it (neither with the content, nor with the controls).

Tested with: Configs: My config, default Applications: Telegram desktop, Jetbrains Rider, Nautilus, Konsole

To Reproduce Steps to reproduce the behavior:

  1. Open a popup (Nautilus about/preferences, Telegram call, Rider settings, Konsole preferences)
  2. Minimize it (through window buttons or the dock)
  3. It reappears

Expected behavior The popup stays minimized

Screenshots or stacktrace Demo video ft. my cat: https://user-images.githubusercontent.com/1337470/104355212-a3bc6980-550a-11eb-8d0e-b219774c7549.mp4

Wayfire version 0.6.0-1247f9d

solarkraft avatar Jan 12 '21 18:01 solarkraft

I thought such views are not supposed to be minimize-able at all? (for ex. see #705)

ammen99 avatar Jan 12 '21 21:01 ammen99

Is there a technical reason? From a UX perspective I don't see why they'd have to be. Especially with workarounds/all_dialogs_modal = true windows in the background are still perfectly interactive with dialogs open (no bugs found after quick testing), so why restrict minimizing them?

solarkraft avatar Jan 13 '21 08:01 solarkraft

Is there a technical reason? From a UX perspective I don't see why they'd have to be. Especially with workarounds/all_dialogs_modal = true windows in the background are still perfectly interactive with dialogs open (no bugs found after quick testing), so why restrict minimizing them?

Do you mean with that option set to false?

Sure, we can implement it but I don't really see a use-case where you want to minimize your dialog. It could happen that for ex. the dialog is treated as modal by the toolkit, that is, the main view cannot be focused unless the dialog is closed (but wayfire doesn't have this information, hence the workarounds option). In such cases, if you minimize the dialog, you still will not be able to interact with the main view, even if nothing obscures it. Also note that this behavior can happen even if you do have all_dialogs_modal = false, so I think at this point it is much more sensible to just disallow this.

ammen99 avatar Jan 13 '21 09:01 ammen99

Do you mean with that option set to false?

Yep, you're right!

This seems to hinge on whether main windows can be interacted with when dialogs are open, since the minimized state doesn't really matter itself (right?).

The use case for that would for example be something like changing the canvas view while applying a filter in GIMP or interacting with Telegram chats while the call popup is open or generally changing some setting you want to try out before closing the dialog. I've tested this a bunch within the current capabilities and at least with the mouse all of the applications I tried it worked perfectly. The ability to do such things is a (supported according to #1030?) feature that I'd be sad to see go.

As long as windows can be focused and interacted with while a dialog is present, is there really a reason to remove the feature of the dialogs also being minimizable (is the application even aware of them being minimized)? A situation that could benefit from such a thing being possible would be GIMP without single window mode, which opens multiple windows that can be interacted with simultaneously.

One practical reason I could think of to disallow minimization would be that applications and dialogs are currently handled inseparably in switcher, fast switcher and scale.

solarkraft avatar Jan 18 '21 19:01 solarkraft