Re: [dev] dvtm: don't change master or numbering

From: Ross Mohn <>
Date: Sat, 23 May 2015 13:56:29 -0400

On Fri, May 22, 2015 at 06:13:25PM -0400, Greg Reagle wrote:
> On Fri, May 22, 2015, at 05:31 PM, Ross Mohn wrote:
> > I don't think this should be mainline workflow, but it probably makes a
> > nice patch. However, you should understand that window numbering is
> > always the same with the master being window #1 and the rest in
> > consecutive order. The clients are then arranged within those
> > pre-numbered windows, The clients can move around to different window
> > positions, but the window numbers stay the same. When you minimize a
> > window, it takes its client with it and moves to the end of the stack.
> > When you unminimize a window, it pops up to the master (#1), bringing
> > its client along, and pushes the other clients down the stack.
> Thanks for that explanation. In that case my patch is seriously flawed,
> because it screws up the window numbers.
> I've written another patch that does it a bit differently, it creates
> new clients as the second window, so it preserves the master as master
> (as I want), and it doesn't screw up the window numbering. However, it
> still does gratuitous renumbering.
> What I really want is more stability. When I have mutt (or whatever)
> running in my master window, I want it to stay as my master window
> unless I tell dvtm explicitly to change the master window. This means I
> don't want newly created clients to automatically take the master
> window, and I don't want un-minimized clients to automatically take the
> master window.

Getting new windows and un minimized windows to go on the stack instead
of taking over the master window is pretty easy. Having them go to the
end I'll have to think about a little more. Here's an easy solution that
makes them go to the top of the stack instead of to the master.
(Definitely NOT fully tested, and also I don't really endorse this as a
use case!)

Put these two lines in the "commands for use by keybindings"
section in dvtm.c:
    static void createonstack(const char *args[]);
    static void toggleminimizeonstack(const char *args[]);

The put these two functions lower down in dvtm.c:
    static void
    createonstack(const char *args[]) {

    static void
    toggleminimizeonstack(const char *args[]) {
        if (sel->minimized) {
        } else

Finally, replace the 'c' and '.' commands in config.h:
    { { MOD, 'c', }, { createonstack, { NULL } } },
    { { MOD, '.', }, { toggleminimizeonstack, { NULL } } },

> Another stability goal is that I don't want every client shifting its
> windows number by one, unless I explicitly tell dvtm to do so. So if I
> create a new window or un-minimize a window, I'd like it to be placed as
> the last visible window so that no visible clients need to change their
> window number. Of course if I choose to Mod-Enter, I know that
> re-numbering will be required, there's no getting around that.
> Based on what I understand currently of the internals of dvtm (which is
> not a lot and maybe somewhat confused), I would like newly created
> clients and un-minimized clients to go after the last visible window.
> This way the master stays the master and all the visible clients keep
> their window number. Does that make sense?
> So I'm thinking that I need to write an attach function that will attach
> a client after the last visible window and before the first minimized
> window, and call that for newly created and un-minimized clients. Is
> that the solution?

Yes, something like that, although the numbering will probably still not
behave completely in the way in which you want. I'll think about it some
Received on Sat May 23 2015 - 19:56:29 CEST

This archive was generated by hypermail 2.3.0 : Sat May 23 2015 - 20:00:10 CEST