stumpwm-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [STUMP] Flipping heads in group to groups in head!


From: Michael Raskin
Subject: Re: [STUMP] Flipping heads in group to groups in head!
Date: Tue, 24 May 2011 18:01:20 +0400

<address@hidden>
<address@hidden>
<address@hidden>)
Mime-Version: 1.0
Content-type: text/plain; charset="UTF-8"

>>>>>>> What would be needed to get this support into StumpWM ?
>>>>>>> As far as I understand it its not possible to get it done in stumpwm.
>>>>>>
>>>>>> It would require changes more or less everywhere.
>>>>>>
>>>>>> I sent out the idea to get feedback on whether the design is sound or 
>>>>>> not.
>>>>>
>>>>> It would probably mean breaking a lot of code and stumpwmrcs
>>>>> everywhere, but I really support this motion. Having independent heads
>>>>> would be a killer feature for me.
>>>>
>>>> The problem is that _both_ heads-in-groups and groups-in-heads can be very
>>>> useful. So we either have to provide both and share code, or develop some
>>>> new concepts which allow simple expression of both cases.
>>>>
>>>heads-in-groups is a superset of groups-in-heads.
>>>
>>>I described in my original post how to emulate the latter behaviour by
>>>gluing heads together to make the group switching happen for all heads
>>>at the same time.
>>
>> And we need to rethink bindings for group operations, because when my wish
>> "I want to see group my email client", I would obviously prefer to be able
>> to summon the relevant group in some consistent way, even if my focus is on
>> another head.
>>
>Currently a group spans multiple heads.  Frames are contained within groups.
>
>With the new changes it would be that you have a group per head and
>frames within the group.

I understand that part.

>I would think that the group bindings that exist would still work the
>same regardless of which
>head you're on.

That depends. It is an interesting question whether groups _should_ 
be able to migrate between heads; if yes, we will have unified group
numbers for all groups for all heads (that may be a problem for 
people liking to have lots and lots of groups); if no, there is 
a questiona whether we want bindings to switch to group #n on current
head or whether we want a binding to switch to group #n globally 
on the head where it belongs. Both cases have advantages and drawbacks.

>p.s:  I use the mode-line that is that there and I've got seconds in
>the clock.

I head minor performance problems with less-than-second update times 
back in the time, and now I have a complicated enough status bar script 
not to want to migrate to builtin modeline. 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]