What is Reddit's opinion of
bspwm?
From 3.5 billion Reddit comments
100 reviews of this app found across Reddit:
There's an open PR for it here, but it hasn't been merged yet. If you want to try it out you can pull Javyre's fork and build from source.
It seems to work pretty well.
I was dealing with the same thing a couple of days ago.
This is due to changes to the bspc syntax.
You should find updated examples in /usr/share/doc/bspwm/examples/
pacman -S destroy-weekend :)
I try not to. The servers I need to SSH into usually have a tmux session running or if not, I want one to be immediately started, so that I could pick up my work where I left off (join back to watch some lengthy process, manage my torrents, etc.).
If I were to use a host tmux split and SSH into my server in a split then I would end up <C-b><C-b>ing constantly and also would lose track of where I am logged in to which servers.
Instead of that, I use a tiled window manager (bspwm) and instead of a new host tmux split I create a new split on my desktop to spawn another terminal, and have the remote tmux running there.
Ew sounds clumsy, huh? No.
Let's say I use a server to run my irc client (which I did).
- add to your
.bashrc:alias irc="ssh irc.kmarc.me -t 'tmux attach -t kmarc || tmux new -s kmarc'"- with this alias, I just need to type inircand I'll be brought to my session automatically - add to your hotkey config (in my case it's sxhkd):
super + space; i urxvtcd -ls -e bash -ci 'irc'- with this hotkey combo, I need press Win button and space (like in MacOS's spotlight) and then immediately keyiand a new window will be created.
If I need to ssh ad hoc, I'll press Win+Enter to spawn a new terminal.
I have my dotfiles on github, probably I should polish them and have a blogspot about how to configure this kind of tiled-window tiled-terminal workflow :-)
- wm: bspwm
- bar: bar
- wallpaper: Squidfingers pattern 156
- terminal: urxvt
i guess
bspwmrc
#! /bin/sh bspc config border_width 0 bspc config window_gap 3 bspc config split_ratio 0.52 bspc config borderless_monocle true bspc config gapless_monocle true bspc config click_to_focus button1 bspc config pointer_mod mod4 bspc config pointer_action1 move bspc config pointer_action2 resize_side bspc config pointer_action3 resize_corner bspc monitor DP-1 -d 1 2 3 4 5 bspc monitor HDMI-0 -d 6 7 8 9 0 bspc config pointer_follows_monitor true # Multihead behavior bspc config remove_disabled_monitors true bspc config remove_unplugged_monitors true exec ~/.config/bspwm/autostart
sxhkdrc
to start: just remove everything below
# Mouse click focus
(if you miss auto_alternate see: https://github.com/baskerville/bspwm/commit/4fbd961311a3b76f60b7128c85f5b8be0cd91ce2)
I've been happily using bspwm for quite a while, mainly because
- tiling :D
- it's very light weight and doesn't get in my way
- you use sxhkd for your keybindings, and I've set mine up so that it doesn't clash with any of my Emacs bindings.
I've been doing some Haskell work lately, and I've been thinking of trying the beast that is xmonad, but I may very well end up coming back to bspwm.
I'm curious to see other people's setup (yours too, OP).
If you're using the "-git" version of a package you should expect things to break. The version arch is using shouldn't have the new config options yet as they're coming in version 0.9.1 which hasn't been released yet. Just use the arch version and all the old tutorials/guides/configs should still be compatible.
You can see this page for a full list of changes:
https://github.com/baskerville/bspwm/wiki/Upcoming-Changes-in-0.9.1
I'm currently using bspwm with xfce4-panel, so bspwm does. This is in my config:
bspc monitor DVI-I-1 -d 1 2 3 4 5 6 7 bspc monitor DVI-D-0 -d q w e r t z u
You can add something like this to your external rules until you finish adding a WM_CLASS.
>#!/usr/bin/env bash > >fwid=$(bspc query -N -n focused.automatic) >wid=$1 >class=$2 >instance=$3 >title=$(xtitle "$wid") > >## Window rules ># Floating >if [[ "$title" == "raytracer" ]]; then >echo "desktop=^5 state=floating center=true" >fi
i3 would be a good choice to start with since it has a good default config and easy to learn without previous tiling experience. Once you're familiar with it you could try out other WMs and choose which suits you best.
I have been using bspwm for a while and liking it. It has simple style of configuration - basically you use separate programs for bars and keybinds, and configure it yourself from start to finish. Takes time to configure but very customizable.
ArchWiki and bspwm's GitHub repo have some customization examples.
Most of these can be applied to other tiling WMs too.
Take a look at the example panel from the bspwm repo.
In essence mkfifo creates a FIFO file, then you pipe messages into that file from forked threads and cat the file into your parse-command, which outputs the bar-friendly lines. The parse-commands is a while-loop and switch-case, that refreshes and echoes every time it can read another line from the FIFO.
It's actually very simple to use it, but if you want a more functionality out of it, you can learn and customise the keybindings. You will find the default set of keybindings within the sxhkdrc file. The commands correspond to the list found on the bspwm git repo.
> I have installed it, but have yet to start using it
By this, I'm assuming you've at least run the program once to check it installed correctly? Once you've started the window manager, you can use the commands found in sxhkdrc to do various things as stated in the file. At the very least, you will need to know how to:
- Open a new terminal window, which is usually (mod) + enter
- Close a window
- Launch a program, which uses a different program. I use dmenu, as do many others.
Do you mean the binary division of the selected wmnode described in 'Manual Mode' here: https://github.com/baskerville/bspwm? So that the new window tiles inside the selected node with the window that formerly occupied the entire space?
Found the solution here:
https://github.com/baskerville/bspwm/issues/678
Instead of the bindings mentioned erlier you now have to use
bspc config pointer_modifier mod4 bspc config pointer_action1 move bspc config pointer_action2 resize_side bspc config pointer_action1 resize_corner
Thats realy bad documentation/communication if you have to google everywhere, post on reddit and so on ... to find that the answer to that change is in a bug report in the github repo.
Exactly this. Exemples :
- here bspc suscribe report will trigger only when a state change in bspwm
- or here with the battery level that may be refreshed once every few minutes
I use pretty much the same thing on my set up as well. It works pretty swell.
Incidentally here is the commit that removed create_frame. So I guess using dynamic padding settings is something to look into.
EDIT: also you can use something like this:
XClassHint hint = { "name" , "class" }; XSetClassHint (display, win, &hint);
to set class and name hints for rules.
If you already use Ubuntu my suggestion is Xubuntu: xubuntu.org
Basically is the same thing with a different GUI. If you reeeeaaaally need to slim it down (From your set up I believe this is not necessary) You can go with a tiling window manager instead of a desktop environment. I would recommend [i3](i3wm.org) or bpmwm.
My tiling windows manager (bspwm) is implementing a binary search tree to partition the screen. Every window is a leaf. Every container is a node with a left and right set to either another container or a leaf (window). Of course windows have other properties too, like the title, size etc. but those aren't interesting regarding the binary tree. Window movement results in a rotation of that binary tree.
It may be a bit overengineered, but I like it. If I would program a game or something where rooms are of matter, I would always implement a binary tree to describe my room hierarchy, because it for example simplifies problems like pathfinding down to a level where I only have to cross the current room. Which in some cases can be partitioned again.
For actual searching and sorting problems I highly suggest using a fibonacci tree or a fibonacci heap instead. For example the priority_queue of the C++ STL implements one.
If you're not sure what the key is named, you can start xev in a terminal and then press the key. The key name will be on the keysym with a name like Shift_L, Alt_R, etc..
Polybar does not ship with example config.
If you look at upstream polybar repo at https://github.com/polybar/polybar, there is no default/example config (at least I couldn't find one).
https://github.com/baskerville/bspwm if you look at bspwm upstream repo, there is default/example config, and so it is in freebsd package
FreeBSD usually ships packages/ports as close as possible to upstream. And so, if there is no example config in upstream, there will not be one in freebsd package, unless someone(port maintainer) go out of their way to provide one.
What I can think of:
You can use xrandr to make your screens into one big screen. You probably don't want this, but maybe you do?
xrandr --setmonitor NameOfDisplay auto HDMI-A-0,HDMI-A-1
You could create separate desktops for each monitor and then have keybinding to switch multiple at once (something like 1-9 on left, 10-19 middle and 20-29 on right and then meta+1 will switch to 1, 10 and 20). I'm not sure how to nicely write this into sxkhdrc, but you can always just make a simple script and call it.
edit: here is a small snippet on how to also implement next/previous desktop for multiple monitors
The second part...i'm not sure what you mean. I haven't used i3 in a while, so i'm not sure how it behaves there, but when I move window left in bspwm, it goes to the left screen.
The Arch Wiki has a section called Set up a desktop where all windows are floating (source)
If google translate translated your message correctly (it says you are asking for a mouse binding that allows you to drag a window to a receptacle), yes, this is possible.
It is very easy actually compared to the other mouse movement bindings that people have requested in the past:
- drag a window from tiled state to floating;
- re-implement <code>bspwm</code> mouse actions as a shell script so that they can be bound to something else.
Since we only care about the initial and the final position of the mouse, we can implement this binding with few lines of shell scripting code.
In sxhkdrc(requires bspwm version 0.9.10):
ctrl + alt + button3 bspc query -N -n pointed.window > /tmp/bspdragtoreceptacle_file \ || rm /tmp/bspdragtoreceptacle_file ctrl + alt + @button3 if wid=$(< /tmp/bspdragtoreceptacle_file); then \ bspc node "$wid" -n 'pointed.!window.leaf'; \ bspc node "$wid.!tiled.!pseudo_tiled.window" -t tiled; \ fi; \ rm /tmp/bspdragtoreceptacle_file
That's it. :^)
This will bind ctrl+alt+right_click to that drag thingie you want.
Nice idea.
> Thanks again for the detailed explanation dude
No problem.
> EDIT: I just realized I was confusing nodes with windows and that I don't know what nodes are exactly
Basically, every desktop that has windows (or receptacles) in bspwm has a binary tree.
In this binary tree, the "leaves" (this is CS terminology; read the wikipedia page I linked for definitions) of the tree are the receptacles and the windows, and the non-leaf nodes are nodes that group other nodes in horizontal or vertical splits.
(this method of partitioning space is called Binary Space Partitioning, that is where the BSP in bspwm comes from.)
If you want some visual examples, go read the README.md for bspwm; it has some diagrams that might help you understand. In those diagrams, letters are non-leaf nodes and digits are leaf nodes.
> Hello, I tried to change the automatic_scheme to longest_side, but it still uses the default fibbonacci layout, is there a way to change this? Thanks.
What you call "the default fibonacci layout", is actually called "the longest_side automatic_scheme" (note: the "layout" is also influenced by other settings such as initial_polarity, split_ratio, etcetera) and it is the default automatic_scheme.
The other automatic_schemes you can set are alternate and spiral (as well as longest_side of course).
You can find out what a setting does and its possible values in the man page for bspwm (or bspc). This is true for every bspwm setting.
From bspwm(1):
automatic_scheme The insertion scheme used when the insertion point is in automatic mode. Accept the following values: longest_side, alternate, spiral.
NOTE: automatic_schemes are also explained in the README.md file that you can find in <code>bspwm</code>'s github repository.
>Except maybe polybar if that's how the polybar bspwm module works?
yea.
the issue that u/SeerLite might be referring to is described in this PR. That sounds more likely (unless polybar is acting up for some reason). See if that fits your situation and give the patch a shot.
Supon que abres una terminal, abres una segunda y se colocan mitad y mitad. Ahora abres una tercera (y en i3 las tres terminales se abren de manera horizontal) y esta se abra a la mitad de la una terminal. Puedes ver más información en su página bspwm
​
+-----------------------+ +-----------------------+ +-----------------------+ | | | | | | | | | | | | | | | 2 | | | | | | | | | | 1 | | 1 | 2 | | 1 |-----------| | ^ | | | ^ | | | | | | | | | | | 3 | | | | | | | | ^ | +-----------------------+ +-----------------------+ +-----------------------+
X Y Z
https://github.com/baskerville/bspwm/blob/master/doc/bspwm.1.asciidoc#stacking-layers
"There’s three stacking layers: BELOW, NORMAL and ABOVE. In each layer, the window are orderered as follow: tiled & pseudo-tiled < floating < fullscreen."
And you can send windows to the below or above layer, a basic z-index thing, and maybe if you wanted to you could also make such a window sticky.
I used i3 before and it was nice. But I didn't like how i3 splits windows or that gaps require multiple setup. BSPWM also splits configuration and makes it less cluttered. I've heard that many people use it because of its automation regarding windows and how it structures them.
https://github.com/baskerville/bspwm
In regards to my service, I'm positive it's enabled. However, I think I may have not done the configuration step properly as vaguely described on the arch wiki.
Have you considered contributing to an already existing project? There are many:
https://github.com/Kintaro/wtftw (this one's even written in Rust)
https://github.com/baskerville/bspwm
You might learn more by collaborating with experienced developers and shaping projects that already have users.
All right, this sequence of command sorta achieves what I want I think. However, all my actions require just one key combination, so I'm not a fan of the manual selection thing (it just doesn't really fit well with automatic splitting thing I got going, and I always know in advance how I want to split my to be warped window (namely, according to the rules in this pseudo automatic rules script)). I'm gonna look into chaining this sequence of commands, which I hope is doable. EDIT tyvm, see the edit in OP.
I believe this does the opposite of what you want: https://github.com/Chrysostomus/bspwm-scripts/blob/master/configs/bspwm/bspwmrc
You can try with a negative gap and positive padding.
Baskerville has an example with overlapped Ng borders worth exploring: https://github.com/baskerville/bspwm/blob/70b477de2e70dc46d78e11f7d78fc2d9c2448725/examples/overlapping_borders/bspwmrc
For anyone who comes across this issue from google: > Indeed solution is to change the JRE that the IDE uses, by default it uses the bundled JRE, to change it follow this steps:
> - Ctrl + Shift + A (Find Action) search for "Switch IDE Boot JDK"
> - Select your system JRE ubication, if not provide the path by the "..." button
> - Restart your IDE
Edit: Also see here.
I had poor font rendering when switching to Oracle's JRE. I found an alternative runtime in the IDE issue tracker that (after following instructions and updating the settings) solved the issue.
Maybe not the answer you're looking for, but what if you try bspwm?
I also tried hlwm, and had the same problem, mainly because I was already used to bspwm.
It also does the "spiral tiling", and you can easily control where the next window will open with mod+ctrl+{h,j,k,l} to pre-select the direction.
You can configure it on the fly with the bspc command, which means you can configure it with bash or some other scripting language. (Maybe I'm wrong, but I think that's the case with hlwm).
I was pretty into using Openbox for over a year. But at some point I decided to try bspwm and I haven't gone back yet. Not necessarily saying one is better than the other, but I prefer configuring bspwm's keyboard shortcuts since it is designed in such a way that everything you do with the WM is just a shortcut. I think it makes it more concise than the XML soup associated with Openbox.
I am running bspwn which is a tiling window manager, it automatically sorts the windows.
Config Here https://github.com/stagfoo/rice-files/blob/master/bspwmrc
I almost forgot to mention one of my other main motivations. Look at all of the great examples that herbstluftwm includes vs. bspwm's examples. I can use these to figure out how to do other things, whereas with bspwm I had to search for other peoples bspwmrc and read the source code for the window manager itself.
That makes more sense. I was wondering why someone with Arch flair using bspwm wouldn't know that :)
I'm not using bspwm any more to test this, but perhaps you could put something together using urxvt -name foo, bspc rule -a URxvt:foo --one-shot and receptacles?
It's fairly simple once you figure it out. A good place to start is with the bspwm included config and as long as you can follow the bash script, you can get pretty far from there.
Here're the links:
- bspwm for dummies: https://github.com/windelicato/dotfiles/wiki/bspwm-for-dummies
- bspwm example lemonbar: https://github.com/baskerville/bspwm/tree/master/examples/panel
One of his terminal windows was used to run screenfetch .. which lists stuff like window manager, icons, shell theme, etc. In this case his wm is bspwm. Hope that helps.
The solution is to kill every instance of the panel before you start it (when you open bspwm-session). Put this where you normally start the panel (.xinitrc if you use startx or in your bspwmrc)
killall panel ~/bin/panel &
Edit: Another solution is to kill it when you leave. To do this you can add this to your sxhkdrc
super + alt + Escape pkill -x panel; bspc quit
This is from https://github.com/baskerville/bspwm/tree/master/examples/panel
Uhm, yes, wait a little, have to search for it. Had that problem a few weeks ago.
edit: There are multiple solutions to the problem, but setting the following environment variable should be the preferred one:
_JAVA_AWT_WM_NONREPARENTING=1
(Export with your shell and iirc restart X)
Resources:
Just realized I had a couple of mistakes. I'd removed the lines related to !button. Now that that's fixed and sxhkdrc has been reloaded, I can resize floats.
The other thing that is included by default in the sxhkdrc file is a semicolon. Be sure to take it out if you want mouse resizing:
Thank you, this actually works!
It seems like Java applications are misbehaving on some (all?) tiling window managers and the arch wiki page of dwm has an actual fix for this, as found in a github issue for bspwm.
Does anyone know why the wmname "LG3D" is used?
What does the output from xrandr look like? Does it show HDMI3 as being the primary monitor?
Also, which version of bspwm are you running? There was a bug which caused incorrect numbering of workspaces, however it was fixed last year: 764b428d
I don't know anything about building on Debian, but a quick look turned up this on Baskerville's github issue tracker: https://github.com/baskerville/bspwm/issues/210 You could add your errors to the issue, hopefully he'll look into what they're doing wrong with the libs, find a fix or workaround.
(NOT OP) I'm running 14.04, with BSPWM on mine, so it doesn't resemble Ubuntu, but in terms of the touchpad, there are fixes out there that make it as it should be. In terms of HiDPI, I've kinda got used to it, with some apps like Firefox scaled up, and as I live in a terminal, I've got slightly bigger fonts there, but on the whole I'm still able to take full advantage of the extra screen real estate. Would definitely recommend it!
You probably need to figure out bspwm's way of saying "close this window", and then write a script that does that to all windows.
EDIT: I haven't used bspwm, but from reading this it looks like the command is bspc window [WINDOW_SEL] --close. I don't know what you'd want for WINDOW_SEL, but you can experiment.
There was a window type called a "frame" that drew a transparent X window into a node. That was reverted here after this was implemented. Here are the relevevant lines in my sxhkd. To get the windows in this scrot, i'd hit alt + [ to increase the padding to the left of the selected desktop! Sorry for missing this until now
1) You didn't install terminus or you didn't install terminus correctly
2) bspwmrc is a bash script that gets excecuted at launch, and never again. You can script it to reload. Look at the example here: https://github.com/baskerville/bspwm/tree/master/examples/loop. However, I would recommend just entering the command in the terminal you wish to change, and put it in the bspwmrc to make it persist on logout.
Så! Den här tråden fick mig att, efter över 20 år med amerikanskt tangentbord, bygga en lösning för att växla mellan svensk och amerikansk layout.
Nu kan jag växla layout med `super + F11`. Fick även tillfälle att lära mig något nytt. Jag kör Polybar och bspwm. Stoppade in en sektion som visar den aktiva layouten i Polybar. Gillade inte att den uppdaterades på intervall. Började läsa lite och såg att det finns stöd för "inter-process communication" (IPC). Använde detta för att se den nya layouten direkt efter att den ändrats. Nu kommer jag att kasta bort en massa timmar på att hitta intressanta användningsområden för det här. Sen ska jag försöka vänja mig vid den svenska layouten igen.
my two cents:
bspwm never shrinks padding when struts get smaller. i think changing that to shrink padding would require tracking the docked windows to ensure that the shrinking doesn't obstruct some other potential window with struts on the same edge (or make assumptions about padding).
you can do it via wrapper script easy enough - depending on how you are reloading the polybar config.
eg. check {top,bottom} padding setting of each monitor before polybar starts and use those values to compare padding after the bar maps. when polybar finishes then the wrapper script should set the original padding (or difference between the two)
or grep the bar config for bottom = true and use that to unset the padding in a similar way as above (which should work better if you are using polybar --reload).
There are many ways to do it.
One solution could be this (maybe use two binding: one for clockwise and one for counter-clockwise rotation):
super + e bspc node '@parent' -R 90
On the git version of bspwm, you can use node -y that simply changes the split type instead of rotating the parent:
super + e bspc node '@parent.vertical' -y horizontal \ bspc node '@parent' -y vertical
Using this patch, you can use node -y next to achieve the same:
super + e bspc node '@parent' -y next
An alternative solution to have the same behaviour as node -y next on 0.9.10 could be:
super + e bspc node '@parent.vertical' -R 90 \ || bspc node '@parent' -R -90
You could use a script like bspside.
You could use preselections.
Etc...
I would recommend an installation guide because you lack the knowledge of how bspwm functions in it's barebone state.
You need to install sxhkd
sudo apt install sxhkd
you then need the config files.
make corresponding dirs in your ~/.config folder with
mkdir ~/.config/{bspwm,sxhkd}
when that's done it's time to copy the example configuration files to the above made folders. Now, I don't know where they are installed on your system, but you can find them in bspwm's github
It is trivial that the bspwmrc file is made executable which you do with
chmod +x ~/.config/bspwm/bspwmrc
And then you are off to the races, start configure your sxhkdrc and have fun with it!
> its already usable, without single issue ...nothing to wait for bud.
I've tried it as recently as a couple weeks ago and it's still not quite there.
> But i dont think river is wayland's bspwm
I shouldn't have included the word clone. It looks like they changed their README, but it specifically said it was inspired by dwm and bspwm.
> River is a dynamic wayland compositor that takes inspiration from dwm and bspwm.
the rules don't work because they are not run.
>it didn't work. But when I put it before that block, it works.
your loop doesn't end and is not backgrounded. the example at the archwiki is backgrounded (but i doubt the suggestion of running from xinitrc would work out well).
a note - there has been now for some years: this, which is better way (my opinion) to achieve the same thing via an external rule script.
just an fyi since you already have a workaround
>Here's hoping there's an option or a method to refer to the window_role and auto float "Dialog" types.
this should already be done. check here, those functions will apply some default rules to a window. window role is not honored (but type is). but, you can always check these hints in an external rules script and then set floating.
>By setting it's state to tiled I everything is all good until
curious, does firefox nightly float by default?
Well, in my case "ricing" is just choosing the best backend for wpgtk for my current wallpaper, so my color scheme both matches my wallpaper and is usable.
I use bspwm with minimal config modifications, no window borders/headers, no panels, just the apps I use and keyboard hotkeys which I'm comfortable with.
might be related to this issue which caused artifacts for me in chrome/electron/alacritty
https://github.com/baskerville/bspwm/issues/1261
setting bspc config pointer_motion_interval 50 helps a lot
The cause of the issue has been found, see here:
- Reddit thread
- Stackexchange answer
- I created a GitHub issue
The cause of the issue has been found, see here:
- Reddit thread
- Stackexchange answer
- I created a GitHub issue
Hey, thank you very much for all your help with this issue!
I answered my own stackexchange post, I hope everything is correct ;)
I also created a GitHub issue on bspwm's repo: https://github.com/baskerville/bspwm/issues/1271
> I'd like to run a notification after running alt + 0
it can be done - take a look at this example.
>I'd also like for it to exit the mode after selecting an option.
use ; instead of : ?
>Smart Node Toggling
a keybind to toggle between fullscreen and the last state, like:
alt + f bspc node -t ~fullscreen
?
you might be interested in a PR u/torreemanuele6 submitted that can make toggling more useful: #1253
>an action will occur when clicking on the root window
not to ignore this part, but i don't have any tips here. only that sxhkd should be able to do that, and i feel like there may be a thread on this sub with details.
Ubuntu freezes the version of most software when released, just a small portion of the packages get updates after release (mostly security updates). You will need to build bspwm from source if you want a newer version.
The bspwm wiki in their github repo has instructions on how to build bspwm from source.
bspwm is working, you don't have any config/keybindings to do anything. It is a bare wm so you have almost nothing included without configuration. you need a daemon for keyboard shortcuts like sxhkd, and at least an application launcher like rofi. bspwm's config is at ~/.config/bspwm/bspwmrc and example configs here. Also make sure the config is executable with chmod +x ~/.config/bspwm/bspwmrc.
Are you sure that you want a window manager instead of a desktop environment at this stage? Seems like you should need to grasp the ropes of linux before moving to a bare wm.
Oh, just button2; I misunderstood you, sorry.
In that case, you can simply use xmmv from wmutils/opt; with this in your sxhkd configuration file:
~button2 bspc query -N -n pointed.floating > /dev/null \ && xmmv @button2 killall xmmv
You can also use this solution with this in your configuration file for sxhkd:
~button2 bspdragtofloat @button2 bspdragtofloat stop
This also has a "drag to float" behaviour (which is surprisingly quite nice), but it's probably going to be annoying since it will get activated by simply pressing button2 in your case.
You can adapt the script to simply moving floating windows like so:
bspdragwindow:
#!/bin/env bash
status_file="/tmp/bspdragwindow_dragging"
[ "$1" = stop ] && { [ -e "$status_file" ] \ && rm -r -- "$status_file" exit }
[ -e "$status_file" ] \ && exit
wid=$(bspc query -N -n pointed.floating) \ || exit
eval "$(xdotool getmouselocation --shell)" x=$X y=$Y touch -- "$status_file" while [ -e "$status_file" ]; do eval "$(xdotool getmouselocation --shell)" (( X != x || Y != y )) && { bspc node "$wid" -v "$((X - x))" "$((Y - y))" x=$X y=$Y sleep .01 } done
[ -e "$status_file" ] \ && rm -r -- "$status_file"
You might prefer using this script over xmmv for these reasons:
- it is more customisable, e.g. you could implement a behaviour that swaps tiled windows if you drag the pointer from a tiled window to another like
bspwmdoes by default. xmmvwill move the mouse pointer to the centre of the window when it is run which might result annoying; this script won't do it.
There is currently an open issue that asks a very similar question to yours. One possible solution, as I mentioned in the issue, would be to use virtual monitors (which contain a group of related workspaces) and write a script that allows you switch them out easily using some keybindings.
If you pursue this method, definitely post about it because I’d be interested in that script.
Honestly I think it's probably best to wait til Wayland (and libraries for it) to mature. I posted an issue back in February, asking for about how the project feels toward moving to Wayland now and the answer I got was this.
> Let me preface this by saying that I would love to see a port/rewrite of bspwm for Wayland, and I would love it even more if it were written in Rust.
> That said, this isn't something that happens overnight. A full rewrite of bspwm is a sizable effort even before taking into account the switch to Wayland. From what I understand, Wayland support in Rust is still very much a work-in-progress.
> One of the other Rust-based Wayland WMs mentioned in the other thread, Way Cooler, was declared dead at the beginning of this year. Additionally, the Rust-based Wayland compositor Way Cooler was built on, wlroots-rs was also abandoned.
> Right now the best option appears to be Smithay, but I cannot speak to its maturity as a library. The author of Way Cooler did have this to say:
> > Smithay is very incomplete. Very, very incomplete compared to wlroots. It is no where near usable and the current trajectory doesn’t look like it will be usable very soon either. wlroots is a great framework and has a strong backing in the community so I don’t see the need to abandon it just so I can keep using Rust.
> I certainly can't speak for @baskerville; I don't know if they will agree with me entirely or not, but I think that biding our time and waiting for Wayland support to mature in Rust will only make things easier for if/when we decide to pursue this.
From the readme.md in the BSPWM github.
The default configuration file is $XDG_CONFIG_HOME/bspwm/bspwmrc
: this is simply a shell script that calls bspc.
An argument is passed to that script to indicate whether is was executed after a restart ($1 -gt 0
) or not ($1 -eq 0
).
Keyboard and pointer bindings are defined with sxhkd.
Example configuration files can be found in the examples directory.
https://github.com/baskerville/bspwm#configuration
The default configuration file is $XDG_CONFIG_HOME/bspwm/bspwmrc: this is simply a shell script that calls bspc.
you could set the variable at the start of that config, or export it in your bash startup configs.
also..
https://github.com/baskerville/sxhkd/issues/129
details how to use exported variables in sxhkd
i think this is different from what op is describing, but maybe not. regardless it should be fixed in latest git
https://github.com/baskerville/bspwm/commit/5298a9121134103a81b9a47dfafd949e6350c55c
barless
dots: here are my dotfiles
wm: bspwm
colorscheme: ashes (in
pywal)walls: wallpapers are generated from your pywal colorscheme, the wallpaper is set on workspace change so that each workspace has its own wallpaper
term:
urxvtfont: PT Mono
notifications:
dunstother: I am using
sxhkdandnotify-sendto display, time, battery, and current workspace on change. This is the main things i was using in my bar so now i dont need them.network:
nmcli, I decided to finally just figure out how use it so now i dont need an applet.
I believe I did follow your advice, please correct me if I've missed something.
Here's my real-world example:
undocked
bspc monitor eDP-1 1 2 3 4 5 6 7 8 9 10
Here's the script I'm running upon docking: ```
!/bin/sh
Credit: https://github.com/baskerville/bspwm/issues/629
desktops_to_monitor() { monitor=$1 shift for desktop in "$@"; do bspc desktop "$desktop" --to-monitor "$monitor" done }
desktops_to_monitor DP-2-1 5 6 7 8 9 10
bspc monitor eDP-1 -d 1 2 3 4 bspc monitor DP-2-1 -d 5 6 7 8 9 10 ```
Hi, Thanks for the hint.
I did something similar to what msteen suggested in this issue.
I'm facing another problem now, where upon docking, an empty desktop is automatically created on that monitor so moving desktop 2 to it will actually add a second desktop.
Testing it with HDMI1 1 2 3 4 5 and HDMI2 6 7 8 9 10, 6 will be go to 7 on the new monitor (because 6 is occupied by the automatically created desktop), 7 to 8 and so on. 10 will end up on HDMI1 because it overflows.
On the issue, msteen mentions something about using virtual monitors, but I'm not entirely sure how it's supposed to solve this particular problem...
This is caused by the recent updates to bspwm - changelog.
Appending !hidden.window on that mapping should restore the previous behavior. The full command in sxhkdrc should look like this bspc node -f {next,prev}.local.!hidden.window.
Updated version which doesn't use xinput and doesn't have any latency between when you release the mouse and when the window stops moving: https://github.com/baskerville/bspwm/issues/1128#issuecomment-671566198
I'm posting it here too in case you haven't seen it on GitHub u/kristoferus
I don't understand what behaviour you want since you explained it very poorly, so I can't help you.
You are not obliged to use the example hotkeys you found here though:
# focus or send to the given desktop super + {_,shift + }{1-9,0} bspc {desktop -f,node -d} '^{1-9,10}'
If you don't like that behaviour/hotkey, just change it... You don't have to work around that with some hacky scripts.
> v1
Oh, you mean bspwm 1.x.y.
<code>bspwm</code> uses semantic versioning so it being 0.9.10 doesn't really mean that it is incomplete...
Most programs will refresh their configuration if you send a USR1 signal to it. But I think bspwm config is a script that can be run in the terminal when you need to refresh. So what you need to do is, run xrdrb to update the Xresources config, and run the bspwm config script to refresh everything.
Thanks! I got rounded corners working on bspwm by applying Javyre's rounded corner fork of bspwm as a patch to baskerville's master branch of bspwm. More info here :)
>should have guessed it, but as apparent, this dosnt respect the mouse focus on switching desktop, just randomly picking a non sticky window and focuses it :(
using any would do that.... you could use last..
doing a subscribe script and just recording the last focused node for refocus would probably make more sense. but honestly a quick edit to the source is easier and i think will work out better in general.
remove the sticky focus conditional in focus_node @ tree.c - here.
This is my lemonbar script.
I've tried this:
bspc subscribe report |
while read line; do
pkill -14 hjcbar.sh
done
It seems unacceptably slow. I wonder why the example lemonbar script in bspwm github can be so efficient. Do you think it is possible for me to update the bar in the way that example lemonbar script did?
I assume you're already aware that bspc outputs new lines whenever the window manager state changes. What you can do with those output lines is read them whenever they're outputted. Then, run your commands during that.
bspc subscribe | while read -r line; do echo "Output updated!" echo "New output is: $line" # do more stuff here done
I think what you're doing in your example above is similar to how piping is performed in the example lemonbar script.
That might work (though just remember to use actual named pipes, not regular files), but it's not too useful when all your piping the data from is just one program.
Named pipes are made to take input from multiple programs, from what I can tell. Then, output to one, that's why the example lemonbar script uses them. Here, where you're only receiving input from one program, I think it's overkill.
Check out Bspwm and/or Herbstluftwm. They are my personal favorites - both have shellscript as their configs which makes it easy to add to - or change - their behaviour. Both can also chance their appearance on the fly - without editing configs.
/usr/share/examples/bspwm/sxhkdrc doesn't exist for me. (usr/share/examples doesn't even exist) I did use the example from the github though.
https://github.com/baskerville/bspwm/blob/master/examples/sxhkdrc
It doesn't do it by default, but I think you could use bspwm to do this by making use of its external rules functions, it's a bit more complicated than default setups but it's quite powerful.
It's already packaged for most linux distros, although it doesn't work on wayland afaik.
I just learned that xqp can compare IDs by itself.
This is equivalent to what we figured out. ```
!/bin/sh
xqp 0 $(xdo id -N Bspwm -n root) && rofi -monitor -3 -show drun ```
FUNFACT: xqp was created to solve that focus_follow_pointer issue: baskerville's comment on a github issue about this.
It's lightweight
It comes completely unconfigured so I can make it work exactly how I want it to.
Configuration is done in any language you like, for example a you can do all your configuration with a
bashscript.It comes with no default keybinds or a bar so I can use my own.
Follows the Linux philosophy of "do one thing and do it well".
~~the option only takes true/false and then uses <code>automatic_scheme</code>s value to decide how to go about it - and~~ (not so relevant after rereading your comment) yea, automatic_scheme only has those three options. so you just want to turn if off.
i stumbled upon this issue this morning. instead of clogging up your report - and since its related to this post i'm just gonna reply here:
the window preview in rofi works fine with bspwm - it takes a 'screenshot' of the window and displays it, unlike a compositing solution that will do live previews. it will have the same issue that skippy-xd has though - it will not preview unmapped windows. so you are only going to get icons for windows on different workspaces.
i have to wonder though - how effective expose or rofi with thumbnails will be in fixing your issue. from what i've read from your examples you have many windows open. with expose those thumbnails will be very small - telling one instance of vim from another will be difficult i think. similarly rofi can have big thumbnails - but then you need to scroll around.
First make sure bspwm has been installed successfully, by running whereis bspwm, the output should contain /usr/bin/bspwm. If that's the case and the file in /usr/share/xsessions doesn't exist (for whatever reason), then type sudo nano /usr/share/xsessions/bspwm.desktop and paste the content of this file in there.
Not using Spotify myself but did you try this?
> focus_follows_pointer. However a click will make the node take precedence.
ah, yea i'm sure you could patch in raise on focus with focus_follows_pointer if you wanted (it was the behavior years ago). it might be as simple as removing this auto_raise toggle. but it is probably less annoying with the enforced click.
>It is interesting that there are only 3 layers available; at first I thought this would be limiting but I'm not sure that it is.
its 3 levels, but you still get the stacking order tiled,floating,fullscreen in each one - so it is a little more flexible then just 3.