wmutils tricks and tips - Desktop Customization & Workflow

Users browsing this thread: 1 Guest(s)
z3bra
Grey Hair Nixers
Hey all!

As a proud developper of wmutils, I'm openning this thread to have a single place to discuss wmutils scripting, share scripts and find out new use for it.

So there you go!
BANGARANG, MOTHERFUCKER
Wildefyr
Long time nixers
Not sure if anyone else has a solution easily find what process is currently running in a window when given it's window id, but I have been using this: https://github.com/Wildefyr/fyre/blob/master/wclass heavily for my tiling/detection scripts.
dkeg
Members
I leveraged my current battery state/level script to color the window border(s) accordingly. Also customized rainbow to pulse red when at critical level. All colors used for borders are sourced from xrdb.
  • bbdr for active border colors based on battery state/level. This will give you a static border color as such. Source bbdr in focus, then set active border color as '$bb'
    rnbw for pulsing red when critical. To use this you don't necessarily need to change the active border color in focus, because the colors are the same (they actually work better together, coloring the newly focused window border with a bit less lag). By default rnbw will only pulse at critical level. I left in commented code to easily change to pulse always. Easily customizable to fit your needs.
work hard, complain less
z3bra
Grey Hair Nixers
Damn I love the idea of using pulsing borders for battery notifications!
If I get a laptop, you can be sure that's what I'll use :P

I also noticed you still use your "colr" script. I need to work on a way to get everything smoothly controlled (speaking theme-wise) myself.
I should check uurn too, as it might result in a cool way to generate themes on the fly, as well as automating everything.
dkeg
Members
Cool, thank you z3bra. Yes, simple consistency. Change and go.
work hard, complain less
Wildefyr
Long time nixers
Bit too tired to implement this right now, but has anyone got a method of detecting a button click? Want to run focus.sh when I left mouse click. Mainly because wew event 7, entering a window, doesn't work when the mouse moves over windows that don't have a gap, or moving the mouse very fast even with gaps.
pranomostro
Long time nixers
I am very fascinated by wmutils, although I haven't tried it yet.

One question: how do you open a window with it? Because I know the utilities can move windows around, resize them etc, but I have got no idea how I would open a window.

When you tell me, I'll probably say: »Yes, of course, I was so stupid«, but at the moment I have got no idea how to do that.
dkeg
Members
No worries ... Really the same way as with any wm
Terminal
Dmenu
Keybind
I have keybinds for terminal and browser. Anything else I used dmenu, which of course has its own keybind.
work hard, complain less
pranomostro
Long time nixers
@dkeg:
Thanks a lot. I'll read some of the docs and try it.
sagittarius
Members
Do you guys use wmutils to complete your wm or do you only use it as a custom wm ?

I'm in love with 2bwm (thanks again venam & contributors) and I would like to improve it with custom scripts based on wmutils. So far it is more complicated than using wmutils & swm. I had issues with the latter so I switched back to 2bwm.

I'd like to get the best of both worlds.

