On Mon, Dec 27, 2010 at 07:33:00PM +0000, Thomas Adam wrote:
> Hi all,
>
> I've been giving some thought to monitoring the state of windows (winlinks)
> across sessions, since it's something which I personally would find useful.
>
> I started to think of ways of displaying this information as a starting
> point. Let's say you have 6 sessions, each with N windows -- some of them
> might be attached, others not, and it might be the case that an alert
> happened on a window. Currently, the only way you'd know is if the session
> were attached and you were viewing it to either see the message, or the
> change in window title/colour/etc (assuming you'd set that up on the status
> line.)
>
> But that's no good. Neither choose-{session,window} for instance allow you
> to see information for other clients. So I decided to combine the two --
> into what I've currently called "choose-tree" which works exactly the same
> as choose-{window,session} (or rather, it will when I finish it off. :P)
>
> This is what the current set of patches in this series are about -- and I
> stress, it's a proof-of-concept only at the moment. The functionality of
> choose-tree in terms of selecting items, etc., isn't working -- it just
> shows an overview for now.
>
> What I am interested in knowing is how far to take this as a concept. Is
> showing a tree in this way the best way of representing the intent for
> monitoring across sessions? Is there some other way we might want to do it?
I don't have any opinion on how useful it'd be for displaying alerts,
but being able to display all sessions/windows in a tree would be
awesome.
Bonus points if you can hide all windows from a session. Extra points if
the shortcut keys can be nested too (so you press eg 5 7 to go to the
7th window in the 5th session).
> To describe the patches:
>
> PATCH: 1/3 -- "Centralise printable window flag code", currently moves two
> places where there's repeated information for printable window flags ("*"
> for active window, "-" for previous window, etc.) into a common function
> which returns *all* flags on a given window, not just the first one it finds
> in a deterministic order. I've done this because in choose-tree, I'm
> wanting to see *all* flags on a window -- if there's an alert, I'm going to
> want to know if a given window on a session has content *and* silence, for
> instance. I appreciate though this is a change in behaviour, and for things
> like the status-line (where this function is also used), it might get
> annoying. That being the case, perhaps we can maintain a stack of flags,
> where the most recent flag to occur on a window is used in that case? This
> patch in general is divorced enough from the concept of session-monitoring
> that it might be considered a bug-fix? One for Nicholas to determine. ;)
I'm not convinced about showing multiple flags in the status line but I
need to give it a go and see. It'll probably be fine, I hardly ever have
more than one flag on any window.
>
> PATCH: 2/3 -- "Centralise window/session choose-mode code" -- because, in
> choose-tree mode, the list is derived from the amalgamation of what
> choose-window and choose-session spit out, make these commands use the same
> function.
Not sure about the code for this one but the idea is fine.
>
> PATCH 3/3 -- "Introduce cmd-choose-tree" -- the code that makes tmux run the
> command and generate the tree for selection, etc., using functions from
> PATCH 2/3. Currently broken though, as it will only work for selecting
> windows from the currently attached session (i.e., the session from which
> choose-tree was invoked from.) I am not worried at all about this, the
> intent is to show the thing for people to see.
I'd thought of changing the idx argument for the choose callback from an
int to a long which would mean you could pass a pointer. Or it might be
better to make it a union. Anyway, don't feel you need to stick with an
int.
>
> I do have a number of technical questions involving this, if it's to be
> developed further, but I'll let the code speak for itself. I know bits of
> it are a bit rough and ready, so don't lampoon me for it too much just yet.
> :)
>
> I realise I've used git to do this, but it's easier for me than to mess
> about with cvsps to try and get half-decent patches for review. Nicholas,
> you'll have no problem applying these to your CVS tree, they've been
> directly developed on top of CVS HEAD from tmux.sf.net, FYI. However,
> should you just want current versions of all these files, just say. You
> might need to mess about with -p, of course.
>
> Finally, for anyone tracking git at home who wants to play along, see:
>
> https://github.com/ThomasAdam/tmux/tree/ta/session-windows
>
> Or alternatively:
>
> % git clone git://github.com/ThomasAdam/tmux.git tmux.git
> % cd ./tmux.git
> % git checkout -b ta/session-windows origin/ta/session-windows
> % configure && make
>
> Any questions, just shout.
>
> -- Thomas Adam
>
> Thomas Adam (3):
> Centralise printable window flag code.
> Centralise window/session choose-mode code.
> Introduce cmd-choose-tree
>
> cmd-choose-session.c | 28 +---------
> cmd-choose-tree.c | 141
> ++++++++++++++++++++++++++++++++++++++++++++++++++
> cmd-choose-window.c | 45 ++---------------
> cmd.c | 1 +
> status.c | 17 +-----
> tmux.h | 8 +++
> window-choose.c | 107 ++++++++++++++++++++++++++++++++++++++
> window.c | 31 +++++++++++
> 8 files changed, 296 insertions(+), 82 deletions(-)
> create mode 100644 cmd-choose-tree.c
>
> --
> 1.7.2.3
>
> ------------------------------------------------------------------------------
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> to consolidate database storage, standardize their database environment, and,
> should the need arise, upgrade to a full multi-node Oracle RAC database
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> tmux-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/tmux-users
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
tmux-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tmux-users
