bspwm — A tiling window manager based on binary space partitioning

vloiki · 2013-10-14 11:19:29

One small request: could the example files also include multi-monitor support?

I am trying to set up a second monitor and it's rather confusing.

bloom · 2013-10-14 11:55:46

Nindwen wrote:

However, I'm still not sure how they'd be best used with bspwm. If I understand correctly, currently I can't show same windows on multiple desktops. Wouldn't the whole idea make more sense if each desktop created its own tag on creation, and the tag would show the same windows in every desktop? Or in other words, desktop would only be the layout of windows and tags defined which windows are shown. This way, you could use desktops as simple containers for tags, but also use power of tags more freely.

Currently, tags are at the experimental stage.

I didn't want to make a complete conceptual overhaul unless I'm certain that everything will work as expected.

I do agree that we don't need two mechanisms for hiding/showing a set of windows. And therefore, the next step would be to merge the desktop concept into the monitor concept (and have one tree per monitor). This would simplify some of the features (e.g.: sticky windows would just have a full tags field). But there are still open problems (e.g.: how am I supposed to restrain tree rotation to the visible nodes?).

Last edited by bloom (2013-10-15 19:57:28)

robstwd · 2013-10-14 12:50:19

vloiki wrote:

One small request: could the example files also include multi-monitor support?
I am trying to set up a second monitor and it's rather confusing.

I have a multi monitor-setup, pretty basic but I'm happy, thanks to various tidbits gleaned from this thread and the bspwm mailing list help from bloom. I have 2 monitors, the main 1920x1080 DVI and the secondary 1280x1024 VGA.

The relevant bits of .xinitrc are:

# set up dual monitors
xrandr --output DVI-I-1 --primary
xrandr --output VGA-0 --auto --left-of DVI-I-1

my bspwmrc contains (apart from the usual rules & settings...):

# VGA monitor (#1)
bspc monitor ^1 --reset-desktops a b c         # arbitrary labels for 3 desktops on the left-hand VGA monitor
bspc config -m ^1 top_padding 10

# DVI monitor (#2)
bspc monitor ^2 --reset-desktops 1 2 3 4 5         # arbitrary labels for 5 desktops on the right-hand DVI monitor
bspc config -m ^2 top_padding 10

# move the focus to the main monitor
bspc monitor -f primary

# start panel script
panel &

the relevant bits of panel script are:

bspc control --put-status

xtitle -sf 'T%s' > "$PANEL_FIFO" &
clock -sf 'S%Y-%m-%d %H:%M' > "$PANEL_FIFO" &

cat "$PANEL_FIFO" | panel_bar | bar &

Note that I am piping the output of panel_bar script into LemonBoy's bar, that has been compiled for Xinerama support, using

make XINERAMA=1

And finally, the (almost standard) panel_bar script is

while read -r line ; do
    case $line in
        S*)
            # clock output
            sys_infos="\\r${line#?}"
            ;;
        T*)
            # xtitle output
            title=" ${line#?}"
            ;;
        W*)
            # bspwm internal state
            wm_infos=""
            IFS=':'
            set -- ${line#?}
            while [ $# -gt 0 ] ; do
                item=$1
                name=${item#?}
                name2=" $name "
                case $item in
                    O*)
                        # focused occupied desktop
                        wm_infos="$wm_infos \\u5\\b2\\f5${name2}\\ur\\br\fr"
                        ;;
                    F*)
                        # focused free desktop
                        wm_infos="$wm_infos \\u2\\b2\\f5${name2}\\ur\\br\fr"
                        ;;
                    U*)
                        # focused urgent desktop
                        wm_infos="$wm_infos \\u9\\br\\fr${name2}\\ur\\br\fr"
                        ;;
                    o*)
                        # inactive but occupied desktop
                        wm_infos="$wm_infos \\b8\\u5${name2}\\ur\\br"
                        ;;
                    f*)
                        # free desktop ie inactive
                        wm_infos="$wm_infos ${name2}"
                        ;;
                    u*)
                        # urgent desktop
                        wm_infos="$wm_infos \\b3\\f0${name2}\\fr\\br"
                        ;;
                    L*)
                        # layout
                        layout=$(printf "%s" "${name}" | sed 's/\(.\).*/\U\1/')
                        wm_infos="$wm_infos  \\f7[\\fr $layout \\f7]\\fr "
                        ;;
                    [Mm]*)
                        # monitor
                        if [ "$name" =  "DVI-I-1" ] ; then
                            wm_infos="$wm_infos \\s1"                          # move the main information to the 2nd monitor
                        fi
                        ;;
                esac
                shift
            done
            ;;
    esac
    printf "%s\n" "$wm_infos $title $sys_infos"
