[solved] Dk: view, focus workspace in static_ws=true, 3 monitors setup

Hi all, it’s been a long time since i posted on the forum but I come time to time to read stuff…
I posted on nate bitbucket issues section and since he doesn’t use a multi-monitor setup I imagine he can’t reproduce it, so I won’t rewrite the topic here and if someone can put me on tracks I will appriciate very much
my files here dkrc, windows rules & sxhkdrc

I was wondering who opened the issue :), I’m working on getting another monitor setup to test things but other peoples help would be appreciated.

I duplicated the issue this issue this morning (2 monitors, WS 1-5 on one, 6-10 on the other):

I have one window on workspaces 1 & 2 and working on monitor 2 workspace 5, when I want to focus or view workspace 2 which is not visible, the focus comes on workspace 1 (visible) so I have to bind workspace 1 again and then workspace 2 to finaly see the desired window…

However, if the first monitor is set to an empty workspace (WS4 in this test), then WS2 receives focus and becomes active as expected.

Hope that helps.

2 Likes

Well, I don’t get this “issue” in bspwm or i3 even though my workspaces are configured the same way… but that’s a problem in static_ws=true and I after all like the dymanic mode on multihead so I don’t have this little annoyance.
So the issue is still open but I avoid it for now

ws one is occupied & visible, ws two is occupied but not visible
Thanks again friends

Did you check my configs ?

No but I don’t think I really need to, got my second monitor set up now and using some basic config settings for testing (got off work early today)

mon1='DisplayPort-1'
mon2='HDMI-A-0'
dkcmd set static_ws=true \
	ws=1 mon=$mon1 ws=2 mon=$mon1 ws=3 mon=$mon1 ws=4 mon=$mon1 ws=5 mon=$mon1 \
	ws=6 mon=$mon2 ws=7 mon=$mon2 ws=8 mon=$mon2 ws=9 mon=$mon2 ws=10 mon=$mon2
2 Likes

… no luck :sleepy:

Haven’t had a ton of free time and my brain is pretty fried after work, it’s on the top of my priorities.

Sorry for the delay.

So I’ve done a bit of testing and I haven’t been able to recreate it, perhaps it’s specific to 3 monitors.

dk should be fully capable of handling multiple monitors and it has access to all the info xrandr does so I’m not sure what’s going on. If it’s an issue you really want solved I can provide instructions for creating a log file I might be able to get some info from.

Will look into it more tomorrow

Hi nate, well dkrc.log is empty…

Maybe you should, I rewrote dkrc in bash

#!/bin/bash
# https://pastebin.com/qFw26TuS
# DK WINDOW MANAGER CONFIGURATION FILE
logfile="$XDG_CONFIG_HOME/dk/dkrc.log"

: > "$logfile"

