What's wrong with Arch? On Sat, Nov 17, 2012 at 1:11 PM, clamiax <smo...@gmail.com> wrote:
> 2012/11/17 Anselm R Garbe <garb...@gmail.com> > >> Hi there, >> > Hi. > > >> I'm back in the game ;) >> > Welcome back! > > >> (i) First I plan a new dwm release with the introduction of draw{.h,c} >> or libdraw. The idea is to abstract all the PCF/Xft cruft away from >> the dwm implementation and to define a clean draw.h interface to be >> used instead. This should also be incorporated into dmenu and st. > > This sound like a logical step we had to do first or later. At least, > until we have something to draw. > > >> a) requiring an additional library dependency at build time (I'm not >> the biggest proponent for this idea) >> > If we aspire the perfection this shouldn't even be considered. > > >> b) using cloned draw.{h,c}'s in st/dmenu/dwm, whereas the dwm >> implementation is the master > > Maybe. Does this also mean that we could end up to have some piece of code > used in some program but unused in other, for the sake of sharing the same > implementation? > > >> (ii) Another aspect on the dwm roadmap is a reimplementation of the >> current multi-screen handling. It still contains some weird bugs in >> special setups with same screen sizes. Those don't seem to be easily >> fixable with the current updategeom() handling. >> > I don't need multi-screen handling at all. No, I'm not proposing to remove > it. It would be too nice... > > >> (iii) A third idea is an old idea that 20h brought into the discussion >> when investigating 2wm. The man page of 2wm mentions sbar, which was >> abandoned a couple of years ago. My question here is: > > >> -> is there anyone who uses the mouse functionality of the dwm bar >> right now? Could you live without it? >> > No. Yes. > > >> I barely use the mouse for the dwm bar and would be in favour for >> removing the bar altogether from dwm. Instead I would output the >> current dwm state to stdout which could be used by a different program >> like sbar for input. But I wouldn't add an interface to dwm to change >> the tags through X props or some other command interface (like stdin >> processing) to allow other programs to amend the dwm tags. Good old >> key commands would be enough for me. >> > Agreed. Though someone doesn't. I hate when people which don't think like > me comes with good arguments. I can safely ignore them, though. So, +1 to > remove the bar from dwm. > > >> I know that some of you are inclined to use dwm on tablets. But I'm >> not convinced that tablets or touch interfaces in general are a nice >> fit with the terminal world we live in. >> > I'm pretty sure that even those who use dwm on tablets are doing it by > thinking that it is not a good idea. > > >> dmenu needs some fixes. The removal of config.h is the wrong way it >> took. If someone stays with hg of dmenu or uses the releases, he has >> to do conflict management now with dmenu.c changes. >> > I don't use dmenu. No, I'm not proposing to abandon the project. It's so > geek. > > >> To me archlinux was a good distro until a couple of years ago. >> > To me, you are wrong. Archlinux has never been a good distro. > > Nowadays it seems to be very en vogue and thus has degraded quite >> significantly in terms of simplicity. I'm not aware of any distro that >> would come close to the radical goals of stali, thus this is the real >> effort suckless.org must work on. I believe that the Android core as >> a base system is the best platform to base sta.li on. >> > I agree to use Android core as base system but only if we schedule to > slowly remove it from sta.li, one piece at a time, until will not remaing > nothing at all. >