done

This is basically the example panel_bar with a little bit of tweaking as kindly assisted by bloom. See the case statement section beginning with [Mm]*) - this allows for the VGA monitor to just display its 3 desktops ("a b c") and all the rest from the 5 DVI desktops on the DVI monitor, along with window title and date/time. According to bar's documentation the "\\s1" switches to screen #1 (VGA is screen #0). So far, my bar info is just the window title and date/time - I do have plans to add to this when time permits. And I'm sure that I can take better advantage of bar's xinerama support somehow, but as a work in progress it may be of some help to get you started ....
(And the hackish "name" expansion to "name2" is my doing - to expand the background block of colour behind each desktop label.)

Last edited by robstwd (2013-10-14 12:52:08)

chickenPie4tea · 2013-10-14 14:01:30

I dont understand why wm's dont come with a basic panel already set up to work out of the box. UNLESS it is specifically the aim of the WM to be very basic and not have a panel option.
After all it is much kinder to the user to have one set up and if you dont want a panel then I imaging it is a much easier task to
disable one than to set one up from scratch. There could be something in the documentation on what lines to comment out if you want to disable panel.
I have found bspwm to one of the most difficult to set up - I couldn't get a panel going so in the end jsut startup up tint2 that I had from openbox and that is working.

agahnim · 2013-10-14 14:45:19

chickenPie4tea wrote:

I dont understand why wm's dont come with a basic panel already set up to work out of the box. UNLESS it is specifically the aim of the WM to be very basic and not have a panel option.
After all it is much kinder to the user to have one set up and if you dont want a panel then I imaging it is a much easier task to
disable one than to set one up from scratch. There could be something in the documentation on what lines to comment out if you want to disable panel.
I have found bspwm to one of the most difficult to set up - I couldn't get a panel going so in the end jsut startup up tint2 that I had from openbox and that is working.

I want to try to get one of the panels working myself, but I haven't had a lot of time to figure it out. I just use Conky myself, and I am seriously considering just keeping my Conky panel.

Supplantr · 2013-10-14 16:59:23

chickenPie4tea wrote:

UNLESS it is specifically the aim of the WM to be very basic and not have a panel option.

This applies to bspwm:

bloom wrote:

There will never be a built-in panel because it would violate one of the UNIX design principles.

Very comprehensive example panel scripts targeting both bar and dzen2 are provided. The internal state format is documented. What's the problem?

chickenPie4tea · 2013-10-15 07:39:11

Agahnim said "I want to try to get one of the panels working myself, but I haven't had a lot of time to figure it out"
I doubt it is just me and him that find it difficult.
Yes I saw some nice examples of panels but SETTING it up is the problem. It was a couple of days ago that I was trying so can't remember all the things i tried - I just gave up.
So ok if the aim is to not set one up as default - it just means folk like me have to move on in frustration and not use bspwm.

ict · 2013-10-15 09:50:26

chickenPie4tea wrote:

it just means folk like me have to move on in frustration and not use bspwm.

.. or put tint2 in the autostart, click some buttons in tint2conf to configure it to your liking and enjoy the wm. Like I do.

