xmonad tray in right wrong window placement about pnmixer

[hasufell]

I'm not 100% sure what you mean, but I get the following behavior:

• click tray icon -> dialog pops up at mouse position
• click anywhere else on the screen -> dialog goes away
• click tray icon again -> dialog now pops up in the very center of the screen

In popup_window.xml we have

  <object class="GtkWindow" id="popup_window">
    <property name="window_position">mouse</property>

So it should always be placed at mouse position.
I'm not sure if this is a gtk+ glitch not working properly with tiling window WMs (I use i3).

By accident I found out that this hack solves it for me, but I have no idea why:

--- a/src/main.c
+++ b/src/main.c
@@ -184,6 +184,10 @@ void tray_icon_button(GtkStatusIcon *status_icon, GdkEventButton *even$

 void tray_icon_on_click(GtkStatusIcon *status_icon, gpointer user_data) {
   get_current_levels();
+
+  gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (mute_check), FALSE);
+  gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (mute_check), TRUE);
+
   if (!gtk_widget_get_visible(GTK_WIDGET(popup_window))) {
     gtk_widget_grab_focus(vol_scale);
     gtk_widget_show(popup_window);

Another interesting case.

For testing purposes I put my trayer in top left corner. Now a popup shows next to icon(hard to say if this is top-left placement or correct placement next to icon) and when I press "Mod" key a popup window is closed.
This happens always when I do described scenario.

Now funny part, I try to mute a voice using "Mute" check-box. Now "Mod" key doesn't close popup.
So now I can move this popup window around.
When I move mouse outside window it is closed and a next placement on popup will be in a place previously closed.
BUT when popup is visible again and I press "Mod" key window is closed and a next placement will be reseted to top-left corner.

And ... when I kill this popup window with "Mod-Shift-C" (xmonad kill window command) pnmixer goes into invalid state and after clicking on tray icon an error is raised:

(pnmixer:2036): GLib-GObject-WARNING **: invalid uninstantiatable type '-g-type-private--GTypeFlags' in cast to 'GtkAdjustment'

(pnmixer:2036): Gtk-CRITICAL **: IA__gtk_adjustment_set_value: assertion 'GTK_IS_ADJUSTMENT (adjustment)' failed

(pnmixer:2036): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'GtkObject'

(pnmixer:2036): Gtk-CRITICAL **: IA__gtk_widget_grab_focus: assertion 'GTK_IS_WIDGET (widget)' failed

(pnmixer:2036): Gtk-CRITICAL **: IA__gtk_widget_show: assertion 'GTK_IS_WIDGET (widget)' failed


"-" and "+" buttons don't work either :/

[stevenhoneyman]

Oh! that reminds me of a small bug I found but didn't write down or fix!

@hasufell sorry I didn't get chance to work on this anymore yesterday or test out popen() changes - got sidetracked! I'll set some time aside tonight and/or tomorrow night

[hasufell]

I tried to fix this for one hour and only see a few dirty hacks that work. Basically this is tiling window managers screwing up. i3 honors the initial position of the volume meter popup, but then moves the window to the center of the screen next time you open it. We can work around it by simply moving it back (but that only works after it's already shown, so you will see it snap) or triggering some signals that seem to cause the wm to forget about it.

Anyway, I don't like either of it. I tried all wm hints in popup_window.xml there are, none of them fix the issue for the volume meter popup.

[bbidulock]

If you want it to behave like a menu you will have to make it one. Right now I show the following that the window is a dialog, with no WM_TRANSIENT_FOR, the regular unmapped 10x10 GTK client leader, program position (0,0), min and max width and height set 285x82, static gravity (which window managers ignore), _NET_WM_WINDOW_TYPE_DIALOG (which is wrong), _NET_WM_STATE_BELOW (which is weird, you must have asked for it), and I show it iconified instead of withdrawn.

There are a couple of things you could try: _NET_WM_TYPE_POPUP or even _NET_WM_TYPE_DOCK, set a user position (do you know to do that?, but propbably the best is to hook a "realize" signal callback and set override-redirect with gdk (this happens normally for menus) and grab the pointer when it maps (which will be released automatically when it unmaps).

It is not i3's or xmonad's fault. I tried with 3 or 4 other tiling window managers (including one I wrote) and it behaves poorly on the second popup. Some far worse that centering it like the parenteless dialogue that it preports to be. It is just what happens when you try (and fail) to get GTK to make a dialoge pretend to be a popup.

[bbidulock]

Another few oddities, GTK is using _MOTIF_WM_HINTS to try to say to undecorate the "dialogue". Only the oldies WM's obvserve _MOTIF_MW_HINTS over _NET_WM_WINDOW_TYPE. About the only window types that GTK will set on a non-override window are utility, dock, normal, dialog.

[hasufell]

If you want it to behave like a menu you will have to make it one.

I'd say that's impossible. GtkMenu limits us to GtkMenuItems. I don't see a way to construct GtkBox/GtkScale etc inside a GtkMenu.

There are a couple of things you could try: _NET_WM_TYPE_POPUP or even _NET_WM_TYPE_DOCK, set a user position (do you know to do that?, but propbably the best is to hook a "realize" signal callback and set override-redirect with gdk (this happens normally for menus) and grab the pointer when it maps (which will be released automatically when it unmaps).

Yeah, I am currently looking into making it a real popup, but that makes hiding the window on focus-out more difficult (because the popup doesn't really accept focus).

[bbidulock]

Looks like all one has to do is:

<object class="GtkWindow" id="popup_window">
<property name="type">popup</property> <!-- makes it a popup instead of a toplevel -->
<property name="window_position">mouse</property>

[stevenhoneyman]

That wasn't used because popup windows do not have GDK_FOCUS_CHANGE events

(I think it's been mentionned somewhere)

[hasufell]

Looks like all one has to do is:

popup mouse

see hasufell@21c0b9d

@stevenhoneyman I have already fixed that

[bbidulock]

Gee, just by adding that line it works fine in all my tiling window managers: pops up in the right place, pops down, again and again. It is now marked as an override-redirect window making the window manager leave it alone. You can turn on focus-in and focus-out events using gdk_window_set_events(widget->window, GDK_FOCUS_CHANGE_MASK|gdk_window_get_events(widget->window)) if you really want them.

[bbidulock]

hasufell, I need the change in nicklan/pnmixer not hasufell/pnmixer (I will never use gtk3). Was not this issue for nicklan/pnmixer?

[hasufell]

I will never use gtk3

Provide a pull request with an appropriate configure switch, ifdefs and separate xml files then.

[hasufell]

Gee, just by adding that line it works fine in all my tiling window managers: pops up in the right place, pops down, again and again. It is now marked as an override-redirect window making the window manager leave it alone. You can turn on focus-in and focus-out events using gdk_window_set_events(widget->window, GDK_FOCUS_CHANGE_MASK|gdk_window_get_events(widget->window)) if you really want them.

Doesn't work here. In addition, there is no "window" member in GtkWidget. I tried with 'gtk_widget_get_window(popup_menu)' and get 'assertion 'GDK_IS_WINDOW (window)' failed'. If you can make it work without the grabbing trick in 21c0b9d, provide a pull request.

[bbidulock]

Pardon, I was mixing gtk-perl and gtk. Yes you need to use gtk_widget_get_window(); however, the GdkWindow needs to be realized before you do so, so it must either be done from a "realized" signal callback on the widget or you have to do gtk_widget_realize() before gtk_widget_get_window(). Sorry, I thought you knew more about Gdk2/Gtk2.

[hasufell]

It would help more if you provide code.

[hasufell]

@krzychosan has this fixed your issue as well?

Issue is fixed for me.

Only one more small thing.
I have 2 terminals open next to each other(tiling layout) and I click on volume tray icon to show popup.
Because this is popup it doesn't grab focus which stays on one of terminals.
Now when I click on focused terminal a popup won't close. Only clicking on another terminal causes popup to close.

This might be related to xmonad rather than pnmixer but I will just let you know.

[nicklan]

This strikes me as an xmonad problem, since in i3 and openbox (where i've tested it so far), the focus is given to the popup (as it should be).

If you open the popup and then hit Esc, does that close it? Also, make sure you're on the latest master as there was a pointer/keyboard grabbing update merged yesterday.

[hasufell]

@krzychosan check out commit 13c74b5 and tell me if that works better for you

there were 2 solutions to this problem and the initial one was reverted since the other looked cleaner

Sorry for late response, all works great with this commit.

On Wed, Jul 9, 2014 at 12:27 AM, Julian Ospald [email protected]
wrote:

@krzychosan https://github.com/krzychosan check out commit 13c74b5
13c74b5
and tell me if that works better for you

there were 2 solutions to this problem and the initial one was reverted
since the other looked cleaner

—
Reply to this email directly or view it on GitHub
#37 (comment).

[hasufell]

@bbidulock do you have another idea? Otherwise I'd be inclined to revert to my initial solution from commit 21c0b9d

[bbidulock]

What's the problem? @krzychosan says it works great...

[hasufell]

What's the problem? @krzychosan says it works great...

He says it works great with my initial approach which I reverted in favour of your approach.

[bbidulock]

I don't think anyone is on the same commits. My popup-fix branch in the pull request works fine on all 36 window managers I have loaded (half of them tiling).

[bbidulock]

I just checked out and tried current master: 3a1659c --without-gtk3 and it does not work on the first window manager I tried (adwm). There is no pointer grab at all: the first EnterNotify event on another window that occurs moving the pointer outside the popup moves the focus to another window and the popup remains. You hand merge is incorrect in some way. In hide_me() you added:

if (event->type == GDK_BUTTON_PRESS && !gdk_window_at_pointer(&x, &y)) {
gtk_widget_hide(popup_window);
}

That was incorrect. There are three events reported on the top-level that need to hide the window: button presses, key releases and broken pointer grabs. I don't know what else you changed. The xml looks ok, but diff your main.c against mine at the end of my popup-fix branch.

[bbidulock]

You removed gtk_widget_grab_focus(vol_scale) from the end of create_popups(). That's a problem.

Also, the key press you added for GDK_KEY_Escape in hide_me() is wrong: keyboard events reported here are key releases while the pointer is outside the popup window. All of those should pop the window down. If you want to popdown on the ESC key, you need to connect to the key-press signal inside the popup where owner events are reported (e.g. on the GtkVBox). The button part will always fail: again, only pointer events from outside the owner window are reported on the popup and call hide_me(). Any event reported on the top-level are from outside the window. Other events (from within the popup) are reported normally to the widgets inside the window. That's what the TRUE means for owner-events in the pointer_grab and keyboard_grab.

Because broken grabs are reported here, if you click on some other window on the desktop, the WM takes a active grab on the pointer because it has passive grab on button clicks and the pointer grab on the popup gets broken. These pointer grab broken events are reported to hide_me(). So, change hide-me back to just gtk_widget_hide(popup_window) and the correct behaviour will ensue, but also add the gtk_widget_grab_focus(vol_scale) back to the end of create_popups(). I wish you had just merged the pull request.

[hasufell]

if (event->type == GDK_BUTTON_PRESS && !gdk_window_at_pointer(&x, &y)) {
gtk_widget_hide(popup_window);
}

That was done, because the initial behavior was incorrect... any click inside the popup window that didn't hit the scrollbar, checkbox or button caused it to be closed.

So I guess we could do:

if (event->type == GDK_BUTTON_PRESS) {
        if (!gdk_window_at_pointer(&x, &y))
            gtk_widget_hide(popup_window);
} else {
    gtk_widget_hide(popup_window);
}

You removed gtk_widget_grab_focus(vol_scale) from the end of create_popups(). That's a problem.

Why? It never gets focus here anyway. But sure, we can reinstate it.
edit: yes, seems gtk3 is different here

Also, the key press you added for GDK_KEY_Escape in hide_me() is wrong

I didn't add it. @nicklan added it in 92d1ecb and it works perfectly fine here. Also, if you remove that part of the code, you won't be able to move the volume slider with up/down keys anymore.

I wish you had just merged the pull request.

We did. See a07dbd2 and cd326e2

Besides... we are testing 2 different libraries...

[hasufell]

hasufell@9192eb7

@krzychosan can you test via

git clone --branch popup_fix https://github.com/hasufell/pnmixer.git pnmixer-popup_fix

not working, I need to click on a window without current focus to close popup.

[hasufell]

@krzychosan can you please test the latest commit from my popup_fix branch?

Works perfect.

Because latest version works for me I will close this issue.
Thanks for fixing

[hasufell]

@krzychosan what do you mean? the fix is not merged into this repository yet

Well I cloned this link to be completely sure "https://github.com/nicklan/pnmixer.git" and it works without mentioned issues.
e.g. there is no "+" and "-" buttons.