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 <linuxhooli...@gmail.com> 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 > Stumpwm-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/stumpwm-devel >
_______________________________________________ Stumpwm-devel mailing list Stumpwm-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