Clickable workspaces, clickable programs, integrated tray. And if I decide to switch to another (EWMH-compatible) WM, I can keep on using it. That's the beauty of the *nix-philosophy.

Last edited by ict (2013-10-15 09:54:19)

agahnim · 2013-10-16 22:48:21

This is a question mainly aimed at bloom. I do not know if this has been asked before, but what are your plans for the move to Wayland? Do you plan on adding support once Wayland becomes standard, or rather becomes more common place? I love this window manager, and have found that I cannot even use a normal DE anymore. I am hoping that things like this that are accessible and also very functional will continue to be available in the future once Wayland is widely adopted. I am a convert through and through. I do not use this because I need to save resources, but because it is a fantastic method of using my desktop, which I find to be far superior. Thank you for making tiling more accessible and more functional, and I hope to see more in the future.

sardina · 2013-10-17 09:10:38

A request:

can we have a drop-down feature, Quake style? Like Guake or Yakuake, but for every type of client, just as awesome-scratchdrop does. This is fundamental for a lot of people, and I think it would be useful to even more people if integrated.

ict · 2013-10-17 09:54:34

Calling the set function on a client it is automatically centered on screen and set floating
Client also assumes other properties, of which size, sticky and screen are all controllable
Calling the toggle function client is hidden, or shown, depending on its state when scratch is not empty
Calling the set function on a scratched client will un-scratch it, and calling it on another client will replace the scratch

Sounds like this could be implemented with some keybinds and a simple script.

sardina · 2013-10-17 10:23:13

I'd like to have it as a config to set in sxhkdrc, if it's not trivial.

Like this:

super + z
   bspc toggle scratchdrop MyClient --top

Last edited by sardina (2013-10-17 10:28:58)

Supplantr · 2013-10-17 21:29:35

Scratchpad functionality can be emulated with:

xdotool search --onlyvisible --classname scratchpad windowunmap \
|| xdotool search --classname scratchpad windowmap \
|| st -c scratchpad -g 1000x400+460 &

and a rule:

bspc rule -a scratchpad --sticky

As an aside, would it make more sense for a sticky window to retain focus when changing desktops?

sardina · 2013-10-18 11:22:52

What is "st"?

Earnestly · 2013-10-18 11:42:34

It’s a terminal emulator

evilzer · 2013-10-18 23:44:27

Does anyone else had all floating windows appear below tiled ones?
I skimmed thorugh the manual but could not find anything relating to it. Seems to happen when you toggle between monocle / fullscreen view much.

Also is there a way to get active window_gap and border_width through bspc?
I want add a key to add N of steps to active value.
This returns an error

bspc config window_gap

while

bspc config normal_border_color
#222222

works fine.

Or is there another way to do this?

instantepiphany · 2013-10-19 04:49:46

After trying to troubleshoot my problem(windows resize slowly, incredibly slowly with a compositor running, still slow without, I posted a couple pages back), I still haven't found an answer.
I have however noticed a few things:

1. resizing 2 applications I would consider to be "gui heavy" such as chromium with a busy webpage open, and teamspeak3, is not as painful as;
2. resizing 2 urxvt windows full of text (after doing ls -al of ~ for example) is incredibly slow, maybe because as I resize them the text inside them is constantly recomputed to display inside the newly sized window? Empty terminals are much better, but still worse than chromium + teamspeak3.
3. 2 empty xterm windows are incredibly slow to resize. For example resizing 2 xterms that are occupying 1/2 of the screen each so they occupy 2/3 and 1/3 takes close to 10 seconds, with lots of flicking and the border/gap between them jumping around.
4. Switching desktops with compton running is really smooth and pleasant.

Bloom, what did you use to record your video showcasing bspwm 0.1 on vimeo? I might record my problems and upload a video.
Video is here. Simplescreenrecorder is a great tool!

Last edited by instantepiphany (2013-10-19 06:07:58)

bloom · 2013-10-19 09:45:28

instantepiphany wrote:

