On Wednesday, October 07 2015, 09:01:50, Michael Raskin wrote: >>4. I think the support for floats should be dropped initially and re-worked >>in a >> different way. If we're going to have floats, I envision being able to >> toggle windows between being tiled and floating on top of the tiles. In a >> sense making the float group sit on top of the tiled group and being able >> to >> move windows between the two as needed. This would ideally be done >> automagically for dialog boxes that often are placed in awkward positions >> when tiled. > > If we discuss changing the grup logic, maybe we will end up > reconsidering the granularity of group choice? > > I.e., is it worth supporting per-monitor groups? Is it worth supporting > multiple «pseudo-monitors» inside a single physical display? What _is_ > a group, what is tied to it (windows has a single group?) and what are > its immutable characteristics (if we have per-monitor groups, what to do > with frame splits, if there are any)? Is a floating group always > entire-workspace? Is a floating group tied to underlying tiling group? > > My setup via frame tagging is most close to 4 no-permanent-splits > «groups» inside a single physical display, and one or four more when > I attach an external display to my notebook. > > Should I describe more details about its usage as a use case or is it > too weird to consider at the current stage?
I think the fact that a single group spans *all* heads and it's not possible to switch between groups on a per-monitor basis is a leading cause of confusion (based on my experience of lurking/helping out in the IRC room,) and would defiantly be a great boon to the software. There are a lot of design questions around interface, and I think the current functionality might be desirable for some users. I think that Michael's tag-based approach to window<->frame association has a bit too much cognitive overhead (at least for me,) and--while this is more general than this specific feature--I think it'll be important to continue to use emacs and screen as a guide for interface and user interaction models, even if we do a lot of clean up and refactoring around the edges. Cheers, sam -- Sam Kleinman (tychoish): - ga...@tychoish.com - tychoish <http://tychoish.com/> "don't get it right, get it written" -- james thurber _______________________________________________ Stumpwm-devel mailing list Stumpwm-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
