Detached plugins are breaking ShowDesktop actions because they are "normal" windows

[Jehan]

Hi,

on Openbox, when I show the desktop while having some plug-in detached from the dock, I can't hide the desktop back because the detached plug-ins are windows of type "normal" and they try to show themselves immediately after a ShowDesktop (hence breaking its revert action).

Dana Jansens, the Openbox developer says:
------------------
So right, because openbox hides "normal" windows, it hides the clock. The clock then immediately shows itself again, causing openbox to not restore stuff.

I think the clock should be a type "dock" or type "desktop" window (depending if they want it above or below other windows).

Otherwise, if the window is going to be a "normal" window, it shouldn't try to prevent itself from being hidden.

[...]

The clock plugin is actually doing a MapRequest, and then also a NET_ACTIVE_WINDOW request when it is hidden, which also causes it to take focus. It seems rather misbehaved in this regard.
-------------------

You can check his full diagnosis of the situation on the Openbox bug report, and also in particular in this comment, he gives debug output: https://bugzilla.icculus.org/show_bug.cgi?id=6023#c6

Note: I am not sure if this is specific to some plug-ins. It has been verified by myself with the clock and the notification area plug-ins at least (and the OpenBox maintainer saw also the behavior with the "Desktop Pager"). I have not tried to detach exhaustively all plug-ins but it looks kind of general.

Tested using the bazaar development branch.
$ cairo-dock -v
3.2.99.beta2

Distribution: Linux Mint 15
Window Manager: openbox

Reproduction Steps:
1/ openbox with cairo dock. Have the clock plug-in detached and shown on the desktop;
2/ have some normal windows opened;
3/ Show the desktop using openbox ToggleShowDesktop action; => the windows hide, as expected
4/ Try to "unshow" the desktop by repeating the ToggleShowDesktop action.

Expected result: the previously hidden window should unhide so that you get back to state of the desktop in step 2/.
Actual Result: all windows stay hidden.

[Jehan (jehan-marmottard)]

Note: I have tried also with the Cinnamon desktop.

What would happen there is that the detached clock plug-in would also be minimized by a call to ShowDesktop, which is also not expected (at least I think). I expect my detached cairo-dock plug-in to "belong to the desktop" and stay on the desktop when I "show" it, without blocking the revert "unshow" action.

[Fabounet (fabounet03)]

Hi,
thank you for reporting this bug (and for the useful details !)

First the reason why desklets are normal windows is to allow for usual
window placement by dragging it (activated by gtk_window_begin_move_drag,
which allows the WM to place it, including visual effects like "wobbling
window" for Compiz). Dock windows can't be moved like that (nor desktop
windows).
It also allows the desklet to be placed like normal windows, if ever the
user wants it.

Now, I think we can work around the first point, and the 2nd point is
probably useless (most probably, the user wants its desklets to be either
always above or always below).
So I think your point is valid, making them Dock windows is the solution (a
Desktop window wouldn't work because the main desktop window goes over it
when clicking on the desktop, making it invisible, at least I noticed that
on XFCE).

Meanwhile, please consider using the "Show-desktop" applet, which has 2
modes, one to hide every windows, another to hide windows except desklets
:-)

2013/9/9 Jehan <email address hidden>

