How to you "close" a window in a friendly way?

1,838 views
Skip to first unread message

Anthony Thyssen

unread,
May 10, 2017, 8:21:07 PM5/10/17
to xdotool-users
The xdotool man page for "windowkill" says...

Kill a window. This action will destroy the window...

So according to the manpage it tells the Xserver to just "destory" the window out from under the clients control.  This is the same action as the "xkill" command.

But how to I "close" the window in a more friendly manner?

That is sent the client a "Delete Window" event, as if the user pressed the 'close' button for the window.  Most clients will then close that particular window, clean up, and only exit, if that was its last window, if it wasn't the client will continue working with the windows it does still have open.

This is a much more friendly function, and yet I don't see it in xdotool.

Current version (from fedora repositories) 3.20160205.1


ASIDE... Up until now I have used
   xwit -c :ACTIVE:
to do this to the current window but "xwit" is no longer part of the fedora repositories, and is not activally mantained, though it is still part of the Ubuntu repositories.

martin...@googlemail.com

unread,
May 12, 2017, 8:16:09 PM5/12/17
to xdotool-users
One could send alt+F4 to the window in question.

xdotool windowactivate --sync $(xdotool search --name ".Terminal.") key --clearmodifiers --delay 100 "alt+F4"

In this case xdotool sends alt+F4 to the first window which has "Terminal" in its name.

Best wishes from splitcells.net

Anthony Thyssen

unread,
May 14, 2017, 8:33:24 PM5/14/17
to martin...@gmail.com, xdotool-users
That is a application dependant solution.  Not all applications, especially old ones, will not understand.
Better to be able to send a 'delete_window' event directly, and was suprised that the functionality did not seem to be in xdotool.

Actually it seems worse that I thought.  When I tried to test it using
  xdotool selectwindow windowkill

xdotool killed my window manager (openbox) rather than the window I selected!
That however may be a problem with the window I selected (the manger wrapping window rather than the application) 



--
You received this message because you are subscribed to the Google Groups "xdotool-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xdotool-users+unsubscribe@googlegroups.com.
To post to this group, send email to xdotoo...@googlegroups.com.
Visit this group at https://groups.google.com/group/xdotool-users.
For more options, visit https://groups.google.com/d/optout.

martin...@googlemail.com

unread,
May 15, 2017, 9:31:45 AM5/15/17
to xdotool-users, martin...@gmail.com, A.Th...@griffith.edu.au
I'm not that experienced on Linux (I'm currently using Fedora) and I never have
heard of an 'delete_window' event.
Do you mean the "WM_DELETE_WINDOW" message?

The poster explicitly said that "windowkill" does not fit his solution as
it just kills the window.

According to https://unix.stackexchange.com/questions/159205/a-quit-command-weaker-than-windowkill :

    "Typing in xdotool getwindowfocus windowkill currently

     terminates the active window and bypasses any safeguards like

     "would you like to save your work?"."


His problem with the current solution is that:

" "xwit" is no longer part of the fedora repositories, and is not activally mantained"


Best wishes from splitcells.net

To unsubscribe from this group and stop receiving emails from it, send an email to xdotool-user...@googlegroups.com.

martin...@googlemail.com

unread,
May 15, 2017, 10:10:12 AM5/15/17
to xdotool-users
Maybe it is not important that xwit is currently not mantained actively.
The whole program is about 2k LoC.
Also you should be able to compile the program yourself as X11 is the only
dependency of the source code.

Best wishes from splitcells.net.


Am Donnerstag, 11. Mai 2017 02:21:07 UTC+2 schrieb Anthony:

Anthony Thyssen

unread,
May 15, 2017, 7:31:31 PM5/15/17
to martin...@gmail.com, xdotool-users
Maybe, But the delete window function is a very basic (core X Windows) control that xdotool can not currently do.

Another tool with this function is xclosedown  which sends a delete (close) window event to all applications, then waits 30 seconds before sending the destroy (kill) event.  Of course that is going a bit too far!

