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? 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. ;) 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. 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 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 tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users