After trying to troubleshoot my problem(windows resize slowly, incredibly slowly with a compositor running, still slow without, I posted a couple pages back), I still haven't found an answer.

It might have been useful to have a sticky floating terminal window with top running in it during your screencast.

What's your wallpaper setter?

Have you tried with a minimal .xinitrc and empty .Xresources?

Last edited by bloom (2013-10-19 09:46:20)

instantepiphany · 2013-10-19 13:11:42

bloom wrote:

It might have been useful to have a sticky floating terminal window with top running in it during your screencast.

Yeah, in hindsight that would have been smart. When I did it before the video I had top open, and when resizing terminal windows, X was close to 100% of cpu time. When resizing chromium, chromium was using around 70%, I guess because chromium handles redrawing of the web content.

bloom wrote:

What's your wallpaper setter?
Have you tried with a minimal .xinitrc and empty .Xresources?

I use "bash ~/.fehbg &" in ~/.xinitrc.
Will try with a minimal .xinitrc (just making the panel_fifo, starting sxhkd and bspwm should be fine, correct?) and empty .Xresources and post back.

shmibs · 2013-10-19 14:11:53

Feature Request: could 'bspc rule' be made a bit more robust? particularly, i mean being able to select clients by more than just class and name. allowing type in particular makes writing generic rules much easier, with rules applicable to everything of type "normal", "desktop", "splash", "dock", etc.

thanks

bloom · 2013-10-19 15:58:26

evilzer wrote:

Does anyone else had all floating windows appear below tiled ones?
Seems to happen when you toggle between monocle / fullscreen view much.

I'd be grateful if you could provide simple steps to reproduce.

bloom · 2013-10-19 16:00:25

shmibs wrote:

Feature Request: could 'bspc rule' be made a bit more robust? particularly, i mean being able to select clients by more than just class and name. allowing type in particular makes writing generic rules much easier, with rules applicable to everything of type "normal", "desktop", "splash", "dock", etc.

Could you provide a rule example involving the window type?

The aforementioned window types are currently handled by implicit rules.

Last edited by bloom (2013-10-19 16:09:25)

aoba · 2013-10-19 17:18:36

More floating window weirdness:

This is not necessarily a problem with bspwm, but still a little weird and does not occur in, e.g. Openbox. When I start a simple GLUT program and set it to floating mode (whether with a keybind or beforehand with `bspc rule`), it appears to vanish from the screen. What actually happens - and I have no idea how I noticed this - is the window is moved almost entirely off-screen, with the exception of its top-left pixel, which appears in the bottom-right corner of my screen.

This is a minimal-ish program that should illustrate the problem:

#include <GL/glut.h>

void display()
{
	glClearColor(0.0f, 0.5f, 1.0f, 0.0f);
	glClear(GL_COLOR_BUFFER_BIT);
	glutSwapBuffers();
}

void keyboard(unsigned char key, int x, int y)
{
	exit(0);
}

int main(int argc, char** argv) {
	glutInit(&argc, argv);
	glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGBA | GLUT_DEPTH);
	glutCreateWindow("i will be invisible");
	glutKeyboardFunc(keyboard);
	glutDisplayFunc(display);

	glutMainLoop();

	return 0;
}

It requires extra/freeglut and linking with -lglut -lGL.

It is possibly worth noting that the `xprop` output for this window is minimal:

_NET_WM_DESKTOP(CARDINAL) = 1
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW
WM_LOCALE_NAME(STRING) = "C"
WM_HINTS(WM_HINTS):
		Initial state is Normal State.
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		user specified size: 300 by 300
WM_CLIENT_MACHINE(STRING) = "ohana"
WM_ICON_NAME(STRING) = "i will be invisible"
WM_NAME(STRING) = "i will be invisible"

shmibs · 2013-10-19 17:33:32

bloom wrote:

