Re: [dwm] clientspertag status message

From: pancake <pancake_AT_youterm.com>
Date: Wed, 31 Oct 2007 15:54:39 +0100

On Sat, Oct 27, 2007 at 08:13:36PM -0400, Ritesh Kumar wrote:
> Hi pancake,
> Thanks for reviewing the patch. :)

np :)

> I understand your concern about not having to change dwm.c. I had
> initially thought about a way to do it using the conventional stdin
> statusbar. But, is seemed a little roundabout to take a string in the same
> process out of it and then bring it back in using stdin... but I guess
> that's just my feeling. There are also some other problems using a fifo.
> - the fifo needs to be unique for every concurrently running dwm session. I
> however have only one screen... so not exactly my problem :)
> - writing to a fifo would block dwm in the printf. Worst yet, a little
> mis-scriping at the statusbar end can cause a hung dwm.
> - it will be hard for multiple extensions/patches to send data to the same
> fifo. I guess some bash scripting and grepping at the stdin-statusbar end
> could to away this problem at the cost of a slight inconvenience.
> That's why I wanted to solicit some feedback regarding a status text
> configuration thing in dwm.c/config.h which could be used by other
> extensions.

Yes, the problem of a printf, is that it needs a fflush() and if we're working
with a fifo there'r some issues that are heavy to handle, so it can be more
a problem than a solution :)

> I really like your idea about tagging the rest of the windows (after a
> clientspertag operation) a separate tag. It goes well with dwm's tagging
> paradigm too. Since the presence of a window with a tag is shown by dwm in
> the left statusbar, it gets rid of my whether-or-not-cpt-is-active dilemma
> too. However, activating cpt when seeing one tag and deactivating it when
> seeing another can cause all the windows in the 'rest of clients' tag to be
> tagged with the new tag. Also, if we are currently viewing a set of tags
> then it is not easy to say what tags to assign to the 'rest of clients' when
> deactivating cpt. Life doesn't seem to be all rosy with the tagging paradigm
> here ;).

Well. its not my idea..it is the dwm main concept, but the problem I found
with it is that it's not much handy for things like 'cpt'. So you have to
remember in which tag did you drop the clients and toggle them.

Maybe we need a key to repeatively toggle the last Ctrl+Meta+Tag like we
now have a toggle key to change between two tags.

But this doesn't fits at all on the cpt concept, because we loss the freedom
to choose how many clients we want to see, and usually the N top clents
of the list are the most interactively used (the tail is usually used as
"view only" or as "pool" for non-currently-used apps.

> About the enhanced monocle layout replacement, I can actually do the
> following without problems:
> (Lets say I have two windows on a tag).
> Activate cpt=1. [Now the window in the master tag is full screen, The
> number of hidden windows is shown in the status bar].
> Ctrl - j shifts focus to the hidden window. Visually, the red border
> from the full screen is removed.
> Ctrl - <enter> zooms on the newly focussed window.

yup, thats what I usually do, but it's not much clean because you don't see
the client. only the titlebar, and for terminals this is not much ok.

> This still doesn't completely achieve the 'scolling through all windows'
> effect. Probably the easiest alternative (as you suggested) is to zoom() on
> the focussed client automatically on focusnext() if cpt = 1... and that
> would be a cool improvement to clientspertag. One way is to have a
> cptfocusnext doing the cpt related chores and calling the actual focusnext
> appropriately. config.h handles binding Ctrl - j to cptfocusnext so that's
> not a problem either. This solves the problem for clientspertag but ofcourse
> is not general enough for a number of hooks (How about a config.c? That
> could actually handle a lot of other problems too.).

Uhm the zooming way is not ok at all because it modifies the clients list
and breaks the focusnext()/focusprev(), so imho the right way to achieve
this is by having an index and a counter. Something like a moving window
with

Here's a sample:

                     Window (size = cpt)
 =-Index-=> +----------------------------------+
            | |
 [ client0 ] [ client1 ] [ client2 ] [ client3 ]

So, we should be able to change the starting index into the clients list
to start handling clients and keeping cpt as the size of our view for
the current tag.

So, we can hook ^alt+j and ^alt+k to move this index with soemthing like
cptidx++ or so.

We can make cptidx=0 when entering in 'cpt' mode. And always make't fit
for all the clients on the current view.

This way. dwm.c will remain as is, and we can 'handle' when focusing a
non-visible client (out of the window) and shifting right or left the
window.

I think this way we can make cpt more consistent and functional, but
we also need the visible-clients indicator.

Thanks for discussing the cpt stuff. I need some feedback to think on
some concepts and so..let see if we finally got the proper approach
for this patch.

--pancake
Received on Wed Oct 31 2007 - 14:12:58 UTC

This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 15:03:47 UTC