Missing from openbox dock

[GoogleCodeExporter]

Tint2 no longer uses the openbox dock with panel_dock = 1 (since r680).  

The configuration parameter panel_dock specifies that tint2 should present 
itself as a "dockapp".  Dockapps are primarily utilized in WindowMaker and 
Afterstep, but are also employed by Openbox, Fluxbox, and Pekwm.

Reverting the following change should restore "dockapp" capability:

panel.c        
        // Unfocusable
        XWMHints wmhints;
-       if (panel_dock) {
-               wmhints.icon_window = wmhints.window_group = p->main_win;
-               wmhints.flags = StateHint | IconWindowHint;
-               wmhints.initial_state = WithdrawnState;
-       }               
-       else {  
-               wmhints.flags = InputHint;
-               wmhints.input = False;
-       }               
+       wmhints.icon_window = wmhints.window_group = p->main_win;
+       wmhints.flags = StateHint | IconWindowHint;
+       wmhints.initial_state = WithdrawnState;
+       wmhints.flags = InputHint;
+       wmhints.input = False;
        XSetWMHints(server.dsp, p->main_win, &wmhints);

        // Undecorated

Original issue reported on code.google.com by goo...@craigoakes.com on 7 Feb 2015 at 7:59

[GoogleCodeExporter]

I see. Looking at that patch, I made a mistake when setting the flags. The 
correct version should be:

WMHints wmhints;
memset(&wmhints, 0, sizeof(wmhints));
wmhints.flags = StateHint | IconWindowHint | InputHint;
wmhints.initial_state = WithdrawnState;
wmhints.icon_window = wmhints.window_group = p->main_win;
wmhints.input = False;
XSetWMHints(server.dsp, p->main_win, &wmhints);

I looked at the documentation to understand what these do:

* wmhints.input = False;

According to http://tronche.com/gui/x/icccm/sec-4.html#WM_HINTS , False means 
we use either the Globally Active or the No Input focus models. No Input means 
that we do not need focus for keyboard input--which is the case for us.

* wmhints.initial_state = WithdrawnState;

The states are described here: 
http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.4 but it is not exactly 
enlightening.

I found this discussion http://lists.windowmaker.org/dev/msg01605.html 
explaining that WithdrawnState and icon_window in the hints are necessary to 
place the panel in the dock on some WMs, including Openbox.

* wmhints.icon_window = p->main_win;

See above.

* wmhints.window_group = p->main_win;

"A set of top-level windows that should be treated from the user's point of 
view as related (even though they may belong to a number of clients) should be 
linked together using the window_group field of the WM_HINTS structure. [...] 
It is up to the window manager to determine the policy for treating the windows 
in a group."

Updated in r688.

Original comment by mrovi9...@gmail.com on 7 Feb 2015 at 8:33

• Added labels: Component-Panel

[GoogleCodeExporter]

Now after r688, tint2 will not run outside of the native openbox dock.  Tint2 
has always been able to run in either mode under openbox: panel_dock = 0 was 
normal tint2 operation and panel_dock = 1 was dockapp/native dock operation.

It really needs to support both, as in:

WMHints wmhints;
memset(&wmhints, 0, sizeof(wmhints));
if (panel_dock) {
    wmhints.flags = StateHint | IconWindowHint | InputHint;
    wmhints.initial_state = WithdrawnState;
    wmhints.icon_window = wmhints.window_group = p->main_win;
}
else {
    wmhints.flags = InputHint;
    wmhints.input = False;
}

Original comment by goo...@craigoakes.com on 7 Feb 2015 at 11:46

[GoogleCodeExporter]

I see. So in the end I guess we will revert this change. At least we figured 
out why the WMHints were set like that.

Let's see if it is possible to fix issues 455, 461 and 465 all at the same time.

Original comment by mrovi9...@gmail.com on 8 Feb 2015 at 9:43

[GoogleCodeExporter]

Is it normal for tint2 to have a white, thin border in openbox when in dock 
mode? I'm using the Clearlooks theme. The border is drawn by openbox, because 
when I change the theme it changes colors.

Original comment by mrovi9...@gmail.com on 8 Feb 2015 at 10:03

[GoogleCodeExporter]

Committed r689.

I could not get rid of the border even with "osd.border.width: 0" in 
/usr/share/themes/Clearlooks/openbox-3/themerc and obconf > Appearance > 
Windows retain a border when undecorated unchecked. If this is normal, fine.