shmibs wrote:
Feature Request: could 'bspc rule' be made a bit more robust? particularly, i mean being able to select clients by more than just class and name. allowing type in particular makes writing generic rules much easier, with rules applicable to everything of type "normal", "desktop", "splash", "dock", etc.
Could you provide a rule example involving the window type?
The aforementioned window types are currently handled by implicit rules.

in my awesome config, i had the following two rules:

{ rule = { type = "desktop" },
  properties = { border_width = 0,
                 sticky = true,
                 focusable = false,
                 focus = false,
                 floating = true } },

and

{ rule = { type = "splash" },
  properties = { border_width = 0,
                 floating = true,
                 ontop = true } },

evilzer · 2013-10-19 17:57:04

bloom wrote:

I'd be grateful if you could provide simple steps to reproduce.

Well it have only happen about 2-3 times and I dont know how to reproduce thats why I asked if anyone else had the problem or if it might be some on my system.

But when it happend last time I did notice some things,
1, Only happens on affected desktop, if you spawn a floating on another it does not occur there, but if you move it do affected desktop it does.
2. The reason i think it have something to do with fullscreen view is that when it happens after messing around with it for a while one window suddenly pops up in fullscreen and when you close it the problem dissapear. I dont remeber if this window was visible on the desktop while the symptons where there.

Seems to me like one window gets stuck in fullscreen view when you push it back to tiled, floating or whatever.
But I just started using bspwm so if it happens again got any tips on what to check / test to help identify the problem?

Arch Linux

#776 2013-10-14 11:19:29

Re: bspwm — A tiling window manager based on binary space partitioning

#777 2013-10-14 11:55:46

Re: bspwm — A tiling window manager based on binary space partitioning

#778 2013-10-14 12:50:19

Re: bspwm — A tiling window manager based on binary space partitioning

#779 2013-10-14 14:01:30

Re: bspwm — A tiling window manager based on binary space partitioning

#780 2013-10-14 14:45:19

Re: bspwm — A tiling window manager based on binary space partitioning

#781 2013-10-14 16:59:23

Re: bspwm — A tiling window manager based on binary space partitioning

#782 2013-10-15 07:39:11

Re: bspwm — A tiling window manager based on binary space partitioning

#783 2013-10-15 09:50:26

Re: bspwm — A tiling window manager based on binary space partitioning

#784 2013-10-16 22:48:21

Re: bspwm — A tiling window manager based on binary space partitioning

#785 2013-10-17 09:10:38

Re: bspwm — A tiling window manager based on binary space partitioning

#786 2013-10-17 09:54:34

Re: bspwm — A tiling window manager based on binary space partitioning

#787 2013-10-17 10:23:13

Re: bspwm — A tiling window manager based on binary space partitioning

#788 2013-10-17 21:29:35

Re: bspwm — A tiling window manager based on binary space partitioning

#789 2013-10-18 11:22:52

Re: bspwm — A tiling window manager based on binary space partitioning

#790 2013-10-18 11:42:34

Re: bspwm — A tiling window manager based on binary space partitioning

#791 2013-10-18 23:44:27

Re: bspwm — A tiling window manager based on binary space partitioning

#792 2013-10-19 04:49:46

Re: bspwm — A tiling window manager based on binary space partitioning

#793 2013-10-19 09:45:28

Re: bspwm — A tiling window manager based on binary space partitioning

#794 2013-10-19 13:11:42

Re: bspwm — A tiling window manager based on binary space partitioning

#795 2013-10-19 14:11:53

Re: bspwm — A tiling window manager based on binary space partitioning

#796 2013-10-19 15:58:26

Re: bspwm — A tiling window manager based on binary space partitioning

#797 2013-10-19 16:00:25

Re: bspwm — A tiling window manager based on binary space partitioning

#798 2013-10-19 17:18:36

Re: bspwm — A tiling window manager based on binary space partitioning

#799 2013-10-19 17:33:32

Re: bspwm — A tiling window manager based on binary space partitioning

#800 2013-10-19 17:57:04

Re: bspwm — A tiling window manager based on binary space partitioning

Board footer