--
You received this message because you are subscribed to the Google Groups "xdotool-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xdotool-users+unsubscribe@googlegroups.com.

Jordan Sissel

unread,
May 15, 2017, 11:56:31 PM5/15/17
to Anthony Thyssen, martin...@gmail.com, xdotool-users
A quick glance at this issue and some (very brief) research, it seems we have three options:

1) Add support to invoke XDestroyWindow
2) Add support to send a ClientMessage with WM_CLOSE_WINDOW
3) Add support to send a ClientMessage _NET_CLOSE_WINDOW to the window manager.

We could support all 3. I don't think it will be much code.

-Jordan


On Mon, May 15, 2017 at 4:30 PM, Anthony Thyssen <a.th...@griffith.edu.au> wrote:
Maybe, But the delete window function is a very basic (core X Windows) control that xdotool can not currently do.

Another tool with this function is xclosedown  which sends a delete (close) window event to all applications, then waits 30 seconds before sending the destroy (kill) event.  Of course that is going a bit too far!

Anthony Thyssen

unread,
May 16, 2017, 2:10:24 AM5/16/17
to Jordan Sissel, martin...@gmail.com, xdotool-users
That first should be  XDeleteWindow()  (for the 'close' event)  and not XDestroyWindow()  (the 'kill' action)

It may be that the xdotool  "windowkill" also needs a little work, as running the command

   xdotool selectwindow windowkill

kills my window manager (openbox) rather than the window and the associated client, when I use it against one of a number of "gedit" windows (for testing).   The "windowkill" however worked fine (killing the client and all its windows) when I used the proper application WindowID, just as the "xkill" command does.

So perhaps that function needs to be fixed first, then whatever method it uses, should be used to create a proper "windowclose" function.


On Tue, May 16, 2017 at 1:56 PM, Jordan Sissel <j...@semicomplete.com> wrote:
A quick glance at this issue and some (very brief) research, it seems we have three options:

1) Add support to invoke XDestroyWindow
2) Add support to send a ClientMessage with WM_CLOSE_WINDOW
3) Add support to send a ClientMessage _NET_CLOSE_WINDOW to the window manager.

We could support all 3. I don't think it will be much code.

-Jordan

On Mon, May 15, 2017 at 4:30 PM, Anthony Thyssen <a.th...@griffith.edu.au> wrote:
Maybe, But the delete window function is a very basic (core X Windows) control that xdotool can not currently do.

Another tool with this function is xclosedown  which sends a delete (close) window event to all applications, then waits 30 seconds before sending the destroy (kill) event.  Of course that is going a bit too far!

Justin C

unread,
May 16, 2017, 4:06:55 AM5/16/17
to xdotool-users
Where Untitled is the title of the window

kill_it=$(xdotool search --name Untitled getwindowpid);

kill $kill_it



Anthony Thyssen

unread,
May 16, 2017, 8:26:55 PM5/16/17
to jtcha...@gmail.com, xdotool-users
That would not work for all applications.  Applications don't set the clients PID.  It also will not work for a remote X Window application running on another machine.  Something I do all the time when administrating hundreds of machines!

Also the report is to try and help improve "xdotool" with something very basic, that it should have, but for some reason does not.

