AWN Window Area takes up a Large Area under Openbox

[Tsuki]

Under Openbox (possibly *box), the AWN window covers a large area (bottom 100px or so, full width of the screen). While most of this is transparent, it still registers as AWN being on top and thus does not pass clicks through to the window underneath as it does in, say, GNOME.

This is reported here:

http://wiki.awn-project.org/FAQ#AWN_grabs_the_focus_on_a_large_piece_of_the_screen_in_Openbox._How_do_I_fix_this.3F

However, the suggested fix doesn't work for me in Openbox 3.4.7-pre2, AWN 0.3.1, xcompmgr 1.1.3 under Ubuntu Hardy. Fiddling with the auto-hide and hide-under-maximized-windows settings in AWN has no effect.

I'm not sure if this is strictly speaking an AWN bug or an Openbox one, but if nothing else any suggestions on how to determine where the problem is would be appreciated.

[dustigroove (dustigroove)]

I will confirm this bug.

It appears that AWN occupies a rectangular region stretching from the left side of the screen to the right side, and up to where the rollover text boxes appear above the dock, Other windows are allowed to occupy the same area above the dock where the text notifications appear but AWN grabs the mouse clicks effectively not allowing you to work within the portion of the windows that are "covered" by AWN.

[dustigroove (dustigroove)]

To clarify further on my confirmation of this bug, I too am using AWN (0.3.1) under Ubuntu Hardy / Openbox (3.4.7.2) and the suggested fix in the Wiki did not work for me either.

[dustigroove (dustigroove)]

A small correction - the fix from the Wiki did have some impact. Previous to adding the application/layer entry in the Openbox rc.xml file the affected area spanned across the full screen, afterward it only impacted the space directly above the dock itself. However, in this area the issue persists (windows are transparently covered by AWN where the text hover boxes appear).

[Mark Lee (malept)]

Unfortunately, none of the developers run Openbox (or any *box window manager, to my knowledge). Have either of you asked the Openbox developers if they have any ideas as to how to fix this? (This sort of bug is not my specialty, so this is why I'm asking.)

Alternatively, could you make sure it's not an xcompmgr-specific bug and see if the Cairo Compositing Manager also exhibits the same behavior?

http://cairo-compmgr.tuxfamily.org/

[dustigroove (dustigroove)]

Okay, it looks like I've got it functioning properly now. The key is to follow the Wiki fix but instead address the application window by its class and not name.

So this should be the entry in the rc.xml file:

      <application class="Avant-window-navigator">
 <layer>below</layer>
      </application>

On a separate note, wasn't even familiar with the cairo-compmgr project, thanks.

[moonbeam (rcryderman)]

As an additional note this is probably the same issue that shows(has shown) in various compiz plugins where they were not covering the transparent part of the window when maximizing/snapping etc. The solution is to have them pay attention to the strut instead when the application is a dock.

[dynamotwain (dynamotwain)]

Window managers cannot assume window boundaries based on struts when the programs themselves do not set struts. AWN doesn't set struts when displaying in 'flat' mode and thus Openbox or any other WM can't use them.

The true cause of the problem is that Openbox reparents undecorated windows inside a frame window of its own creation. Doing so causes the frame window to receive the events rather than the window behind the frame.

I've filed a bug against Openbox at http://bugzilla.icculus.org/show_bug.cgi?id=3799 describing the issue.

[dynamotwain (dynamotwain)]

I've written a patch for Openbox to support windows with a ShapeInput mask (i.e. avant-window-navigator). For those of you who are comfortable compiling programs yourself and don't want to wait for the next release of Openbox whenever that may be, you can get the patch off of Openbox's bug tracker here: http://bugzilla.icculus.org/attachment.cgi?id=1893

[Michal Hruby (mhr3)]

Setting as Invalid, as this is Openbox problem.

[Julian Lam (julian-lam)]

avant-window-navigator:
  Installed: 0.3.2.1-4ubuntu1
  Candidate: 0.3.2.1-4ubuntu1
  Version table:
 *** 0.3.2.1-4ubuntu1 0
        500 http://ubuntu.mirror.rafal.ca karmic/universe Packages
        100 /var/lib/dpkg/status

===

Upstream (I think that's the term for it?) reported the bug fixed, closed it, and supposedly, the changes were in the git repository.

That was in January of 2009 --> Any idea why it hasn't filtered down into the Ubuntu repositories yet?

[Julian Lam (julian-lam)]

Disregard, I'm an idiot - totally glossed over the fact that it's not an awn problem...