{
# let's include windows rules function
source "$XDG_CONFIG_HOME"/dk/_WindowsRules

# workspaces/monitors settings using xrandr.
if [[ -n $(pidof nvidia-persistenced) ]]; then
    xrandr --output DVI-D-0 --primary --mode 1920x1080 --pos 0x0 --rotate normal \
           --output HDMI-0 --mode 1920x1080 --pos 1920x0 --rotate normal \
           --output DP-0 --mode 1920x1080 --pos 3840x0 --rotate normal
            MONITOR1="DVI-D-0"
            MONITOR2="HDMI-0"
            MONITOR3="DP-0"
else
    xrandr --output DVI-D-1 --primary --mode 1920x1080 --pos 0x0 --rotate normal \
           --output HDMI-1 --mode 1920x1080 --pos 1920x0 --rotate normal \
           --output DP-1 --mode 1920x1080 --pos 3840x0 --rotate normal
            MONITOR1="DVI-D-1"
            MONITOR2="HDMI-1"
            MONITOR3="DP-1"
fi

# initialize 10 workspaces (1-10) (default: 1/monitor)
dkcmd set numws=10

# default workspace '_' values used when allocating new workspaces
# can be applied to all existing workspaces when passed 'apply' after ws=_
dkcmd set ws=_ apply layout=tile master=1 stack=3 gap=0 msplit=0.52 ssplit=0.5
dkcmd set ws=1 layout=grid
dkcmd set ws=7 layout=none

function _wslayout {
    awk '
    /^workspaces:/ {sub(/^workspaces: /, ""); gsub(/(*)?[0-9]*:\w*:/, ""); print; exit}
    ' <(dkcmd status type=full num=1) \
    | sed 's/dwindle/D/g;s/grid/G/g;s/mono/M/g;
    s/none/N/g;s/rtile/R/g;s/spiral/S/g;s/tile/T/g;s/tstack/W/g'
}

# Indicates the active startup workspace layout beside the name.
# The polybar ewmh module will look like this:
# 1:T 2:S 3:N etc...(name:layout)
# dwindle=D grid=G mono=M none=N rtile=R spiral=S tile=T tstack=W

dkcmd set static_ws=true \
    ws=1 name=1:$(_wslayout | awk '{print $1}') mon="$MONITOR1" \
    ws=2 name=2:$(_wslayout | awk '{print $2}') mon="$MONITOR1" \
    ws=3 name=3:$(_wslayout | awk '{print $3}') mon="$MONITOR1" \
    ws=4 name=4:$(_wslayout | awk '{print $4}') mon="$MONITOR1" \
    ws=5 name=5:$(_wslayout | awk '{print $5}') mon="$MONITOR2" \
    ws=6 name=6:$(_wslayout | awk '{print $6}') mon="$MONITOR2" \
    ws=7 name=7:$(_wslayout | awk '{print $7}') mon="$MONITOR2" \
    ws=8 name=8:$(_wslayout | awk '{print $8}') mon="$MONITOR3" \
    ws=9 name=9:$(_wslayout | awk '{print $9}') mon="$MONITOR3" \
    ws=10 name=10:$(_wslayout | awk '{print $10}') mon="$MONITOR3"

if ! hash polybar wmctrl >/dev/null 2>&1; then
	notify-send -t 0 -u critical 'polybar, wmctrl should be installed...'
fi

# checking external scripts
_check() { command -v "$1" >/dev/null; }

_check launch_polybar && launch_polybar &
_check sxhkd-start && sxhkd-start &

# global settings
dkcmd set focus_{open,urgent,mouse}=true
dkcmd set tile_{tohead,hints}=true
dkcmd set win_minwh=50 win_minxy=50
dkcmd set smart_{gap,border}=true
dkcmd set mouse mod=super move=button1 resize=button3

function _colours {

    local blu cyn grn mag red

    blu=$(xrdb -query | awk '/color4:/{print $NF}')
    cyn=$(xrdb -query | awk '/color6:/{print $NF}')
    grn=$(xrdb -query | awk '/color2:/{print $NF}')
    red=$(xrdb -query | awk '/color1:/{print $NF}')
    ylw=$(xrdb -query | awk '/color3:/{print $NF}')

    dkcmd set border width=2 outer_width=1 \
    colour \
    focus="$cyn" \
    urgent="$red" \
    unfocus="$ylw" \
    outer_focus="$blu" \
    outer_urgent="$grn" \
    outer_unfocus="$ylw"
}

[[ -f $HOME/.Xresources ]] && _colours

_WindowsRules

dkcmd ws 5

# dkcmd rule apply '*'
} >> "$logfile" 2>&1 # append responses

# inform of any errors in a notification
if grep -q 'error:' "$logfile"; then
	hash notify-send && notify-send -t 0 -u critical "dkrc has errors" \
		"$(awk '/error:/ {sub(/^error: /, ""); gsub(/</, "\<"); print}' "$logfile")"
	exit 1
fi

exit 0

Thanks

1 Like

It won’t be in the dkrc logfile that’s just for errors from the dkrc. dk reports info on stderr when built in debug or fdebug mode

# debug messages written by me, I add/remove when trying to find issues
make clean && make debug

# generated function enter->exit info
make clean && make fdebug

# then in .xinitrc you can redirect the output to a file
exec /path/to/debug/dk/dk > ~/dk.log 2>&1

