awesome

Welcome to awesome bug tracking system.
Tasklist

FS#240 - Awesome should support _NET_WM_WINDOW_TYPE_DOCK

Attached to Project: awesome
Opened by Tim Allen (Screwtape) - Saturday, 02 August 2008, 06:06 GMT
Last edited by Julien Danjou (jd) - Friday, 26 September 2008, 15:14 GMT
Task Type Feature Request
Category Core
Status Closed
Assigned To No-one
Operating System All
Severity Very Low
Priority Normal
Reported Version 2.3.3
Due in Version 3.1
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

I've been a GNOME/Metacity user for quite some time, but after noticing that my usual workspace layout was composed of manually-tiled terminals I decided to give automatic tiling a try. Unfortunately, GNOME does many more things than merely managing windows, and some of that functionality (screensaver configuration, desktop image selection, automatically mounting USB disks when I plug them in) I would like to keep around.

As far as I can tell, there are two ways to use GNOME and Awesome together:

- put "export WINDOW_MANAGER=awesome" into ~/.gnomerc

- pro: very, very easy
- con: your screen is filled with maladjusted panels and such that Awesome
can't handle

- hunt down all the things that gnome-session runs apart from Metacity, and
run them manually in ~/.Xclients before starting awesome.

- pro: Awesome doesn't get horribly confused by docks and desktops.
- con: After a few months, there's still things I can't get working.

The nicest possible resolution of this conflict, as far as I can tell, would be for Awesome to support _NET_WM_WINDOW_TYPE_DOCK windows like the GNOME panel, so that I can use the first option and get all my GNOME functionality back.

For completeness, here's a description of how _NET_WM_WINDOW_TYPE_DOCK windows work at the moment and how I'd expect them to work:

Steps to reproduce:
- Start gnome-panel while Awesome is running (or any other application that
creates a _NET_WM_WINDOW_TYPE_DOCK window). I have my GNOME dock configured
to be 24px tall and located across the top of my screen.

Expected behaviour:
- A 24px-tall window would appear across the top of my screen, containing my
configured menus, launchers and applets.
- It would appear just below the tag bar/window list.
- It would be present no matter which tag was selected (just like the tag
bar/window list)
- It would be hidden and shown with the tag bar/window list.
- Dragging an empty spot (a place with no widgets) would let you move the
panel to different sides of the monitor, just like in Metacity.

Actual behaviour:
- A window appears that takes up all available space on my monitor, the top
24-pixels of which display the panel and the rest of which is wasted.
- I open a terminal (or some other window), which takes up residence in the
right half of my display. The left half now displays the left half of my
panel in the top 24px; the right half is inaccessible and everything belown
the 24px is still wasted.

Notes:
- "full" GNOME support would involve a lot of extra feature I'm prepared to
do without: for example, _NET_WM_WINDOW_TYPE_DESKTOP support, integration
with the GNOME pager and window-switcher plugins, etc. Most of these can be
easily disabled in GNOME without degrading functionality, but it seems the
panel cannot.
- Here's XMonad's page on GNOME integration:

http://www.haskell.org/haskellwiki/Xmonad/Using_xmonad_in_Gnome

XMonad does support _NET_WM_WINDOW_TYPE_DOCK, but, well.. Haskell. :<
- For completeness, here's my current (i.e. partially broken) .XClients file,
in case somebody else wants to run GNOME and Awesome together in vague
harmony:

# nitrogen is a desktop-image setting app
~/bin/nitrogen --restore &
~/bin/xcompmgr -n &
/usr/libexec/gnome-settings-daemon &
/usr/bin/gnome-screensaver &
/usr/bin/ssh-agent ~/tim/bin/awesome

Differences from GNOME/Metacity include:
- Won't set GNOME-configured desktop image on startup
- Won't auto-mount USB drives.
- Probably other things.
This task depends upon

Closed by  Julien Danjou (jd)
Friday, 26 September 2008, 15:14 GMT
Reason for closing:  Implemented
Comment by Julien Danjou (jd) - Saturday, 02 August 2008, 07:01 GMT
AFAICT, awesome 3 support for dock seems to a bit be better than what you describe.

However, one thing we do not support is _NET_WM_STRUT and _NET_WM_STRUT_PARTIAL which would allow to reserve space in the workarea for windows like panels.
Comment by Tim Allen (Screwtape) - Saturday, 02 August 2008, 09:57 GMT
Ah, well, in that case I guess I'd like _NET_WM_STRUT support too (I can't think of a sensible thing for Awesome to do with _NET_WM_STRUT_PARTIAL, and the EWMH spec suggests that clients that use _NET_WM_STRUT_PARTIAL will supply _NET_WM_STRUT as well)
Comment by Marc-Andre Lureau (elmarco) - Monday, 08 September 2008, 08:32 GMT
The docks should probably be displayed in front, unless they don't have the focus. (currently, one must switch to an empty desktop). This is reproducible when the dock have the "auto-hide" property.
Comment by Julien Danjou (jd) - Monday, 08 September 2008, 11:14 GMT
FWIW this will be fixed in 3.1 and it's fixed in next branch.

Loading...