On Sat, Nov 17, 2012 at 06:20:03PM +0100, Anselm R Garbe 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
>
> (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.
>
> (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?
>
> 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.
>
> 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.
Though, I have not really yet had any contributions to this community,
I'd like to share my perspective.
In recent times I have become quite extreme deconstructionist and
following ideas stem from that. And have some ideas that I consider very
interesting, but due to me being quite lazy, and having slight RSI I
haven't put any work into them yet.
First I do not think window manager should do anything more than that -
manage windows.
First of I hold that its always most flexible to read stdin and write
stdout. That way you can put commands from whatever/wherever you like. I
think this would solve all touch related issues too, just add input
handler that suits your environment(key mapper, gesture mapper, whatever
else) and use it to pass commands to dwm. Needless to say I fully
support removing the bar from dwm, and have proposed it several times,
it would also remove any dependencies on fonts, or maybe even draw.c,
though maybe it will be needed for borders.
In my opinion working environment should be build from such pieces:
window manager, key bindings manager, bar application if needed.
However reading stdin means text parsing, and that is not the most fun
thing I suppose. Maybe it could be done using some lib that allows
simple mapping of "command_name param1 param2 ..." to function(arg1,
arg2, ...)
Well thats all, I remember now.
Received on Sun Nov 18 2012 - 00:36:06 CET
This archive was generated by hypermail 2.3.0
: Sun Nov 18 2012 - 00:36:04 CET