[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [STUMP] Paulownia, aka StumpWM 2.0.0
From: |
Sam Kleinman |
Subject: |
Re: [STUMP] Paulownia, aka StumpWM 2.0.0 |
Date: |
Wed, 07 Oct 2015 10:25:55 -0400 |
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
- [STUMP] Paulownia, aka StumpWM 2.0.0, David Bjergaard, 2015/10/08
- [STUMP] Paulownia, aka StumpWM 2.0.0, Michael Raskin, 2015/10/08
- Re: [STUMP] Paulownia, aka StumpWM 2.0.0, Michael Raskin, 2015/10/08
- Re: [STUMP] Paulownia, aka StumpWM 2.0.0, David Bjergaard, 2015/10/08
- Re: [STUMP] Paulownia, aka StumpWM 2.0.0, Mikael Jansson, 2015/10/08
- Re: [STUMP] Paulownia, aka StumpWM 2.0.0, Michael Raskin, 2015/10/08
- Re: [STUMP] Paulownia, aka StumpWM 2.0.0, Michael Raskin, 2015/10/08
- Re: [STUMP] Paulownia, aka StumpWM 2.0.0,
Sam Kleinman <=
- Re: [STUMP] Paulownia, aka StumpWM 2.0.0, Alberto Otero de la Roza, 2015/10/08