dictation-toolbox / dragonfly

Speech recognition framework allowing powerful Python-based scripting and extension of Dragon NaturallySpeaking (DNS), Windows Speech Recognition (WSR), Kaldi and CMU Pocket Sphinx
GNU Lesser General Public License v3.0
388 stars 75 forks source link

Window.close() not working correctly on Linux #364

Closed kendonB closed 2 years ago

kendonB commented 2 years ago

As per Gitter, @Danesprite says:

... this Dragonfly method is not correctly implemented; it sends the wrong message to the target window. The difference can be observed by closing a text editor window (e.g., gedit) with unsaved changes. I'll open an issue on the problem.

drmfinlay commented 2 years ago

Thank you Kendon for opening this issue.

I have just had a look into this and it seems that what I had observed was an X11 quirk. I had assumed that X11 had, like Windows, separate mechanisms for closing and destroying application windows. This is not the case. The following Stack Overflow answer goes into more detail on this:

https://stackoverflow.com/a/22612855

What seems to be happening is that Dragonfly, through xdotool, calls XDestroyWindow() on the window directly, which is what the window manager normally does /after/ letting the application handle a close event. So, to use my text editor example, the save changes dialogue never appears because the window is destroyed immediately.

In my defence, the relevant xdotool command is named "windowclose," not "windowdestroy."

The wmctrl program is able to gracefully close a window. I'll change Dragonfly to use that instead. This program is already mentioned in the documentation as an external requirement on X11. (It is used for window.maximize().) In the long run, however, I would like use python-xlib for everything.

drmfinlay commented 2 years ago

This issue is now resolved in version 0.34.1. If the wmctrl program is not installed, Dragonfly will fallback on xdotool and the old behaviour. Both programs should be available from the system package manager.

I'll look into the feasibility of using python-xlib instead at some point. It would make our X11 integration more portable and efficient.