Re: [dwm] dwm's future

I want to feed the mailing with some more words about this topic...

I don't really care about the font rendering, because I just use title bar
to see what's going on the window (like for large builds or browser's
page titles, ..) And I dont really read contents in chineese or russian,
so i'm happy with ascii. But I understant that there's people wanting
to use truetype fonts for fixing those issues.

If we just implement this stuff into separated .c or .h files, so everybody
can still use the basic x11 stuff, or just use cairo/pango or..maybe someone
would like to use it on w32 or osx, so, these guys will just have to
implement
this little backend, and keep all the dwm internals clean and portable for
all the systems and backends (also for ncurses?). The problem here is
that actually all the keybinding stuff depends on X, and there are other
stuff that is pretty linked to X11, and if we want to drop this hard X11
binding we should try to split it up into a set of callbacks.

I really like to click on the statusbar, so the code that it is
currently there
is more thatn enought to me.

As somebody told in another other mail maybe we should focus on the
Xinerama "problem", which is probably an endless issue, or maybe we
should rewrite X into a new protocol and set of libs in a more minimalistic
way and if someone wants to run an Xbased app just use Xnest/Xephyr or
just provide a way to run Xbased windows inside the new 'graphical server'.

THis last point is probably the way to go, but obviously is a long time
project
but i just wanted to throw few ideas more.

About the buggy apps, well.. i really dont have any problem with any
application,
and maybe this is because i mostly use few graphical applications, and
all the
ones I use are free software which gives me the possibility to fix any
issue or
report it. (blame on privative solutions) (mathematica, ...)

For me the solution for using those broken apps is just to run a fullscreen
nested X server in a tag and run the application inside with no window
manager
or with another one.

I want to keep dwm simple, i think that all the dependencies should be
optional
and minimal, so we should probably think on the basic primitives to work on
X and wrap them as function pointers in a single structure, and allowing
compile-
time-plugins to overwrite those pointers with cairo, w32 api or so.

And please, keep the statusbar and the clickable stuff functional or at
least
optional for those who dont want to use it, but maybe we can think in a more
extensible design for it, but exporting/importing window manager stuff
between
processes is something stupid if you just need few things and they can be
managed from inside the window manager, for me having this feature inside
keeps the things easier.

--pancake

Anselm R Garbe wrote:
> Thanks for all the valueable input so far in this thread.
>
> I think here are the action points:
>
> 1) I plan to separate the bar stuff code-wise into two portions -- the
> tag bar with tags and layout info, and the title/status bar, but
> things will stay as they are from a user perspective, it's just some
> code cleanup which allows replacing the tagbar and/or title/status bar
> with something else (or avoiding to compile it in)
>
> There might be possible pango/cairo implementations of this stuff, I
> plan to have a font API interface, something like libsfont which is
> used by dwm and dmenu to start with, and which depends on either Xlib
> or some more fancy sucking stuff optionally.
>
> 2) I need to investigate into the reparent stuff first, I really
> dislike going the reparent route, because each parent window consumes
> much more X resource memory (basically twice the buffer sizes as we
> have already if you use a reparenting WM -- this makes everything
> slower). I really think bug the authors of the broken apps to fix
> their apps that they do not assume a reparenting WM.
>
> So the action here is: let's make a list of all apps which are known
> to be broken and behaving strange with dwm first, that I can
> investigate.
>
> - Mathematica (Version?)
> - ... please provide input
>
> 3) I agree multihead has got some preference, I like the approach to
> assign certain tags to specific screens.
>
> Kind regards,
> Anselm
>
>
Received on Mon Apr 27 2009 - 14:07:55 UTC