Observations / features

Just stumbled upon this WM while doing some bspwm related searches… looks very interesting. One thing that has always bothered me about bspwm is the lack of layouts; I use bsp-layout as an external “helper”… works OK most of the time, but automatic layouts really should be part of the window placement process, not a re-organization of windows post placement.

I haven’t had a lot of time to play around with DK, but did notice a couple of strange things:

  1. I use a multi-head setup, monitors at relative pos left, middle, right and a fourth above the left monitor. When switching a window from tiled to floating on the left monitor, it is placed (ie. X,Y) so that it is equally split between the left monitor and the one above it. I would have expected the window to stay on the left monitor exclusively (where it was originally tiled).

  2. tstack layout… I know this is just an example layout in config.h, but doesn’t seem to work correctly. The “last” window in the stack area is always squashed horizontally, ie. very narrow. “Last” could be the only window in the stack if nstack=1, the second (rightmost) window for nstack=2, etc.

Any plans for one-shot rules like bspwm implements? I don’t use them very much, but they have come in handy once in a while for a few scripts.

Plans for a hidden flag on windows? I currently implement what some might call a scratchpad using the hidden flag and rofi in bspwm. I find it far more useful than a scratchpad implementation like i3, which honestly is half-baked. i3 doesn’t provide a way to remove a window from the scratchpad… yes, they advise to toggle the floating status of the window to remove it from scratchpad, but then it becomes tiled and you have to re-toggle to float it again. That’s just stupid. go i3…

I didn’t see any kind of “mouse follows focus” setting in the manpage… I assume the builtin behavior is sane, but would be nice to manage this via dkcmd. I usually have this set to false in bspwmrc and wrap any keybound commands in sxhkd that I want to implement it (true), run the command, and then set back to false. Basically mouse only follows focus for certain explicitly run actions (cycling through windows on current desktop, monitor focus changes, etc.). For me, this makes things more predictable instead of having applications warping the mouse around…

Another thing I might have missed in the manpage - is there a command to create new desktops? Something similar to bspwm’s “bspc monitor -a ABC”. I tend to manage desktops exclusively by name, using rofi or other shortcuts (not numbers) to switch, and entirely dynamic, able to create desktops on the fly manually or even optionally auto-name/create when launching apps from rofi, as well as implementing desktop groups to allow easily switching to a logically grouped set of desktops (work, play, etc.)

Look forward to playing with this more.

I thought it was there; it is in the default dkrc file -

	# focus windows when receiving activation and enable focus-follows-mouse
	dkcmd set focus_open=true focus_urgent=true focus_mouse=true
1 Like

Yes, that’s “focus follows mouse”, but not “mouse follows focus”, ie. warping. The other options ‘focus_open’ and ‘focus_urgent’ are a little ambiguous… no mention in the manpage if the mouse is warped or not.

An example from my sxhkd:

# focus the next/previous window in the current desktop
super + {_,shift + }c
	bspc config pointer_follows_focus true; \
	bspc node -f {next,prev}.local.!hidden.window; \
	bspc config pointer_follows_focus false

1 & 2 I believe are related and there’s likely an error in the handling of multiple monitors in vertical orientation as others have had similar issues recently.

Possibly but I haven’t found a need for it yet.

I dislike mouse warping so it’s never been added.

That’s a lot of code being ran to just switch window focus, dk has the ability for the user to easily add their own functionality by only changing the config header

diff --git a/src/config.def.h b/src/config.def.h
index bf8e8ee..46f85c2 100644
--- a/src/config.def.h
+++ b/src/config.def.h
@@ -134,6 +134,14 @@ int tstack(Workspace *ws)
        return 1;
 }

+int ptrwarp(__attribute__((unused)) char **argv)
+{
+       if (selws->sel)
+               xcb_warp_pointer(con, XCB_NONE, root, 0, 0, 0, 0,
+                               selws->sel->x + (selws->sel->w / 2),
+                               selws->sel->y + (selws->sel->h / 2));
+       return 0;
+}

 /* New commands and callbacks must be added to the below arrays if you want to use them */

@@ -192,6 +200,7 @@ Cmd wincmds[] = {
        { "stick",    cmdstick    },
        { "swap",     cmdswap     },
        { "focusm",   focusmaster },
+       { "warp",     ptrwarp     },

        /* don't add below the terminating null */
        { NULL,       NULL        }

Then this will both swap focus and warp (order does matter as the command is consumed and “executed” left-to-right)

dkcmd win focus next warp

# or maybe more readable
dkcmd win focus=prev warp

You can make new workspaces by changing the number allocated, if it’s more than current.

dkcmd set numws=20

however there is no way to directly initialize a single workspace, they can be named and addressed like that but only after being created.

I don’t have plans to add/change things and I think dk is relatively feature complete at the moment, it just needs some work on multihead and bug fixes. I won’t say no to stuff like groups or creating new workspaces in that way but I wouldn’t hold your breath.

1 Like