[dwm] Optional status bar

[Kurt H Maier]

Dwm creates a dock (status bar) of its own and manages unlike any other x
window. Dwm is configured to use a menu that, rather than being managed
like any other x window, requests exemption from window management. By
your logic, if dmenu is not best "rendered like any other x window" than
dmenu is broken, and so is the status bar.

Your logic is inconsistent. The status bar and dwm are not 'managed
unlike any other x window' because they are not managed at all. This
is, in my opinion, a superior alternative to overengineering a
ridiculous set of specifications to accomplish the simple things that
dmenu and the status bar provide. ewmh is flawed because it presumes a
specific interface paradigm. it provides nothing that dmenu or the
status bar need that cannot be provided with override-redirect.

I'll agree dwm would be improved with a simple way to access a list of
tags and which clients are mapped to them, but I don't think that has
anything to do with adhering to a mostly-inapplicable x window
specification.

A design decision moot by the very menu that dwm is configured for by
default and maintained along with. Remove override-redirect from dmenu,
and I'll believe this is a question of design.

Again, your logic is bad. dmenu's use of override-redirect is a big
part of why dmenu is so popular beyond dwm usage. Even the haskell guys
over at xmonad and the indescribable goons who make and use awesomewm
-- both groups use dmenu, because its simplicity and reliability is
pretty unassailable. Best of all, this list doesn't have to hear
whining about how dmenu isn't showing up right in <insert non-ewmh,
non-icccm window manager>. It, to coin a phrase, Just Works.

[Bjartur Thorlacius]

Post by Kurt H Maier

Dwm creates a dock (status bar) of its own and manages unlike any other x
window. Dwm is configured to use a menu that, rather than being managed
like any other x window, requests exemption from window management. By
your logic, if dmenu is not best "rendered like any other x window" than
dmenu is broken, and so is the status bar.

Your logic is inconsistent. The status bar and dwm are not 'managed
unlike any other x window' because they are not managed at all. This
is, in my opinion, a superior alternative to overengineering a
ridiculous set of specifications to accomplish the simple things that
dmenu and the status bar provide. ewmh is flawed because it presumes a
specific interface paradigm. it provides nothing that dmenu or the
status bar need that cannot be provided with override-redirect.

Fair enough. Keyboard grabbing and override-redirect make dmenu multisel
e.g. unusable for intermittent input. But as dmenu is intended to be
short-lived, that use case is simply out of scope anyway. I have the right
to fork dmenu and maintain the dock patch for dwm, so I'll stop
complaining.

[Tom Vincent]

Thanks for the discussion.

It seems we can conclude targeting ewmh/icccm is out of the question.
How about a new "suckless" protocol between dwm and its status bar?

Much like dmenu handles launching, there's still scope in separating
the status bar. Perhaps a compile-time option to disable it completely
if nothing else?

[Bjartur Thorlacius]

Post by Tom Vincent
Thanks for the discussion.
It seems we can conclude targeting ewmh/icccm is out of the question.
How about a new "suckless" protocol between dwm and its status bar?
Much like dmenu handles launching, there's still scope in separating
the status bar. Perhaps a compile-time option to disable it completely
if nothing else?

_NET_WM_TYPE_DOCK support and XEmbed tag switcher would do half the job.
A XID would still have to be sent. Any more complicated protocol would
have to go over DBus, which is not an option.

[Suraj N. Kurapati]

Post by Bjartur Thorlacius

targeting ewmh/icccm is out of the question. How about a new
"suckless" protocol between dwm and its status bar?

_NET_WM_TYPE_DOCK support and XEmbed tag switcher would do half
the job. A XID would still have to be sent. Any more complicated
protocol would have to go over DBus, which is not an option.

DBus is overkill. A named pipe or UNIX domain socket would suffice.

[Bjartur Thorlacius]

Post by Suraj N. Kurapati
DBus is overkill. A named pipe or UNIX domain socket would suffice.

I think even doing it the Xorg way would be an overkill.

I'm in favor of splitting tagging into a separate program drawing to a
subwindow of a panel. Some people use tagging, the dwm way, but others
grouping into workspaces. A decision one way or another should not limit
the choice of layouts. Layouts should be portable, at least as copyable
source code files between dwm derivatives.

[Kurt H Maier]

Post by Suraj N. Kurapati
DBus is overkill. A named pipe or UNIX domain socket would suffice.

I seem to recall someone exporting client and tag information via xprop.

[Bjartur Thorlacius]

Post by Tom Vincent
It seems we can conclude targeting ewmh/icccm is out of the question.

For tag switching at least.

[Bjartur Thorlacius]

This phrasing suggests an implicit approval of the way e.g.
ewmh-compliant software handles docks. dwm handles docks perfectly fine
-- it renders them like any other x window. if the dock doesn't like
it, that is the dock's problem, not dwm's.

Dwm creates a dock (status bar) of its own and manages unlike any other x
window. Dwm is configured to use a menu that, rather than being managed
like any other x window, requests exemption from window management. By
your logic, if dmenu is not best "rendered like any other x window" than
dmenu is broken, and so is the status bar.

not supporting ewmh is not a fault, it's a design decision.

A design decision moot by the very menu that dwm is configured for by
default and maintained along with. Remove override-redirect from dmenu,
and I'll believe this is a question of design.

[Patrick Haller]