> Note: I have tried also with the Cinnamon desktop.
>
> What would happen there is that the detached clock plug-in would also be
> minimized by a call to ShowDesktop, which is also not expected (at least
> I think). I expect my detached cairo-dock plug-in to "belong to the
> desktop" and stay on the desktop when I "show" it, without blocking the
> revert "unshow" action.
>
> --
> You received this bug notification because you are a member of Cairo-
> Dock Devs, which is subscribed to Cairo-Dock Plug-ins.
> https://bugs.launchpad.net/bugs/1222629
>
> Title:
> Detached plugins are breaking ShowDesktop actions because they are
> "normal" windows
>
> Status in Cairo-Dock: Plug-ins:
> New
>
> Bug description:
> Hi,
>
> on Openbox, when I show the desktop while having some plug-in detached
> from the dock, I can't hide the desktop back because the detached
> plug-ins are windows of type "normal" and they try to show themselves
> immediately after a ShowDesktop (hence breaking its revert action).
>
> Dana Jansens, the Openbox developer says:
> ------------------
> So right, because openbox hides "normal" windows, it hides the clock.
> The clock then immediately shows itself again, causing openbox to not
> restore stuff.
>
> I think the clock should be a type "dock" or type "desktop" window
> (depending if they want it above or below other windows).
>
> Otherwise, if the window is going to be a "normal" window, it
> shouldn't try to prevent itself from being hidden.
>
> [...]
>
> The clock plugin is actually doing a MapRequest, and then also a
> NET_ACTIVE_WINDOW request when it is hidden, which also causes it to take
> focus. It seems rather misbehaved in this regard.
> -------------------
>
> You can check his full diagnosis of the situation on the Openbox bug
> report, and also in particular in this comment, he gives debug output:
> https://bugzilla.icculus.org/show_bug.cgi?id=6023#c6
>
> Note: I am not sure if this is specific to some plug-ins. It has been
> verified by myself with the clock and the notification area plug-ins
> at least (and the OpenBox...

[Jehan (jehan-marmottard)]

Thanks.

After reading your first reason, I was wondering: is it possible to change the type of a window during its life? If so, a solution could be to have a "change position" menu item for a desklet, then make it temporarily "normal" when the user selects this item, and change back to "dock" when the user clicks somewhere else. For instance.
In Case a X window can't change its type, a similar behavior could be reproduce by destroying the window after saving its position, then recreating it at the same position but a different type.

Just an idea. If you have a better one, don't hesitate to implement it so. ;-)

Thanks!

[Jehan (jehan-marmottard)]

Hey,

if that suits you, I will likely propose a patch in the next few days.

[Fabounet (fabounet03)]

Another reason I forgot, is that normal windows can be resized with alt +
middle-click (or alt + right-click, depending on the WM).
Feel free to hack your way through the code and propose a patch :-)

2013/9/10 Jehan <email address hidden>

> Hey,
>
> if that suits you, I will likely propose a patch in the next few days.
>
> --
> You received this bug notification because you are a member of Cairo-
> Dock Devs, which is subscribed to Cairo-Dock Plug-ins.
> https://bugs.launchpad.net/bugs/1222629
>
> Title:
> Detached plugins are breaking ShowDesktop actions because they are
> "normal" windows
>
> Status in Cairo-Dock: Plug-ins:
> New
>
> Bug description:
> Hi,
>
> on Openbox, when I show the desktop while having some plug-in detached
> from the dock, I can't hide the desktop back because the detached
> plug-ins are windows of type "normal" and they try to show themselves
> immediately after a ShowDesktop (hence breaking its revert action).
>
> Dana Jansens, the Openbox developer says:
> ------------------
> So right, because openbox hides "normal" windows, it hides the clock.
> The clock then immediately shows itself again, causing openbox to not
> restore stuff.
>
> I think the clock should be a type "dock" or type "desktop" window
> (depending if they want it above or below other windows).
>
> Otherwise, if the window is going to be a "normal" window, it
> shouldn't try to prevent itself from being hidden.
>
> [...]
>
> The clock plugin is actually doing a MapRequest, and then also a
> NET_ACTIVE_WINDOW request when it is hidden, which also causes it to take
> focus. It seems rather misbehaved in this regard.
> -------------------
>
> You can check his full diagnosis of the situation on the Openbox bug
> report, and also in particular in this comment, he gives debug output:
> https://bugzilla.icculus.org/show_bug.cgi?id=6023#c6
>
> Note: I am not sure if this is specific to some plug-ins. It has been
> verified by myself with the clock and the notification area plug-ins
> at least (and the OpenBox maintainer saw also the behavior with the
> "Desktop Pager"). I have not tried to detach exhaustively all plug-ins
> but it looks kind of general.
>
> Tested using the bazaar development branch.
> $ cairo-dock -v
> 3.2.99.beta2
>
> Distribution: Linux Mint 15
> Window Manager: openbox
>
> Reproduction Steps:
> 1/ openbox with cairo dock. Have the clock plug-in detached and shown on
> the desktop;
> 2/ have some normal windows opened;
> 3/ Show the desktop using openbox ToggleShowDesktop action; => the
> windows hide, as expected
> 4/ Try to "unshow" the desktop by repeating the ToggleShowDesktop action.
>
> Expected result: the previously hidden window should unhide so that you
> get back to state of the desktop in step 2/.
> Actual Result: all windows stay hidden.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/cairo-dock-plug-ins/+bug/1222629/+subscriptions
>
> _______________________________________________
> Mailing list: https://launchpad.net/~cairo-dock-team
> Post to : <email address hidden>
> Unsubscribe : http...