Re: [STUMP] The future of StumpWM

Your point about fonts/toolkit/helper apps is good.

I will point out that some other projects (notably XMonad via contrib) do
have XFT support. XMonad has a contrib module that depends on the X11-xft
library. However, this seems like it'd be a strict dependency on X11 that
would have to at least be disabled for Wayland.

Using helper apps seems a reasonable take on it. xmobar and i3bar are
already excellent status bars / mode lines. They can be communicated with
in any language, so it doesn't seem like there would be a tremendous need
for that functionality to be baked into stump.

 - J David Smith

On Sat, Sep 5, 2015 at 6:39 PM, Robert Taylor <[email protected]>
wrote:

> 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.
>
> _______________________________________________
> Stumpwm-devel mailing list
> [email protected]
> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
>

_______________________________________________
Stumpwm-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel