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!

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.

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.
  

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.

Cool, thank you z3bra. Yes, simple consistency. Change and go.

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.

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.

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.

@dkeg:
Thanks a lot. I'll read some of the docs and try it.

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 :)

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.

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.

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.

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!

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?

If you consider 2 years a "proof of concept" demonstration, then yeah :)

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?

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.

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 😉):

(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.

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.

(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

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:


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.

Is it possible to make xmmv behave similar to other WMs, namely start moving a window with Mod4 hold + click drag a window, and place on mouse release? I like how window dragging/resizing implemented in bspwm (resize from any corner, not grabbing mouse pointer), I think grabbing user's mouse pointer is the worst thing you can do in desktop UI, it throws me off so much, like if somebody just took my physical hand and yanked it to some other place. I can't find anything which would work similarly to bspwm for wmutils. WMs like 2bwm, windowchef, glazier are also don't have my beloved move/resize, and they add other features I don't need.

This is not possible to do, while maintaining the way xmmv works right now. The behavior you expect involves that xmmv runs as a background process, while grabbing the shortcut Mod4+click. By doing so, it could detect mouse press and mouse release events, and then move the window accordingly.

However, the way it works now is that you only run it when you want a specific window to move. So you must have a way to spawn the process. Once the process is started, it must grab user input to detect the next mouse release event.
There is no way (that I'm aware of) that would make the following work:

1. Press Mod4 and hold click down
2. Spawn xmmv
3. Have xmmv detect mouse release

We did some testing, and xmmv just doesn't see the mouse release, because it is only reported to the program that spawned it (usually sxhkd or xbindkeys).

tl;dr: nope, impossible. Use a dedicated process that would run at all times to do it, like swm or glazier.

Ok, I've decided that 2022 is the year that I try wmutils. I'm fairly comfortable without a mouse these days as my wm of choice for the past 12 months has been sdorfehs which is a ratpoison clone.

I'd like to start with only wmutils scripts and no underlying wm. All I really need it the abilty to split the screen virtically as I tend to only use two terminal windows per screen.

My only question's now before I take the plundge are:

• How does one set up multiple workspaces and is this even possible without a wm?
  
• I suppose it's possible to set gaps for predefined tiling layouts using the specific pixel latitude/longitude tiled windows?
  

If I can't survive without a wm then I'll install one. Probably glazier.

Workspaces can be reduced to a list on windows to show at a given time. Say you start on ws#0. When you "switch" to ws#2, you save the list of currently visible windows, hide them, then get the list of windows on ws#2 and display them.

This would be a good exercise to start digging into wmutils, and make your first script. Here follows an example implementation if needed (don't spoil yourself too quickly ;))

As for "gaps", you gotta do the maths when coding your own tilesets.

Well here I am again, it's now 2023 and I have finally had a first attempt at a wmutils session. YAY!

It works. I can launch windows with dmenu and move/resize/fullscreen using sxhkd bindings.

I still have a lot to figure out. Tiling will help, but first I need a centre.sh script. I'd like for the first window I open to open in the centre of the screen. Ideally i'd then like to implement an auto tling script where opening a second would move the existing window, and have both windows evenly placed in the centre of the screen (with the gap/split between windiwd bcomming centred).

I dont think I'll get to crazy with tiling layouts using wmutils. To start with, I really just want to be able to split the screen down the middle and allow for maximized+tiled and floating+tiled windows. As I do now, I'll just use workspaces to my advantage when needing space for more windows.

I still have many things to figure out but I'm just taking my time with it (obviously). I hope Y'all are still around because I'll be posting more questions up here soon no doubt. I'll post up my sxhkdrc and .xinitrc later for advice on how to sanitise them both.

This is my first post back here on nixers in over a year. I've been busy havng more kids and then realising that free time for fun *nix things becomes less when you've gotta keep said kids alive and happy :)