I found that I had to set <noStrut>no</noStrut> in the <dock> section of 
~/.config/openbox/rc.xml otherwise openbox would not respect tint2's struts 
settings (i.e. maximized windows would cover the panel).

Original comment by mrovi9...@gmail.com on 8 Feb 2015 at 10:28

[GoogleCodeExporter]

Related: issue 257.

Original comment by mrovi9...@gmail.com on 8 Feb 2015 at 10:42

[GoogleCodeExporter]

In my configuration (a version of shiki-colors for openbox), openbox adds a 
border to tint2 in the native dock (panel_dock = 1).  I am under the impression 
that this is configurable in the openbox theme, but have never tried to modify 
it since I typically use panel_dock = 0 with openbox.  I wager this "feature" 
is another reason why the majority of openbox users avoid the native dock.

Original comment by goo...@craigoakes.com on 8 Feb 2015 at 10:54

[GoogleCodeExporter]

I am under the impression that the dock/slit/iconWindow of windowmaker, 
afterstep, fluxbox, openbox, pekwm was designed to contain *multiple* 64x64 
pixel static icons (representing minimized windows) and dockapps running in 
64x64 pixel windows.  Tint2 has extended this functionality.

Running tint2 as a dockapp is not well suited to openbox.  The native dock adds 
window decorations and historically has had issues with transparency and 
compositing.  The major openbox distros (ArchBang, CrunchBang, Manjaro Openbox, 
et al) do not employ the native dock presumably to avoid these limitations.  
Unless a user specifically needs to support dockapps, panel_dock = 0 should be 
the recommended configuration for openbox.

Original comment by goo...@craigoakes.com on 8 Feb 2015 at 11:25

[GoogleCodeExporter]

Original comment by goo...@craigoakes.com on 8 Feb 2015 at 11:26

[GoogleCodeExporter]

I see.

In the meantime I found another possible problem with the hints: we are setting 
the window_group member, but we are not setting the WindowGroupHint flag. This 
does not make sense. So we could either set the flag, or drop the window_group 
setting. I'm not sure what side effects either change would have :(

The commit that introduced the window_group is r172.

Original comment by mrovi9...@gmail.com on 8 Feb 2015 at 11:54

[GoogleCodeExporter]

From what I can see in the Openbox code, if we do not set the flag, it zeroes 
the window_group member.

http://git.openbox.org/?p=dana/openbox.git;a=blob;f=openbox/client.c;h=c97abd5ac
184d93428f69a40be7ee64b23dfe20f;hb=HEAD#l2033

A safe approach would be to either not set the window_group, or leave the code 
as it is.

Original comment by mrovi9...@gmail.com on 8 Feb 2015 at 12:09

[GoogleCodeExporter]

If the missing WindowGroupHint has no identifiable impact on running tint2 and 
there are no open reported issues, then I think it should be opened as a 
separate NeedInfo issue until there is an identifiable problem.  Dropping the 
window_group *might* negatively impact one of the "dockapp" friendly window 
managers. 

Original comment by goo...@craigoakes.com on 8 Feb 2015 at 12:10

[GoogleCodeExporter]

Original comment by mrovi9...@gmail.com on 21 Mar 2015 at 11:35

• Added labels: Milestone-0.12

[GoogleCodeExporter]

Project moved to GitLab.

You can find this issue at: https://gitlab.com/o9000/tint2/issues/465

Original comment by mrovi9...@gmail.com on 25 Apr 2015 at 11:14

• Added labels: GitLab

[GoogleCodeExporter]

Unfortunately I could not find a way to CC you on GitLab, so commenting here.

I am considering reverting the change to the window flags to (probably) what 
tint2 used in 0.11. The change has some unexpected side effects as explained 
here:

https://gitlab.com/o9000/tint2/issues/465#note_1149941

Original comment by mrovi9...@gmail.com on 27 Apr 2015 at 11:14

[GoogleCodeExporter]

Hi Ovi,

Yes, I can see why this is problematic.  If there is no good solution, 
reverting to original behaviour seems entirely appropriate.  I will let 
you know if I have any other ideas.

Ciao,
Craig

Original comment by goo...@craigoakes.com on 27 Apr 2015 at 12:34

[GoogleCodeExporter]

I found a middle ground: if panel_layer = normal and panel_dock = 0, then the 
new behavior is used (window type set to splash), as it is the only way to get 
normal stacking working.

But if panel_layer is top or bottom and panel_dock = 0, the old behavior is 
used.

If panel_dock = 1 then tint2 is placed into the dock.

Original comment by mrovi9...@gmail.com on 3 May 2015 at 7:42