When I think of it, I can't but wonder if we could write a program
that does tagging and tagging only, and a selection of separate
layout managers that automatically tile or maximize mapped windows.
Interoperability with (other) no-wm tools would be an ultimate win.

An script with xdotool might suffice since it can map/unmap, resize.
cf. the following script for map/unmap based on wm name:

wm_name="$1"
tf="${HOME}/.wm-unmapped-${wm_name}"

[[ ! -e $tf ]] && {
xdotool search $wm_name windowunmap
touch $tf
exit 0
}

xdotool search $wm_name windowmap
xdotool search $wm_name windowraise
xdotool search $wm_name windowsize 100% 100% windowmove 0 0
rm $tf

[Tom Vincent]

I run dwm with the status bar hidden by default. I don't want to be
distracted with system info through xsetroot nor need to see the
window title. Often, I'll forget about open applications in other tags
so sometimes toggle the status bar to find an active tag (NB, is there
an equivalent to xmonad's [runOrRaise][1] action in dwm?). Mostly
though, I hide status bar for maximum screen real estate.

It would seem there might be opportunity here to reduce the dwm
codebase by handing off responsibility of the status bar to something
else, similar to how xmonad does it. dwm could provide an interface
that outputs "desktop" and urgency hints rather than implementing the
status bar itself.

I've searched gmane for previous discussion on this and there may be
an argument that conforming to a ewmh style interface will be
overcomplicating things.

Any thoughts on this?

[1]: http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Actions-WindowGo.html#v:runOrRaise

[Kurt H Maier]

override-redirect window (as docks are not handled properly by dwm).

This phrasing suggests an implicit approval of the way e.g.
ewmh-compliant software handles docks. dwm handles docks perfectly fine
-- it renders them like any other x window. if the dock doesn't like
it, that is the dock's problem, not dwm's.

not supporting ewmh is not a fault, it's a design decision.

[Bjartur Thorlacius]

Post by Tom Vincent
(NB, is there
an equivalent to xmonad's [runOrRaise][1] action in dwm?).

No. Dwm has a rudimentary built-in application launcher (spawn(), IIRC),
but advanced launching is handled externally by dmenu_run, which opens an
override-redirect window (as docks are not handled properly by dwm).

Post by Tom Vincent
It would seem there might be opportunity here to reduce the dwm
codebase by handing off responsibility of the status bar to something
else, similar to how xmonad does it. dwm could provide an interface
that outputs "desktop" and urgency hints rather than implementing the
status bar itself.
I've searched gmane for previous discussion on this and there may be
an argument that conforming to a ewmh style interface will be
overcomplicating things.

Yes, freedesktop has standardized on workspaces (a la MonsterWM) rather
than tags. The number of workspaces dwm would have to present to a
standard pager would grow exponentially with the number of tags, and the
relationship between workspaces (the tags) would be lost, and thereby the
core feature of dwm. Dwm is a window tagger first, window tiler second.

When I think of it, I can't but wonder if we could write a program that
does tagging and tagging only, and a selection of separate layout managers
that automatically tile or maximize mapped windows. Interoperability with
(other) no-wm tools would be an ultimate win.

You could delete the window title stuff from dwm.c and place the status
bar in the slave row only, if you feel the status bar is mostly a waste of
space. If you do, please post the patch here and on the hg wiki repo.

[Anselm R Garbe]

Post by Tom Vincent
It would seem there might be opportunity here to reduce the dwm
codebase by handing off responsibility of the status bar to something
else, similar to how xmonad does it. dwm could provide an interface
that outputs "desktop" and urgency hints rather than implementing the
status bar itself.

I followed this thought experiment a while back in the earlier dwm
days and came to the conclusion that externalizing the status bar
would indeed make dwm simpler/smaller. However the overall complexity
would add up, first one would need to add a "generic" interface to dwm
to play with status windows nicely, second dwm would need expose the
internal tagging state somehow to such external apps, would need
additional input handling to deal with tag selection etc., then the
status bar app itself would become more complex and there would also
be a script that now glues the whole thing together.

If you think about this in terms of the overall line count, I bet you
will end up with a higher SLOC -- just for little gain.

What I do plan though, is adding a config.h hook to make the bar
window smaller (in terms of width) for a better dzen2 or similar
integration.

Cheers,
Anselm

[Sebastian Liem]

Post by Anselm R Garbe
What I do plan though, is adding a config.h hook to make the bar
window smaller (in terms of width) for a better dzen2 or similar
integration.

While I personally doesn't have need for it, how about ability to make
clients "unmanaged"? I.e. visible on all tags but not accessible by any
key command. It shouldn't add much complexity and allow people to run
their favorite statusbar without too much pain. There's probably an old
(non-functional) patch out there.

-- Sebastian Liem

[Anselm R Garbe]

Post by Sebastian Liem

Post by Anselm R Garbe
What I do plan though, is adding a config.h hook to make the bar
window smaller (in terms of width) for a better dzen2 or similar
integration.

While I personally doesn't have need for it, how about ability to make
clients "unmanaged"? I.e. visible on all tags but not accessible by any
key command. It shouldn't add much complexity and allow people to run
their favorite statusbar without too much pain. There's probably an old
(non-functional) patch out there.

It's a bit more complex than that. dwm would still need to ensure that
those windows are not obstructed by bar windows.

Cheers,
Anselm