On Wed, May 7, 2008 at 8:55 AM, Don Stewart <[EMAIL PROTECTED]> wrote: > tuncer.ayaz: > > > > On Wed, May 7, 2008 at 8:25 AM, Don Stewart <[EMAIL PROTECTED]> wrote: > > > tuncer.ayaz: > > > > > > > > > > On Tue, May 6, 2008 at 5:01 PM, Anselm R. Garbe <[EMAIL PROTECTED]> > wrote: > > > > > On Tue, May 06, 2008 at 12:14:10AM +0200, Henrik Holst wrote: > > > > > > I think an implementation of EWMH would make it possible to > remove the > > > > > > dwm panel (the one that reads stdin and displays it) from dwm > code base. > > > > > > > > > > > > In that way dwm would be smaller (or maybe just break even) and > more > > > > > > symmetric with how dmenu is fitted to the equation today. It > would also > > > > > > allowe the user to choose whatever kind of "panel" he or she > wants. That > > > > > > is an escape and dpanel (or some other name maybe) would not > have to be > > > > > > counted in the ridicules 2 kloc limit. :P > > > > > > > > > > > > But seriously, EWMH support with struts and all, should be on > the top of > > > > > > the list for dwm. EWMH is too important to be left to forks. > > > > > > > > > > > > Something for 5.0? > > > > > > > > > > EWMH is evil. I see reasons for people arguing to get rid of the > > > > > status text processing code in dwm, but the tagging approach is > > > > > a too integral part of dwm which heavily depends on the bar. > > > > > > > > > > Thus there is no way to get rid of the bar. The overhead > > > > > introduced by EWMH and a EWMH-driven bar for the tagging concept > > > > > would make the code base much more complex. > > > > > > > > > > Currently I'm at a stage to reconsider features for removal > > > > > again. Esp. DEFGEOM seems to have a lot of potential for > > > > > simplification(s). > > > > > > > > +1 on status text processing removal (it just eats cycles > > > > and makes life harder while trying to concentrate on > > > > real work) > > > > > > > > +1 on keeping a possibility to have the tags part of the bar > > > > for people who need it > > > > > > > > +1 on keeping a way to add a status bar somehow without having > > > > it in dwm but I'm not sure how that would be combined with the > > > > tags support. > > > > > > > > As there are presumably Xmonad devs/users lurking here > > > > I'm curious how the tags part in > > > > http://haskell.org/sitewiki/images/b/b2/Byorgey-config.png > > > > is accomplished. is it dzen or xmobar which has a way to > > > > talk to Xmonad? > > > > > > That's just dzen by the looks of it (with a xinerama hook to print which > > > workspaces are currently on screen, into dzen). > > > > so it's Xmonad > dzen where dzen expects a string/bytestream to parse in a > > defined format/structure? if so it would make sense to try to standardize > > a subset of the format for both dwm and Xmonad just in case dwm goes > > down that path. > > Yep, its just dzen's input format. text and pixmaps. > > You can run this stuff from the command line, so no need for further > standardisation (well, maybe more docs from Rob about dzen).
well, if dwm would use a different output format we could still transform it. I mean it wouldn't matter anyway when you're burning cycles with status/tag drawing/updating :P