Will share some work when ready :)
pranomostro
Long time nixers
I am really happy with my wmutils, but some programs just don't want to
work well with it (I'm looking at you, sam...)

But it really rocks. It just feels right to have a truly personal environment.

I use it as a custom wm.

Just yawee running in the background, with sxhkd, so fairly normal.
xero
Long time nixers
wmutils is my only wm these days. it's really fun building your own personalized setup from some basic building blocks. i have to say i sometimes miss herbstluftwm's binary tree division style tiling, but not enough to switch back. i admit, there's a semi-steep learning curve at the start, but it plateaus quickly.

(15-06-2016, 03:58 PM)sagittarius Wrote: So far it is more complicated than using wmutils & swm. I had issues with the latter so I switched back to 2bwm.

i also had issues w/ wmutils + swm. after talking to dcat, i just removed swm and everything started to work as expected.
sagittarius
Members
I have used herbstluftwm and bspwm for a while but I needed more freedom. That's why I've chosen 2bwm.

I deeply love wmutils but damn it doesn't want to work properly. The main issue is a buggy focus and I didn't manage to fix it yet. I've already written some custom scripts and I can't wait to use them.

I will use the Wildefyr's fyre as a base since it is fully functional.

EDIT:

'kay now everything is working fine. The only little isue is that urxvt opens in the top left corner, before being moved by fyre's scripts. Is this a normal behaviour ? Quite ugly to see this window blinking when opening terminal, especially when it's the only tool you use.
lemons
Members
I wanted to share the script I'm currently working on. It's my first reasonably novel wmutils script; it's called nyntyl.sh and it's purpose is to arrange/manipulate windows along a 3x3 grid.

I'm sure I'm probably not the first person to come up with a script to do this, but I haven't come across one in the wild, and I'd really appreciate any feedback or tips for improvements (I'm still pretty new to shell scripting).

I also wanted to take this opportunity to thank the wmutils devs! You guys did an awesome job, and in my short time as a wannabe nixer I haven't come across another utility as flexible and inspiring, so thanks!
NetherOrb
Long time nixers
To expand on what sagittarius had said is the intent for wmutils to merely supplement an existing wm?

I saw the example z3bra uses on his blog where it wasnt using one. Was the demonstration merely proof of concept? Or another use as a stand alone wm?
z3bra
Grey Hair Nixers
If you consider 2 years a "proof of concept" demonstration, then yeah :)
Ramiferous
Nixers
Bumping this thread.

z3bra, I've been doing some research on wmutils and I want to try it out for myself. Checking out your website, I notice you also have a project called glazier which looks interesting. I also found a project by tudurom called windowchef which looks similar in ways.

Now I know I have much more reading to do, but I was shocked to see that this thread was still only on the first page! Can we bring this one back to life again as I am keen to try out wmutils, either as a stand alone window management or together with a wm such as cwm etc etc... But looking for advice, guidance, recommendations all that.

So, is anyone still using wmutils and can anyone give a noobie a good place to start?
_____________________________________________________________________________________________
“Maybe you have some bird ideas... Maybe that's the best you can do.” - Terry A. Davis (R.I.P Percival)
phillbush
Long time nixers
I use some wmutils to complement the wm I'm writing.
At first, my wm didn't support window moving and resizing with the mouse, so I used wmutils' xmmv and xmrs in order to do it (I think tudurom's windowchef followed this same path). Now that I have implemented them, I use the non-mouse counterparts of those programs: wmv and wrs for key binding.

In a later moment, I think in get rid of my wm and go full wmutils, but I still heavily depend on EWMH hints, so having a wm behind the scenes is very useful. And also there are some features that I really want and that would be hard to implement with wmutils, features which induced me to write a window manager: mainly smart-placing of windows when opening them. I think glazier does something alike by placing new windows below the cursor, but I wanted something that places new windows in a blank area on the screen, where there are no (or few) window.

I am, however, very interested in how people implement window tiling with wmutils, considering the variables such as:
• changing tiling layout
• monitor boundaries
• tiling in different workspaces/groups
• whether window state can switch between floating and tiling, and whether to keep track of its status and position
• and whether the script auto-tiles windows when changing workspace/group or opening/closing a window.
z3bra
Grey Hair Nixers
I read the docs of your WM, and it's pretty interesting ! You managed to get a lot done in a short period of time !

Be careful when relying on wmutils though. It looks like your WM is meant to be controlled over EWMH hints, which is the exact opposite of wmutils' goal.

As an example, in your sxhkdrc, you shouldn't rely on `pfw` to act on the active window. "Active" has a special meaning in the EWMH spec, because there is a corresponding attribute associated with it: "_NET_ACTIVE_WINDOW".

The active window isn't necessarily the one that has focus. So as far as you're using wmctrl to perform an action, you should specify ":ACTIVE:" as the window name, rather than relying on `pfw` (and that's one less fork !). This would be more solid, and would fit your WM's philosophy better (fully EWMH controlled).

I took the other path with glazier: having the WM do nothing, besides what wmutils can. I realised that having a tool in wmutils listenning for events ("wew"), is counter-efficient, and doesn't match what wmutils wants to be: A fully stateless set of utilities that directly send its requests to the X server.

Now about your questions ! As I said, wmutils is fully stateless, and doesn't have anything running in the background to track window positions, or whatever.

• changing tiling layout

Back when I was doing tiling, I had a script (tile.sh) that took as an argument the tiling mode (horiz, vert, full, stuff like that). When you run it, it recalculates EVERY window position, and place them according to the window stacking position (the order listed by lsw). the last one (with keyboard focused) was in the "Main area".

• and whether the script auto-tiles windows when changing workspace/group or opening/closing a window.

The only way you have to do it is with "wew", from wmutils-opt. At first I was triggering the tile.sh script on every CREATE/DELETE event. On such event, it would recalculate the whole layout, and windows were changing places according to their new position in the stack.

You can certainly imagine how inefficient and frustrating that can be.

I quickly moved back to calling the tile script manually from keybind or dmenu, ala cwm. This might sound tedious, however, I accommodated to it, and after some time, I liked that every window popped in "floating mode". This way temporary windows don't fuck up your tiling pattern.

• whether window state can switch between floating and tiling, and whether to keep track of its status and position

All windows poped floating. Running the script made every window tiled. Nothing in between (though now that there is "atomx", you can save states on a window. You probably won't though!)

My tile.sh script was written in shell, which means that it sucks to do proper window size calculations (no floating points, etc…). It was also slow to tile every window, so I would only call that script when appropriate, to avoid the flickering effect of the tiling recalculation.

When resizing a window, the other window wouldn't move to fill the remaining space. I tried to script it at some point, and quickly gave up. I cloud resize the master area however, by calling the script with a different percentage size for the master area (you had to make sure that the currently focused window was the main one, otherwise another window would take its place).

This means that tiling worked like in "dvtm". The only control you have is resizing the master window.

• tiling in different workspaces/groups

Please no. Everything was already too much of a pain.


As you probably guessed, I gave up on tiling with wmutils. It is simply not the best tool for the task (I gave up on tiling overall, but that's another topic). Tiling require many calculations per seconds, and for a smoother effect, you gotta send all your resize/move events to the X server BEFORE flushing the connections (so all changes appear at the same time).

wmutils tools, because they work in a standalone maner, need to flush the connection after every call, so every single change is visible, causing the flickering effect.

• monitor boundaries

wmutils has no visibility over what a monitor is, so I wrote randr to do that. It's pretty stupid, but get the job done. By default it prints the geometry of the monitor when the cursor is. Pass it a window id, and it gives the monitor where the window is (top-left corner).

When I switched to a 2 monitor setup, I replaced all occurrence of "wattr whxy $(lsw -r)" with "randr $(pfw) | cut -f 2-5". Simple as that. See my "maximize" script for example (note saving state in the ORIGINAL_SIZE atom 😉):

Code:
#!/bin/sh

# Make the current window cover the whole monitor, or change it back to
# its previous size if it's already maxed out

cur=$(pfw)
wid=${1:-$cur}
gap=1
atom="ORIGINAL_SIZE"

[ -z "$wid" ] && exit 1

# current window size
w="$(wattr w $wid)"
h="$(wattr w $wid)"
b="$(wattr b $wid)"

# monitor size / position
mx="$(randr $wid | cut -f 4 | head -n 1)"
my="$(randr $wid | cut -f 5 | head -n 1)"
mw="$(randr $wid | cut -f 2 | head -n 1)"
mh="$(randr $wid | cut -f 3 | head -n 1)"

# take gap/border size into account
mx=$((mx + gap))
my=$((my + gap))
mw=$((mw - 2 * (b + gap)))
mh=$((mh - 2 * (b + gap)))

# retrieve original size saved in the "$atom" X atom (if any)
size="$(atomx $atom $wid)"

if  [ -n "$size" ]; then
        wtp $size $wid
        atomx -d $atom $wid
else
        atomx ${atom}="$(wattr xywh $wid)" $wid > /dev/null
        wtp $mx $my $mw $mh $wid
fi

wtf $wid
phillbush
Long time nixers
(25-08-2020, 09:14 AM)z3bra Wrote: The active window isn't necessarily the one that has focus. So as far as you're using wmctrl to perform an action, you should specify ":ACTIVE:" as the window name, rather than relying on `pfw` (and that's one less fork !). This would be more solid, and would fit your WM's philosophy better (fully EWMH controlled).
You're right, I'll use wmctrl's :ACTIVE: argument, as _NET_ACTIVE_WINDOW is supported and used by shod.

Yeah, dealing with tiling is a pita, particularly with the limitations imposed by wmutils (stateless, one event sending per time, the limitations of the shell-script language, etc). A tiling script will eventually become a giant behemoth when adding those variables I've cited. And dealing with different layouts is a problem mainly because of shell's lack of complex data structures. A binary tree division style tiling would be nearly impossible to maintain with wmutils. But, hey, maximization is an instance of tiling: the monocle layout, which is the simplest and most straightforward tiling layout.

As for using monitor information with wmutils, I've just found mmutils, that lists monitors, print their sizes and attributes, etc.

(24-08-2020, 09:43 PM)Ramiferous Wrote: Now I know I have much more reading to do, but I was shocked to see that this thread was still only on the first page! Can we bring this one back to life again as I am keen to try out wmutils, either as a stand alone window management or together with a wm such as cwm etc etc... But looking for advice, guidance, recommendations all that.

I think you should check out fyr's fwm, which is one of the most complete and coherent set of wmutils-based scripts I have found. You can use his scripts as a base for writing yours.

I think that using wmutils as a supplement for a simple wm (like cwm, windowchef and z3bra's glazier) is the way to start from.
z3bra
Grey Hair Nixers
Mmmh yeah, forgot to answer the original question !

wmutils' goal is to provide a simple, standalone and scriptable interface to the X server. Think coreutils, but for X. It grew from the fact that EWMH is a pain to work with, and that you shouldn't need a fully-fledged WM when all you need is moving the current window 10 pixels to the right.

Its composability make it very well suited to control windows from a key binder like xbindkeys or sxhkd.

Over the years, I realize that if you need to react to X events (window creation, deletion, ...) you need an piece of software monitoring those events, and triggering changes. That is why I made my own WM whose only purpose is to provide resizing and moving with the mouse. I made it as a first class citizen for wmutils, so everything I do with the keyboard is done with wmutils.
Ramiferous
Nixers
(25-08-2020, 01:53 PM)phillbush Wrote: I think you should check out fyr's fwm, which is one of the most complete and coherent set of wmutils-based scripts I have found. You can use his scripts as a base for writing yours.

I think that using wmutils as a supplement for a simple wm (like cwm, windowchef and z3bra's glazier) is the way to start from.

Awesome thanks, I'll check it out.

(26-08-2020, 03:25 AM)z3bra Wrote: Mmmh yeah, forgot to answer the original question !

wmutils' goal is to provide a simple, standalone and scriptable interface to the X server. Think coreutils, but for X. It grew from the fact that EWMH is a pain to work with, and that you shouldn't need a fully-fledged WM when all you need is moving the current window 10 pixels to the right.

Its composability make it very well suited to control windows from a key binder like xbindkeys or sxhkd.

Over the years, I realize that if you need to react to X events (window creation, deletion, ...) you need an piece of software monitoring those events, and triggering changes. That is why I made my own WM whose only purpose is to provide resizing and moving with the mouse. I made it as a first class citizen for wmutils, so everything I do with the keyboard is done with wmutils.

It's sounding like a lot of work to get things set up. If I find the time I'll definitely have a crack at it but I'm now trying to decide is it worth it? I like how you've integrated the use of resize/move with mouse. I'll put a pin in this for now, but will certainly come back here to report my experience once I get time to muck around with wmutils.

Cheers
_____________________________________________________________________________________________
“Maybe you have some bird ideas... Maybe that's the best you can do.” - Terry A. Davis (R.I.P Percival)
z3bra
Grey Hair Nixers
It does take some time to get things setup the way you want it, indeed. I'd argue that it takes pretty much the same amount of time as coming up with a nice WM configuration for i3, bspwm, you name it. You can think of wmutils as a WM with a shell-based configuration file, thus providing all the composability power of the shell.

Having a simple, working setup is fairly easy, especially if you use a simple WM like glazier or swm to handle the mouse pointer.
Then you can use this sxhkdrc as a starting point:

Code:
alt + {h,j,k,l}
  wmv {-10 0, 0 -10, 0 10, 10 0} `pfw`

alt + shift + {h,j,k,l}
  wrs {-10 0, 0 -10, 0 10, 10 0} `pfw`

alt + x
  killw `pfw`

alt + Tab
  wtf `lsw | head -n1`; chwso -r `pfw`

Then, when you need a specific behavior, you can make a script that does what you want, and bind it to a key. You will construct you workflow piece by piece, over the time.