Killing a window in icewm

[rubyFeedback]

This is less an issue request and more a description of a minor issue.

Before I will explain it, let me explain to you how I "discovered" that issue. This may help understand the point of view.

There is a small cross-platform called LibUI. There are also ruby bindings to it, and I maintain a gem that simplifies these bindings, called libui_paradise. As an indirect consequence we create widgets and GUI elements in a simple manner.

For example, the current DSL I use (and I try to simplify it even further), is looking like this:

require 'libui_paradise/autoinclude'

main_window = ui_main_window('Youtube Downloader', 1200, 200, 0)
outer_vbox = ui_vbox

hbox = ui_hbox
@entry_URL_to_use_for_the_youtube_video = ui_entry
hbox << @entry_URL_to_use_for_the_youtube_video
hbox << ui_button('TEST')
outer_vbox << hbox

main_window.child = outer_vbox
main_window.intelligent_exit

This is actually eventually a clone of my ruby-gtk3 widget set. Evidently unfinished.

Now ... before I changed something, I had the issue that the exit-action was not properly registered, so I was left with an open "stray" window. I could try to click on the exit button, and after some seconds or so, some dialog popped open which I think came from icewm. It asked me whether I want to kill it. I said yes (or ok) and ... nothing happened.

Right clicking on it and then exit application also did not do anything.

The only thing that actually helped was using "sleep 2; xkill", which I tend to do a lot. :-)

That this libui-specific widget did not properly close is NOT the fault of icewm. So one can not blame icewm for it. But it is still a bit awkward to me that the desired icewm-specific kill action for a window is not working - even if this relates to improperly created xorg-resources / widgets (which, again, is not icewm's fault). But xkill works, so I can conclude that destroying such a stubborn window is possible.

Now ... I don't know if it is worth to add more code in this regard, because "improper windows" like the above description, is most likely a super-rare thing. So I think it is better to just close the issue request - that was the main point of it, to inform icewm devs and users about such rare corner cases.

IF however had one day someone may want to improve on the related aspects then perhaps the functionality that xkill makes uses of could also be integrated into the icewm window that shows up. Perhaps not on a first run but if the window is shown again there could be an additional button that says something along the lines of "close it very forcibly" or something like that; or, perhaps even simpler, delegate onto xkill directly. That may be the least amount of work/code.

But again - I am not even certain whether my proposed change would be useful. If only 0.0001% of a user base ever find something like that then more code added may not be worth the trade off of maintaining that code. So In that event I would like to consider this mostly as information, and less as a request to change anything, unless this affects more users.

Thanks for reading my lengthy explanation!

PS: I actually did not know of that feature in icewm; either I have missed it or it was added more recently. The ruby libui bindings unfortunately do not behave perfectly fine either; in ruby-gtk all closes decently. In ruby libui I can not get control-c to break the application; I have to hit the exit button or quit action on the top right side ... just a bit more information.

[gijsbers]

Can you use Shift + click-on-close-button? That uses the same XKillClient function as xkill. If you want to understand what is going on, you need to consider that IceWM is compliant to the ICCCM and EWMH standards. Your client will advertise the protocols it wishes to use with the window manager. IceWM then accepts this offer. But if your client then fails to live up to its promise, then icewm can't be blamed. Therefore, examine your clients communication with the WM, show us the proof of any mistakes. XKillClient is both a rather crude way to terminate a client, and an unreliable way. Most(?) clients are unprepared and are terminated by Xlib. Some handle it gracefully, others continue in an endless loop, consuming 100% of a CPU. The preferred method to terminate a client is to send a SIGTERM signal, which the client should use to terminate its own business.