Re: [STUMP] The future of StumpWM

[Robert Taylor]

I agree with all of your goals (the ace-window / hydra stuff is really
exciting).  My only concern would be the toolkit and the work to
support Wayland.

Some thoughts:

* ESPECIALLY agreed on your vi comments.  Hillarious!

* Agreed on all of the Wayland comments in thread.   Hasn't it been
around for about 5 years (3 years since initial release) if not
longer?  It should take another 5 years before we really start to see
serious use of Wayland.

On the other hand, maybe that is just the right amount of time for us!

* You have summarized the vision for the 2.0 of StumpWM very well.

* My only concern would be with the use of a toolkit.  I am not sure
that getting font rendering to be a bit nicer outweighs the
co-depenency of a toolkit.  From what I can see, the only real option
is QT and that just seems gratuitous.

The only option that seems aesthetically pleasing is Mcclim, but, that
is not being maintained so that is not an option.

Does a window manager need a toolkit anyway?  I am not so sure.  They
way I visualized Stump development was basically what you described
except the Stump panel deal, Stump console and Stump help would be
ripped out and would instead become modules / standalone apps.
Stumpwm would be aware of them and know what to do if the apps were
started (help of course is just a single page app but could be expaned
upon, a panel app would be accommodated appropriately along the edges,
etc.).  Those that want those features would never have them taken
away, those that don't use them don't really need to even load them
(not that it is even an issue, just saying).

In addition, I was thinking about a generalized standalone helper app
that would draw an overlay over the monitors and let you draw / slice
the windows with your mouse.  The slices / deletes would simply be the
helper app sending Stump the commands that you could do manually
anyway.

The helper app would behave like the current ? menu, it would always
be hidden unless called for.  The helper app could be expanded to
include panel like funcionality (time, date, widgets for system
status, notifications, etc).  That way, the inevitable QT vs GTK vs
whatever debate can be modularized away from the window manager.  We
can keep on using the Window manager even if we don't like the choice
of toolkit.

In other words, I was visualising slimming Stumpwm down to JUST a
window manager as much as possible and push everything else out into
modules and standalone apps and leave the default rendering as it is
now.

I think that Stumpwm has managed to really grab the essence of what a
tiling wm should be, I think it should retain that essence.

* Lastly, your floating tiling thoughts are correct too.  There are
times where a floating window is useful and having a reasonably good
version of that in Stump would really help a lot of users.


David, my thanks for all of the work that you have done and the time
you have put into thinking about where to go next with the project.
Most of the time I REALLY hate where people take ideas (witness Gnome
and KDE), this time sanity prevails.

Above is a bit rambling, let me know if I am wrong on any assumption
or if I need to clarify part of my post.