What's wrong with Arch?
On Sat, Nov 17, 2012 at 1:11 PM, clamiax <smoppy_AT_gmail.com> wrote:
> 2012/11/17 Anselm R Garbe <garbeam_AT_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.
>
Received on Sat Nov 17 2012 - 20:15:09 CET
This archive was generated by hypermail 2.3.0
: Sat Nov 17 2012 - 20:24:04 CET