Re: [dwm] EWMH code would enable some code cuts

On Wed, May 7, 2008 at 8:25 AM, Don Stewart <dons_AT_galois.com> wrote:
> tuncer.ayaz:
>
>
> > On Tue, May 6, 2008 at 5:01 PM, Anselm R. Garbe <arg_AT_suckless.org> 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.

just my .02€
Received on Wed May 07 2008 - 08:33:18 UTC