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
