Re: [STUMP] Paulownia, aka StumpWM 2.0.0

Sam Kleinman <[email protected]>
Newsgroups gmane.comp.window-managers.stumpwm.devel
Message-ID <[email protected]>
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): 
 - [email protected]
 - tychoish <http://tychoish.com/>
 "don't get it right, get it written" -- james thurber

_______________________________________________
Stumpwm-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.