Greetings.
On Sat, 17 Nov 2012 18:58:22 +0100 Anselm R Garbe <garbeam_AT_gmail.com> wrote:
> dwm
> ---
> (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.
> For this there are two options:
>
> a) requiring an additional library dependency at build time (I'm not
> the biggest proponent for this idea)
> b) using cloned draw.{h,c}'s in st/dmenu/dwm, whereas the dwm
> implementation is the master
I’m all for draw.{h,c}. Otherwise the complexity of dependency handling
will need to be added to all of the packages using libdraw. There might
be a tendency of differences in the implementation, but that’s easy to
solve, if the draw.{h,c} stays simple. That’s simpler than having the
hassle to download some more packages, install them at the right place
and go on with building.
Even when sta.li is releases should this be the right approach. With all
source included builds on cygwin or whatever will be next in the future
will be more easier than depending on some package manager.
> (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.
But please keep the same behaviour as dwm has now. Reducing this to this
idea of only starting applications on one screen is not userfriendly and
creates more hassle than the »weird bugs« create. Most of these bugs are
just there because of weird applications using weird modes in weird cas‐
es of weird bloated complexity. I’m rather for adapting the applications
having the problems.
> (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, I am the leader of the suckless touch project and removing this will
require me to fork dwm, which only creates problems. The statusbar works
as it is and we already discussed what bloat some interface for a sta‐
tusbar would add.
Some good nice touch features will be added here, when multitouch is
common and usable in X11. Then the statusbar can serve as the path to
suckless touching.
> 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.
This is replacing a worker with a disabled person.
> 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.
It does, but you are proposing the Android core(wtf?) below.
> sta.li
> ------
> To me archlinux was a good distro until a couple of years ago.
> 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.
What’s »Android« in the »Android core«? The Linux kernel running some
kind of scripts and sometimes hardcoded scripts for specific mobile
phones. Android is now only usable with the dalvik complexity layer for
end user annoyance. No, this can be done more easier, by following the
path of most musl‐based static distributions around. A more complex
problem will be to find a sane compiler that isn’t using C++.
Sincerely,
Christoph Lohmann
Received on Sat Nov 17 2012 - 18:58:22 CET
This archive was generated by hypermail 2.3.0
: Sat Nov 17 2012 - 19:12:09 CET