Re: [STUMP] Paulownia, aka StumpWM 2.0.0

[Michael Raskin]

>
>Michael Raskin <address@hidden> writes:
>
>>>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?
>>
>Hi Michael,
>
>This is a brainstorming thread, so please elaborate an enumerate.  I'm not
>promising it'll end up in the final result.
>
>More than one request has been made to make groups per physical screen.  I 
>quite
>like the way Stump does it now, so I (personally) would want to make it 
>possible
>to achieve what is already there.  For the sake of consistency in our 
>discussion
>lets define some terms :
>- screen: a virtual space within which frames can be drawn
>- head: a physical monitor
>- frame: a boundary within which a window is drawn
>- group: a list of windows to be drawn in frames
>
>To summarize them a bit, a screen can be drawn across multiple heads.  The 
>frame
>is a partition of a screen within which a window can be drawn.  A group is a
>collection of windows that will be drawn across the screen within the frames.  
>
>In terms of reasonable vocabulary, the only word that makes sense is frame, ie
>the boundary of a window.  Groups are what people typically think of as
>workspaces, and I always have to look up how stumpwm treats heads vs screens.
>
>An obvious candidate to lower the barrier for entry (and maintenance) would be
>to rename these things, calling a head a monitor, a group a workspace, and
>either keeping screen or renaming it a canvas.

My setup is as follows:

I have a canvas consisting of one laptop monitor and sometimes I add one
more external monitor to this canvas.

I have 4 main frames in the main monitor, and 1 or 4 frames in the 
external monitor. Each of the 4 or 5 or 8 frames gets a window set 
independently. 

When the external monitor is split, it is split in 4 equal parts.

The main monitor has two very narrow frames at the bottom.

The very bottom is a one-line xterm with a pseudo-modeline (there is 
a complicated shell script, so not a StumpWM modeline). The next frame 
switches between 0 height and one-line urxvt — it displays notifications
like emails from whitelisted senders. The rest of the screen is split
into two full-height frames (the rightmost one has the width of 
a 81-symbol xterm window, the leftmost one is all the remaining space).

I often use the rightmost frame for IM or email. Sometimes for some 
reference materials.

I also often put code in one half and the result in the other half.
It can be LaTeX+PDF or backend code+website in a browser. On a FullHD
monitor marginal utility of an additional small window is almost always
more than marginal utility of extra horizontal space.

Of course, sometimes there are two terminals or something like that.

My frame tagging setup does allow me to create temporary splits inside
one of the frames without losing the division into «right side» and 
«left side» window sets. I mostly use my predefined two big frames,
though.

One more usecase when independent window set switching is very
convenient is driving a (physical) projector/beamer but still having
ability to bring up whatever I need on my laptop monitor.