I am not trying solve a problem *I* am currently having.

  Anthony Thyssen ( System Programmer )    <A.Th...@griffith.edu.au>
 --------------------------------------------------------------------------
 DISCLAIMER - These opoi^H^H "damn", ^H, [esc :q :qq !q "shit!" :Q!  "Whaddya
 mean, Not an editor command?" :wq! ^C^C^C !STOP ^bye ^quit :quit! !halt ...
 ^w^q :!w :wq! ^D :qq!! ^STOP [HALT!   HALT!!! "Why's it doing this?" :stopit!
 :wwqq!! ^Z ^L ^ESC STOP  :bye  bye  bye! "Hey, what's this red button d..."
 --------------------------------------------------------------------------
   Anthony's Castle     http://www.ict.griffith.edu.au/anthony/



martin...@googlemail.com

unread,
May 19, 2017, 8:57:01 AM5/19/17
to xdotool-users, jtcha...@gmail.com, A.Th...@griffith.edu.au
"Also the report is to try and help improve "xdotool" with something very basic, that it should have, but for some reason does not."

That's why I said that xwit is about 2k LoC and has little dependencies.
One could use that or integrat it in xdotool but xwit does not have such functionality
(I have not that time currently and I'm also a noob).
I think that he is using wmctrl
which supports this functionality with exactly the same arguments.
It is still part of the fedora repositories.

I looked into wmctrl source code and the important bits:
-Getting the currently active window:
    Display *disp = XOpenDisplay(NULL)
    static int action_window_str (Display *disp, char mode) {
    static Window get_active_window(Display *disp)
    get_property(disp, DefaultRootWindow(disp), XA_WINDOW,  "_NET_ACTIVE_WINDOW", &size);
    XGetWindowProperty
-Closing the window:
    static int close_window (Display *disp, Window win) {
        return client_msg(disp, win, "_NET_CLOSE_WINDOW",  0, 0, 0, 0, 0);
        }
    static int client_msg(Display *disp, Window win, char *msg, /* {{{ */
        unsigned long data0, unsigned long data1,
        unsigned long data2, unsigned long data3,
        unsigned long data4) {
     XSendEvent

Should be fairly easy to do for some who programs regulary in C.

Am Mittwoch, 17. Mai 2017 02:26:55 UTC+2 schrieb Anthony Thyssen:
That would not work for all applications.  Applications don't set the clients PID.  It also will not work for a remote X Window application running on another machine.  Something I do all the time when administrating hundreds of machines!

Also the report is to try and help improve "xdotool" with something very basic, that it should have, but for some reason does not.

I am not trying solve a problem *I* am currently having.

  Anthony Thyssen ( System Programmer )    <A.Th...@griffith.edu.au>
 --------------------------------------------------------------------------
 DISCLAIMER - These opoi^H^H "damn", ^H, [esc :q :qq !q "shit!" :Q!  "Whaddya
 mean, Not an editor command?" :wq! ^C^C^C !STOP ^bye ^quit :quit! !halt ...
 ^w^q :!w :wq! ^D :qq!! ^STOP [HALT!   HALT!!! "Why's it doing this?" :stopit!
 :wwqq!! ^Z ^L ^ESC STOP  :bye  bye  bye! "Hey, what's this red button d..."
 --------------------------------------------------------------------------
   Anthony's Castle     http://www.ict.griffith.edu.au/anthony/

On Tue, May 16, 2017 at 6:06 PM, Justin C <jtcha...@gmail.com> wrote:
Where Untitled is the title of the window

kill_it=$(xdotool search --name Untitled getwindowpid);

kill $kill_it



--
You received this message because you are subscribed to the Google Groups "xdotool-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xdotool-user...@googlegroups.com.

Anthony Thyssen

unread,
May 21, 2017, 2:48:19 AM5/21/17
to martin...@googlemail.com, xdotool-users, jtcha...@gmail.com
Yes..  "wmctrl" has it

I am using it used from "easystroke" mouse gestures to close windows. 

wmctrl -c :ACTIVE:

But came about because xwit was no longer a standard install and I have been trying to change everything to use one single programs for all windowing functions, instead of three different programs

Apologies for the confusion.


martin...@googlemail.com

unread,
May 21, 2017, 11:26:24 AM5/21/17
to xdotool-users, martin...@googlemail.com, jtcha...@gmail.com, A.Th...@griffith.edu.au
Just in case someone wants to implement the functionality
with the help of wmctrl. It's all in the main.c file and
you can directly search every part that I mentioned in the previous post.

Except for the first line.
There is no line containing the String "Display *disp = XOpenDisplay(NULL)".
Instead it is divided into "Display *disp;" and "if (! (disp = XOpenDisplay(NULL))) {".
Reply all
Reply to author
Forward
0 new messages