stumpwm-devel
[Top][All Lists]
Advanced

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

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


From: Mehul Sanghvi
Subject: [STUMP] Fwd: Flipping heads in group to groups in head!
Date: Tue, 24 May 2011 09:14:58 -0400

did a reply instead of reply-all

---------- Forwarded message ----------
From: Mehul Sanghvi <address@hidden>
Date: Tue, May 24, 2011 at 09:13
Subject: Re: [STUMP] Flipping heads in group to groups in head!
To: address@hidden


On Tue, May 24, 2011 at 07:35, Michael Raskin <address@hidden> wrote:
> <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.
>
> In that case I guess we change quite a lot of things at once (not only in 
> code,
> but also conceptually), so the question is what do we want to get if we change
> everything anyway.
>
> Maybe I should not care because I have reached the state where I almost
> avoid group switches. I have even managed to overcome dirty hack with doing
> a pseudo-modeline out of XTerm by use of frame tagging (using XTerm is not
> a dirty hack per se because I have some status watching sripts for longer than
> I use StumpWM and I want seconds in my clock). In some sense, I
> have virtual heads inside heads and groups of windows are inside them. (I will
> probably post something on this tag-based solution to the list later, I want
> to play with it to be sure it works as I intended - if anyone wants to look at
> complete beta, I can send this now)
>


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 would think that the group bindings that exist would still work the
same regardless of which
head you're on.

Or am I missing some use case that I am not aware of ?


cheers,

      mehul

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



-- 
Mehul N. Sanghvi
email: address@hidden



reply via email to

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