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
