Close button disappeares in undocked dialogs after focus regain (gschem)

Bug #1859815 reported by Alexei
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gEDA
New
Undecided
Unassigned

Bug Description

Close button disappears in "Options" and "Pages" (page manager) dialogs in gschem, after such dialog window losing and then regaining back focus, if these dialogs are opened undocked. If window manager with "focus follows mouse" option is used, bottons disapper after symply moving cursor beyond dialog area and then back on. And I think it is good idea to add such "Close" buttons to all undockable dialogs, it should increase usability with tiled window managers, which are not contain window control buttons at all.

Tags: gschem
Revision history for this message
Roland Lutz (rlutz) wrote :

This is intended behavior. On losing focus, detached docks go from “dialog” to “window” state with two consequences:

- dialog action buttons are no longer shown at the bottom of the dock, and
- pressing Esc doesn't close the dock any more but returns focus to the main window.

I see how this would be undesireable in "focus follows mouse" configurations. OTOH, tiling window managers are exactly the use case for which this feature was implemented: if the window manager takes care of arranging the tool windows in the desired way, you wouldn't want the application to close windows when the user leaves them, or to add its own window decoration.

Do you have any suggestion how in your environment, gschem should decide whether to treat a detached dock as a “dialog” (with buttons at the bottom, will close on leaving) or as a “window” (without buttons at the bottom, will stay on screen)?

tags: added: gschem
Revision history for this message
Alexei (386th) wrote :

I use i3 and dwm window managers, both with "focus follows mouse" enabled. Of course I can dock these dialogs and forget about buttons disappearance. Simply such dialogs behavior seemed strange to me, and I thought it was a bug. I don't know anything about X11 internals, but why change state from "dialog" to "window" on losing focus? I captured two small videos with demo of current behavior (https://sndbro.ru/tmp/gschem_cb/), agree it looks weird.

Revision history for this message
Roland Lutz (rlutz) wrote :

> why change state from "dialog" to "window" on losing focus?

Both “dialog” and “window” mode make sense in certain situations. When opening a dock from the menu, “dialog” mode makes most sense; when a dock is open in parallel to the main window, “window” mode makes most sense. So there needs to be some point where a dock changes from “dialog” to “window” mode.

Losing focus is simply the trigger that made most sense to me. To me, clicking in the main window (as opposed to confirming or cancelling the dialog) is the logical step that indicates that the user wants to use the dock as a tool window. I agree that this isn't optimal, particularly in “focus follows mouse” setups.

So, how would you prefer this to be implemented? What would you intuitively do if you wanted to use the dialog as a tool window?

Revision history for this message
Alexei (386th) wrote :

I agree that switching of dialog to the toolbox window is a good idea, but why remove buttouns in "window" mode? Instead of closing tool window by simple mouse click, users of tiling WMs must use key combination (2-3 key combination, always need to keep this combination in mind), and prior doing this you need to position cursor right above the window (in "focus follows mouse" configuration). It's easy to occasionally kill not targeted window...

So, I solved this problem for myself, now I use only docked dialogs, it's convenient, not like in older versions that don't have docks at all.

Let the gEDA developers perceive adding of "Close" buttons to all undocked windows as a proposal to improve usability for users with tiling WMs. But if this is impossible - no problem, we will simply use these windows docked. :)

There are much more serious problems in gschem than buttons, like crashes after some undos...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.