Re: [dwm] dwm's future

Try to make the new dependencies optionals.

About the broken non-free apps, is not dwm's problem and one solution
can be to use a qemu instance with another WM and connect to the host
Xwindows server.

On Tue, Apr 28, 2009 at 10:01 AM, Anselm R Garbe <garbeam_AT_gmail.com> wrote:
> Ok, thanks again for continuing the discussion.
>
> My conclusion is as follows:
>
> 1) dwm will be slightly redesigned, code-wise. I consider having a
> less suckish font and drawing abstraction in order to be implemented
> in different ways (which will also be used by st and dmenu).
> Officially there will only be X font support as is. But due to this
> abstraction it'll be possible to implement cairo/pango backends if
> that seems more suitable for non western glyphs without the need to
> change any vanilla dwm code.
>
> 2) Similiarly I will separate the bar bits into a separate file to
> make it easy to get rid of the bar if someone prefers going with
> dzen+xdotool.
>
> 3) Regarding the broken apps I need to investigate further. If it's
> really related to reparenting, it's definately a bug in these apps or
> in the toolkit (JDK?) they rely on. If that's the case I WON'T
> introduce kludges to handle them, instead we should file bug reports
> that these apps get fixed.
>
> Particularly if these apps are of commercial nature, it should be the
> vendor's interest to fix their apps that you as a customer can use
> them in your preferred environment. You or your organization pays
> someone license fees I guess so that's just a totally valid request
> that the vendor fixes these apps.
>
> 4) Regarding multihead I will start a separate thread soon what a
> viable solution might be.
>
> Kind regards,
> Anselm
>
>
Received on Tue Apr 28 2009 - 08:53:57 UTC