Sending everything over a pipe from client to server and vice versa is slow, it
would have to use shared memory.

Although in reality there is no reason the client has to be involved for any
implementation, the server has a copy of the tty fd so it can do whatever it
likes.

You could use another session a store for inactive windows. If code was added
to specify "highest window index" as a target (trivial), using a session as a
stack could be done quite easily.

There is no reason hidden panes couldn't be supported natively to allow a "one
pane" layout but at the moment it violates assumptions in the layout code which
would have to be changed.


On Fri, Feb 26, 2010 at 12:03:56PM -0700, Aaron Denney wrote:
> On Fri, Feb 26, 2010 at 10:34:33PM +1100, Trent W. Buck wrote:
> > Now, I come to tmux, which has windows *and* panes.  It looked like I
> > can get something very like xmonad by simply using only one window, and
> > always creating frames, e.g. using ^B" instead of ^Bc.  I can then use
> > :next-layout to switch layout heuristic.
> > 
> > But: confusion!  There is no "just one app" layout in tmux!  My first
> > guess is that there must be some way to move apps out of the current
> > window (without killing them), such that "just one app" is simply to
> > move all but the current app into a second "unmapped apps" window.  But
> > I can't find such a command.
> > 
> > Have I simply misunderstood the "right" way to use panes and windows in
> > tmux?
> 
> Right.  The panes are not merely something that the client uses to keep
> track of what set of ttys should be associated with a window.  They
> are instead a reification of the actual layout, kept in the server.
> The layout managers do not just choose what to display, but change the
> parameters, and let the layout happen.  This means that to not display a
> tty, you need to remove the corresponding pane from the window, either
> closing it, or moving it elsewhere.  There is no per-window "inactive
> list" they can be kept on.
> 
> I do not like the current behaviour very much.  What you are hoping for
> is also not my preferred model, but would be interesting, though requiring
> substantial coding.
> 
> I have advocated before that panes be an entirely client-side structure,
> rather than the current server-side, and that the server just keep track
> of n ttys, and let clients display, and position them as they wish.
> This too would involve substantial code modifications, but make it a bit
> easier to code up and explore new UI modes.
> 
> Code, of course, speaks louder than words, and I won't have any time soon
> to work on such a refactoring.
> 
> -- 
> Aaron Denney
> -><-
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> tmux-users mailing list
> tmux-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tmux-users

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users

Reply via email to