Re: [dwm] cycling tags, again...

----- Original Message ----
From: Sander van Dijk <a.h.vandijk_AT_gmail.com>
To: dynamic window manager <dwm_AT_10kloc.org>
Sent: Thursday, 31 August, 2006 10:06:38 AM
Subject: Re: [dwm] cycling tags, again...

On 8/31/06, Jukka Salmi <j+dwm_AT_2006.salmi.ch> wrote:
> What about functions for viewing the previous/next tags for all tags
> currently selected? Example: dwm is configured to have five tags.
> You're viewing tags 2 and 4. After calling viewnext() you'd be viewing
> tags 3 and 5; calling viewprev() would have resulted in tags 1 and 3
> being viewed. The attached patch does what I'm trying to explain.

| I think that's kind of arbitrary; You could just as well select the
| next tag counting from the rightmost or leftmost of the currently
| selected tags. None of these make much more sense than the others.

For those people who haven't read through the large numbers of clients
patch, it includes some functions for one kind of workflow I've got into
with dwm. I might start with opening up all the files for the current
program I'm working with (which all get the same tag). Then I'll select
those I'm going to be likely to be editing/reading immediately and
give them an additional tag and move to a view which has just that
tag. I can do some work with that view, but often I want a subset of
the clients but with larger windows (so I can see more) so I'll temporarily
give them another tag and move to that view (`pushing a temporary tag').
After I've finished that element I'll remove tag from all the views and
drop down a tag (`popping the temporary tag'). Additionally, sometimes
I'll want to extend my initial selection of clients to get a temporary tag,
which involves going to original tag and adding extra tag to one of the
windows.

All this sounds especially abstract because I've not said how I choose
tags. One simple way to do it is to just make the `highest set tag in
current view'+1 the new tag when pushing and `highest set tag in
 current view'-1 the destination when popping. In this approach the
absolute label of a tag isn't important and relative movement
makes sense since you don't have to keep mental track of absolute tags.
(Functions for this stuff in patch for anyone interested.)

I'm not proposing any of this for mainline, just saying that relative
movement makes sense for my workflow.

cheers, dave tweed
Received on Thu Aug 31 2006 - 13:09:37 UTC