Re: [dev] spacebed - why?
I think the case is this:
dwm has extremely limited stacking which is more efficient (in terms
of user interaction not thin client performance) then i3's tree based
model, which allows substacking quite easily.
If you use a tree based model, adding a spacebed mechanism is trivial,
doesn't require any additional xembed work that spacebed does, and is
just another function of managing windows. I'm not sure that adding a
whole 'nother program in between dwm and st is suckmore.
If spacebing is just a form of window management, why don't we seperate
all tiling modes into separate programs.
I do think that managing windows is part of the window manager, as
multiple st instances are each a window, it seems best to space them
with the window manager.
On 17 February 2014 11:48, FRIGN <dev_AT_frign.de> wrote:
> On Mon, 17 Feb 2014 13:29:06 -0500
> Calvin Morrison <mutantturkey_AT_gmail.com> wrote:
>
>> That is what is clearly not clear. In a group so focused on clarity
>> and logic, I am amazed by the inability to give a concise answer other
>> than "it's not my use case, but i'm sure there is one out there
>> somewhere'
>
> Well, our clarity is expressed by the fact we're not trying to extract
> knowledge from where we clearly can't speak from experience.
> I can't speak for the people using spacebed, but I know the
> Unix-philosophy well enough to value a separate spacebing-program over
> reimplementing this feature in dwm.
>
> Thus this is in fact a pretty clear case, given spacebed is less than
> sufficient for this task.
> However: If you tell me a case where an integrated solution in dwm is
> superior to spacebed, I'm open for this debate.
>
> Cheers
>
> FRIGN
>
> --
> FRIGN <dev_AT_frign.de>
>
Received on Mon Feb 17 2014 - 20:26:47 CET
This archive was generated by hypermail 2.3.0
: Mon Feb 17 2014 - 20:36:06 CET