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