[dev] [dwm] Optional status bar
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
Re: [dev] [dwm] Optional status bar
On Sat, 28 Jan 2012 12:51:46 -, Tom Vincent wrote: (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). 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. -- -,Bjartur
Re: [dev] [dwm] Optional status bar
On 2012-01-28 14:22, Bjartur Thorlacius wrote:
> 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
Re: [dev] [dwm] Optional status bar
On Sat, Jan 28, 2012 at 02:22:09PM -, Bjartur Thorlacius wrote: > 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.
Re: [dev] [st] new xft branch (FreeType font rendering)
Interestingly enough, if you launch the affected ncurses programs inside tmux, everything seems to work fine (which is why I hadn't noticed the bug until my last post - I wasn't using tmux at work.)
Re: [dev] [st] new xft branch (FreeType font rendering)
On Sat, Jan 28, 2012 at 10:30 AM, Bryan Bennett wrote: > Interestingly enough, if you launch the affected ncurses programs inside > tmux, everything seems to work fine (which is why I hadn't noticed the bug > until my last post - I wasn't using tmux at work.) s/in/outside/ -- but I've verified: alsamixer launched in st (outside tmux) looks fine; but launched in st inside tmux it looks hideous. Best, Peter -- sic dicit magister P University of Toronto / Fordham University Collins Hall B06; Office Hours TF10-12 http://individual.utoronto.ca/peterjh gpg 1024D/ED6EF59B (7D1A 522F D08E 30F6 FA42 B269 B860 352B ED6E F59B) gpg --keyserver pgp.mit.edu --recv-keys ED6EF59B
Re: [dev] [st] new xft branch (FreeType font rendering)
That's strange. I'm using tmux here and every ncurses program I'm using looks great INSIDE tmux - but outside looks like shit. [1] 1: http://ompldr.org/vY2kyag (sorry for the hugeness)
Re: [dev] [dwm] Optional status bar
On Sat, 28 Jan 2012 15:28:24 -, Kurt H Maier wrote: 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. -- -,Bjartur
Fwd: [dev] [st] new xft branch (FreeType font rendering)
Begin forwarded message: > From: Peter Hartman > Date: January 28, 2012 11:03:39 AM EST > To: Steven Blatchford > Subject: Re: [dev] [st] new xft branch (FreeType font rendering) > > > > > > On Jan 28, 2012, at 10:51 AM, Steven Blatchford wrote: > >> On 10:44 Sat 28 Jan, Bryan Bennett wrote: >>> That's strange. I'm using tmux here and every ncurses program I'm using >>> looks great INSIDE tmux - but outside looks like shit. [1] >>> >>> >>> 1: http://ompldr.org/vY2kyag (sorry for the hugeness) >> >> Out of curiosity, what do you guys have TERM set to inside and outside >> of tmux? > > Inside, screen > Outside, st-256color > > Peter
Re: [dev] [dwm] Optional status bar
On Sat, Jan 28, 2012 at 04:01:09PM -, Bjartur Thorlacius wrote: > 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 . It, to coin a phrase, Just Works.
Re: [dev] [dwm] Optional status bar
On Sat, 28 Jan 2012 16:35:49 -, Kurt H Maier wrote: On Sat, Jan 28, 2012 at 04:01:09PM -, Bjartur Thorlacius wrote: 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. -- -,Bjartur
Re: [dev] [dwm] Optional status bar
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?
Re: [dev] [dwm] Optional status bar
Þann lau 28.jan 2012 19:13, skrifaði 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.
Re: [dev] [dwm] Optional status bar
Þann lau 28.jan 2012 19:13, skrifaði Tom Vincent: It seems we can conclude targeting ewmh/icccm is out of the question. For tag switching at least.
Re: [dev] [dwm] Optional status bar
On Sat 28 Jan 2012 09:03:26 PM PST, Bjartur Thorlacius wrote: > Þann lau 28.jan 2012 19:13, skrifaði Tom Vincent: > > 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. -- Long computations which yield zero are probably all for naught.
Re: [dev] [dwm] Optional status bar
Þann lau 28.jan 2012 22:40, skrifaði 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.