Think I’ve got the error figured out thanks to some help from @PackRat, just waiting on some testing before I push it.

EDIT: I just pushed a change that should fix the issue natemaia / dk / commit / e92ed2c125db — Bitbucket
try building from source and let me know if you still have the same issue


I like most of the changes and condensing you’ve done and using bash brace expansion but I’m gonna keep the default using sh for portability sake and keeping things more simple for users. That being said it’s really cool to see someone taking advantage of the fact that dk is programmable from the shell, keep up the cool work.

3 Likes

I think going forward I will be removing static workspaces and supporting only the xmonad style dynamic setup. This was originally the way dk was designed but I buckled to some user requests and added support for both styles. This wasn’t a ton of code or hassle but recently I’ve decided I don’t want dk to be a jack of all trades wm and I’m looking to simplify.

With that said I don’t want to completely abandon the people who currently use static workspaces so I’d like this version to be stable for that use case before the switch back. People still looking for this kind of usage should look to other wms like dwm or bspwm. I really encourage people to use the dynamic workspace model for a week or so and decide it it’s for them or not.

Thanks for the help with this issue archus

4 Likes

Today it’s sunday so I have plenty of time to test your last commit, thanks again for working on users issues, I will thank you more if the fix is done :laughing:
My goal is to use dynamic mode, I think that’s the main reason I use dk, in static mode it’s a “bspwm” + a bunch of additional layouts (if I look at it on the surface) which is fine too (I like bspwm). Yes I know, I use bash and not sh but that’s the way I have done for bspwmrc just I feel more confortable with.
Ok now let’s test again! :facepunch: :wink:

1 Like

Well man you fixed it :+1: :ok_hand:
I keep this version for now even though I made a script to switch between static and dynamic mode on the fly because of the issue I had :rofl:
One more thing, can you mark this post as solved and teach me how to do it myself?

1 Like

You can change the title of your original post and add “Solved” at the end, or there should be a box you can check on the post that solved your problem. The box will turn green, or do both.

1 Like

Hi pack, I don’t even see the check box (don’t know why), but I changed the title thanks

1 Like

Glad it’s fixed.

I wasn’t trying to say you shouldn’t, I love bash too and it’s what I do most of my scripts in.

I checked out some of your other scripts for dk, very cool.

One thing I noticed is the amount of rules with the same values like all the floating ones, dk rule matching is fairly fast but you can still speed it up by avoiding so many rules and take advantage of the regex to combine them into one (we’re already converting the match into regex so might as well use it).

classes="" instances=""
while read -r line; do
	{ [[ $classes ]] && classes+="|$line"; } || classes="$line"
	{ [[ $instances ]] && instances+="|$line"; } || instances="$line"
done < "$FloatingApps"

# eg classes: "Confirm|Five-or-more|Fpm2|Gnome-disks|Gufw.py..."
dkcmd rule class="^($classes)$" float=true
dkcmd rule instance="^($instances)$" float=true

This will create a class rule and an instance rule for all the applications in $FloatingApps. But this does create two rules for each match which is a bit wasteful. Only one rule can be matched for a given client. I think seperate arrays/files for classes and instances would be better.

Likewise for many other similar rules in _WindowRules

dkcmd rule class="^file-roller$" ws=2 focus=true
dkcmd rule class="^filezilla$" ws=2 focus=true
dkcmd rule class="^pcmanfm$" ws=2 focus=true

# becomes

dkcmd rule class="^(file-roller|filezilla|pcmanfm)$" ws=2 focus=true

You can see the current rules with the following command (this list will need to be checked for every window opened).

dkcmd status type=full num=1 | sed -n '/^rule:/,/^$/p'

One other thing is that dk rules are always matched case insensitive so Firefox and firefox are both considered the same match.

After all this I feel like a bit of a snob, script however you like. I’m just offering some critique so don’t take it the wrong way. It’s super cool for me to see people using the flexibility of dk to work how they want.

2 Likes

Oh yeah, I forgot about :

nice trick

Thanks again :wink:

2 Likes