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] [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
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.
Re: [dev] [dwm] Optional status bar
On Sat, Jan 28, 2012 at 02:40:07PM -0800, Suraj N. Kurapati wrote: > > DBus is overkill. A named pipe or UNIX domain socket would suffice. I seem to recall someone exporting client and tag information via xprop.
Re: [dev] [dwm] Optional status bar
On 28 January 2012 13:51, Tom Vincent wrote: > 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
Re: [dev] [dwm] Optional status bar
On Wed, 8 Feb 2012 20:01:58 +0100, Anselm R Garbe wrote: > 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
Re: [dev] [dwm] Optional status bar
On 8 February 2012 21:26, Sebastian Liem wrote: > On Wed, 8 Feb 2012 20:01:58 +0100, Anselm R Garbe wrote: >> 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
