Weird gtkdialog bug [SOLVED]

[MochiMoppel]

I need a dialog that
- has a defined height
- opens at current mouse position
- exits when it loses focus (e.g. user clicks outside of dialog)

Something like this:

Code: Select all

export DIALOG='
<window  height-request="200" window-position="2">
<button ok></button>
<action signal="focus-out-event">Exit:0</action>
</window>'
gtkdialog -p DIALOG

This code does not work when no other windows are open in current desktop (or all other windows are minimized) and the dialog is called from a keyboard shortcut or ROX panel. However it works when the mouse pointer is over the JWM tray. It also works on such otherwise empty desktop when any one of the conditions
- window-position="2"
- height-request
- action signal="focus-out-event"
is removed. It also works when height is set to a smaller size or window-position set to 1

On desktops where at least one other window exists everything works as expected. Any idea how to prevent this bug?
 
 
 

[don570]

Just a guess…

Have you tried putting a frame inside the window and giving
it some width and height request??? I've noticed that frames
make gtkdialog act more reliably.

I've also added in other widgets such as text widgets
as a way of getting a minimum height. That is a method to avoid

height-request="200"
_________________________________

Maybe adding
<hseparator></hseparator>

or

<vseparator></vseparator>

would make it act different??


__________________________

[MochiMoppel]

Have you tried putting a frame inside the window and giving it some width and height request???

width and height for a frame?

No, nothing works. I think the problem is that gtkdialog and the window managers have different ideas what constitutes a focus-out-event. For example this works differently in Openbox and JWM:

Code: Select all

export DIALOG='
<window  skip_taskbar_hint="true" >
<button ok></button>
<action signal="focus-out-event">beep</action>
</window>'
gtkdialog -p DIALOG

Openbox would beep even when resizing the dialog window but would ignore when another window gets focus. Very strange.

[don570]

Zigbert uses a separate app to make a right click pop up a window.
Examples : pfind and pmusic
However it does have a bug in Openbox window manager.

____________________________________________________

[MochiMoppel]

On desktops where at least one other window exists everything works as expected. Any idea how to prevent this bug?

Yes, MochiMoppel

I finally figured out that this is a timing problem. When nothing else has focus I guess that JWM tries to switch focus immediately to the newly creating gtkdialog window, but for some settings gtkdialog needs time and when gtkdialog takes too long JWM loses patience and sends a focus-out event. Gtkdialog dies an untimely death.

The solution is to prevent a focus-out action while the gtkdialog window is still under construction. I save the start time in a variable and prevent any focus-out action for 50 centiseconds after start:

Code: Select all

#!/bin/bash
export DIALOG=' 
<window  height-request="200" window-position="2"> 
<button ok></button> 
<text visible="false">
	<variable>START</variable>
	<input>date +%s%2N</input>
</text>
<action signal="focus-out-event" condition="command_is_true(NOW=$(date +%s%2N);[ $((NOW-START)) -gt 50 ] && echo true)">Exit:0</action>
</window>' 
gtkdialog -p DIALOG

[step]

Fyi, the dialog you posted above doesn't behave as described in post #1. I'm on Fatdog64 with openbox and test the dialog by opening a Terminal window and typing

Code: Select all

sh << EOF
#!/bin/bash 
export DIALOG=' 
<window  height-request="200" window-position="2"> 
<button ok></button> 
<text visible="false"> 
   <variable>START</variable> 
   <input>date +%s%2N</input> 
</text> 
<action signal="focus-out-event" condition="command_is_true(NOW=$(date +%s%2N);[ $((NOW-START)) -gt 50 ] && echo true)">Exit:0</action> 
</window>' 
gtkdialog -p DIALOG
EOF

I see an OK box under the mouse pointer, move the mouse outside the window and nothing happens. Clicking the window under the OK box switches the active window but the OK box is still running. Clicking the OK button closes the OK box.

[MochiMoppel]

Fyi, the dialog you posted above doesn't behave as described in post #1. I'm on Fatdog64 with openbox

step, thanks for testing. I checked again and your observations confirm what I already mentioned in my 2nd post: openbox interprets <action signal="focus-out-event"> differently. The original script "works" in openbox in the sense that it always opens the dialog, but then the dialog doesn't close as it should. Not a problem for me as I don't use openbox anymore.