Re: [STUMP] Paulownia, aka StumpWM 2.0.0

[Sam Kleinman]

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): 
 - address@hidden
 - tychoish <http://tychoish.com/>
 "don't get it right, get it written" -- james thurber