bspwm — A tiling window manager based on binary space partitioning

Stebalien · 2013-10-08 20:58:41

Kaustic wrote:

bloom wrote:
Impossible.
ahem

You can do that:

bspc query -T > saved_layout
bspc restore -T saved_layout

However, this won't work across restarts as the window IDs, the only reliably distinct way to identify windows, will change.

However, if you don't care about potential window placement errors, you could parse the output of `bspc query -T` and record various identifying aspects of the listed windows. Then, on restart, you could use these recorded identifiers to derive the new window IDs and use them to restore the layout.

ict · 2013-10-09 12:24:58

earsplit wrote:

Another option could be to simply spawn a "null" window at some point in the tree that is just a blank transparent window with no decorations.

I'd also like to see something like this. I often find myself opening a terminal just so the window I'm actually working in does not occupy the whole screen. Having a cleaner approach to this would be nice.

F34R · 2013-10-09 15:42:40

How i convert status for bspwm only use the lemonboy bar ?
My statusbar in monsterwm statusbar_monsterwm.png?psid=1
I know this possible i finded other config use similar statusbar alike mine. here

Last edited by F34R (2013-10-09 15:43:37)

bloom · 2013-10-09 18:55:40

earsplit wrote:

One small feature reqest.

I'll see if I can comply.

earsplit · 2013-10-10 01:27:05

bloom wrote:

earsplit wrote:
One small feature reqest.
I'll see if I can comply.

Thanks!

If anyone else wants a simple transparent empty spot in the grid for now, I achieved this with this simple X code:

#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <string.h>

int main(int argc, char* argv[])
{
	Display* display = XOpenDisplay(NULL);

	XVisualInfo vinfo;
	XMatchVisualInfo(display, DefaultScreen(display), 32, TrueColor, &vinfo);


	XSetWindowAttributes attr;
	attr.colormap = XCreateColormap(display, DefaultRootWindow(display), vinfo.visual, AllocNone);
	attr.border_pixel = 0;
	attr.background_pixel = 0;

	Window win = XCreateWindow(display, DefaultRootWindow(display), 0, 0, 300, 200, 0, vinfo.depth, InputOutput, vinfo.visual, CWColormap | CWBorderPixel | CWBackPixel, &attr);
	XSelectInput(display, win, StructureNotifyMask);
	GC gc = XCreateGC(display, win, 0, 0);

	Atom wm_delete_window = XInternAtom(display, "WM_DELETE_WINDOW", 0);
	XSetWMProtocols(display, win, &wm_delete_window, 1);

	XClassHint class_hint;
	class_hint.res_name = "transparent_blank";
	class_hint.res_class = "NO_SHADOW";
	XSetClassHint(display, win, &class_hint);

	XMapWindow(display, win);


	int keep_running = 1;
	XEvent event;

	while (keep_running) {
		XNextEvent(display, &event);

		switch(event.type) {
			case ClientMessage:
				if (event.xclient.message_type == XInternAtom(display, "WM_PROTOCOLS", 1) && (Atom)event.xclient.data.l[0] == XInternAtom(display, "WM_DELETE_WINDOW", 1))
					keep_running = 0;

				break;

			default:
				break;
		}
	}

	XDestroyWindow(display, win);
	XCloseDisplay(display);
	return 0;
}

Compile with

gcc -I /usr/X11/include -L /usr/X11/lib -lX11 FILE.c -o BINARY_NAME

Last edited by earsplit (2013-10-10 01:27:24)

bloom · 2013-10-10 16:42:27

Brought by 6bc1285.

In the contrib directory, you'll find create_frame.c.

It can be compiled with:

gcc -lxcb-icccm -lxcb -o create_frame create_frame.c

Example rule:

bspc rule -a BSPWM_FRAME --frame

There are three opacity settings for frames.

earsplit · 2013-10-10 18:17:00

bloom wrote:

Brought by 6bc1285.
In the contrib directory, you'll find create_frame.c.
It can be compiled with:
gcc -lxcb-icccm -lxcb -o create_frame create_frame.c 
Example rule:
bspc rule -a BSPWM_FRAME --frame
There are three opacity settings for frames.

You are a god among men. Thanks. I'll let you know if I think of any other feature requests that I get asked about

http://paste.unixhub.net/index.php/DTVE6j/

EDIT:
Maybe one idea, make a "null" node instead of a transparent window? That way users that don't want to run compositors can maintain the same functionality. Just a thought Is there anywhere I can endorse you? I feel like I should pay you for this. I've been using bspwm every day at work for 4 months without a hiccup. This is an amazing piece of software.

Last edited by earsplit (2013-10-10 20:57:02)

Supplantr · 2013-10-10 21:10:39

This is a nice new feature. Could create_frame be added to the Makefile?
Commit 6bc1285 produces the following warning when compiling:

cc -std=c99 -pedantic -Wall -Wextra -I/usr/local/include -D_POSIX_C_SOURCE=200112L -DVERSION=\"0.8.5\" -Os  -c -o restore.o restore.c
restore.c: In function ‘restore_tree’:
restore.c:178:17: warning: implicit declaration of function ‘get_event_mask’ [-Wimplicit-function-declaration]
                 uint32_t values[] = {get_event_mask(n->client)};
                 ^

Also, thanks for adding the local modifier.

One more thing: this might be a foolish question, but how exactly are tags intended to be used?

aoba · 2013-10-11 19:47:37

I would like to make a request. It was discussed a little bit before in the context of locking windows to specific spots on the screen, but I think my request is a simpler, special case of that idea - one that hopefully can be implemented without too much effort.

I would like an option (maybe a layout?) where one window is manually flagged as "primary" or "main" or whatever keyword makes the most sense. When this is done, the window always occupies the left (or right, whichever) half of the screen, and all automatic tiling is done around it, regardless of whether or not that primary window has focus.

Copying the behavior example from github, instead of this:

              b                                   c
             / \                                 / \
            3   a              -->              4   b
            ^  / \                              ^  / \
              2   1                               3   a
                                                     / \
                                                    2   1
 +-------------------------+         +-------------------------+
 |            |            |         |            |            |
 |            |     2      |         |            |     3      |
 |            |            |         |            |            |
 |     3      |------------|   -->   |     4      |------------|
 |     ^      |            |         |     ^      |     |      |
 |            |     1      |         |            |  1  |  2   |
 |            |            |         |            |     |      |
 +-------------------------+         +-------------------------+

You would instead have this (assuming 3 is "primary"):

              b                                   c
             / \                                 / \
            3   a              -->              3   b
            ^  / \                                 / \
              2   1                               4   a
                                                  ^  / \
                                                    2   1
 +-------------------------+         +-------------------------+
 |            |            |         |            |            |
 |            |     2      |         |            |     4      |
 |            |            |         |            |     ^      |
 |     3      |------------|   -->   |     3      |------------|
 |     ^      |            |         |            |     |      |
 |            |     1      |         |            |  1  |  2   |
 |            |            |         |            |     |      |
 +-------------------------+         +-------------------------+

In other words, 3 would never, ever move as a result of automatic behavior of bspwm, but it could be manually moved/swapped with another window though an sxhkd binding, at which point that other window becomes the new "primary".

Note 1: I have not given the focus behavior any thought. Whatever makes the most sense would be fine.

Note 2: I also do not know what behavior would make the most sense when a "primary" window is the only active on on the workspace - should it fill the whole screen or just half?

The justification for this is that occasionally I find myself opening windows for short periods while working on something (including writing this, actually), and - assuming I fail to consciously take into account the layout - I get distracted moving everything back to how I want it.

My current workaround is the following (alternative suggestions are welcome):

#!/bin/bash

bspc window --focus biggest
bspc window --focus next
"$@"

but I ultimately feel that this layout idea - which would automatically handle all new windows, not just ones I manually launch with that workaround script - would be very useful to me.

bloom · 2013-10-11 22:05:16

earsplit wrote:

Maybe one idea, make a "null" node instead of a transparent window?

The problem is that, without a window to draw to, I can't provide feedbacks.

earsplit wrote:

Is there anywhere I can endorse you?

The email address given on my GitHub account is my PayPal address.

bloom · 2013-10-11 22:17:42

Supplantr wrote:

How exactly are tags intended to be used?

The tagging model is the same as in dwm.

bloom · 2013-10-11 22:33:54

aoba wrote:

I would like to make a request. It was discussed a little bit before in the context of locking windows to specific spots on the screen, but I think my request is a simpler, special case of that idea - one that hopefully can be implemented without too much effort.
I would like an option (maybe a layout?) where one window is manually flagged as "primary" or "main" or whatever keyword makes the most sense. When this is done, the window always occupies the left (or right, whichever) half of the screen, and all automatic tiling is done around it, regardless of whether or not that primary window has focus.

I have an idea:

Let's create a new node state called private.

If a node insertion is requested on a private node, the insertion will occur on the nearest public node.

aoba · 2013-10-11 23:17:23

Sounds good.

The only note I would make is that ideally - to me, anyway - that when swapping a private node with a non-private one, the private flag is traded so that the same conceptual location on the tree remains private. If that is too unintuitive/dumb/annoying-to-implement, then do not worry about it on my account because your suggestion covers 99% of what I am asking for.

PS: Thanks again

instantepiphany · 2013-10-12 05:25:23

bloom wrote:

instantepiphany wrote:
So (assuming I understand how git works and I did actually revert to that version correctly) does this mean that I screwed something else up and it isn't anything to do with some code you pushed?
It would seem so.

Hmmmm. Will poke around for a while and post back the reason if it was something anyone else might run into.

bloom · 2013-10-12 19:19:02

aoba wrote:

Sounds good.

Brought by 7334277.

aoba · 2013-10-12 20:17:51

bloom wrote:

Brought by 7334277.

This is just delightful.

Nindwen · 2013-10-13 17:40:02

bloom wrote:

Supplantr wrote:
How exactly are tags intended to be used?
The tagging model is the same as in dwm.

But what exactly is the difference between tags and desktops? Now it looks like they're additional level of hierarchy (monitor -> desktop -> tag -> window), but I'm not very sure.

Also,

earsplit wrote:

Maybe one idea, make a "null" node instead of a transparent window?

Now it looks like that if there's no tag active on desktop, and I try to create a new window, and after that activate tag on the desktop, there is this empty window/space, which can't be closed or interacted with. I suppose this is bug? example

Last edited by Nindwen (2013-10-13 17:42:05)

bloom · 2013-10-13 19:32:20

Nindwen wrote:

bloom wrote:
Supplantr wrote:
How exactly are tags intended to be used?
The tagging model is the same as in dwm.
But what exactly is the difference between tags and desktops?
Now it looks like they're additional level of hierarchy (monitor -> desktop -> tag -> window), but I'm not very sure.

Tags are just bit masks

Nindwen wrote:

Now it looks like that if there's no tag active on desktop, and I try to create a new window, and after that activate tag on the desktop, there is this empty window/space, which can't be closed or interacted with. I suppose this is bug?

Yes, and it should be fixed by 6daf058.

Thanks for reporting.

tbuck153 · 2013-10-13 19:32:48

Nindwen wrote:

bloom wrote:
Supplantr wrote:
How exactly are tags intended to be used?
The tagging model is the same as in dwm.
But what exactly is the difference between tags and desktops? Now it looks like they're additional level of hierarchy (monitor -> desktop -> tag -> window), but I'm not very sure.

That is what I've gotten out of tags so far. What I like most about them in dwm is that each desktop is basically a tag, letting me essentially view my window on any desktop/workspace by making its tag visible. It doesn't seem like that's possible with these tags unless you used them as desktops which removes the functionality you'd expect from desktops such as going to the next / prev or next / prev free or occupied.

Nindwen · 2013-10-13 20:32:40

bloom wrote:

Nindwen wrote:
bloom wrote:
The tagging model is the same as in dwm.
But what exactly is the difference between tags and desktops?
Now it looks like they're additional level of hierarchy (monitor -> desktop -> tag -> window), but I'm not very sure.
Tags are just bit masks

Thanks, I think I get it now.

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.

Or maybe I just don't understand this correctly, and my idea makes no sense at all. I don't know. Maybe I should look at your keybindings to see how tags could be used ->

kevinae91 · 2013-10-14 01:02:58

Is anyone here using firefox? If I open up a new window and open up firefox, it splits the window in two and one window has the firefox gui, and the other window is another terminal with the output code from the firefox process. Is there any way to stop that from happening? I don't want a new window to open up when I start firefox, I would prefer if it would just open up in the current window and not make any new ones.

I haven't made any changes to any of the config files, and I'm using urxvt. It also does this split-window thing if I try using xterm.

Thanks guys.

Last edited by kevinae91 (2013-10-14 01:03:25)

Kesava · 2013-10-14 01:08:06

-

Last edited by Kesava (2015-06-14 03:45:41)

bslackr · 2013-10-14 01:26:10

kevinae91 wrote:

Is anyone here using firefox? If I open up a new window and open up firefox, it splits the window in two and one window has the firefox gui, and the other window is another terminal with the output code from the firefox process. Is there any way to stop that from happening? I don't want a new window to open up when I start firefox, I would prefer if it would just open up in the current window and not make any new ones.
I haven't made any changes to any of the config files, and I'm using urxvt. It also does this split-window thing if I try using xterm.
Thanks guys.

How are you starting Firefox? It sounds like you are opening up a terminal and typing in firefox. This will absolutely cause two windows to be open, one for the terminal and one for Firefox. You should use a keybinding or something like dmenu to run Firefox instead. Or, if you are set on running it from within a terminal, you could prefix the firefox command with setsid (type 'setsid firefox' in your terminal). This will make sure the Firefox process is outside that of your terminal, so you can safely close it and Firefox will still be running.

kevinae91 · 2013-10-14 02:15:31

bslackr wrote:

kevinae91 wrote:
Is anyone here using firefox? If I open up a new window and open up firefox, it splits the window in two and one window has the firefox gui, and the other window is another terminal with the output code from the firefox process. Is there any way to stop that from happening? I don't want a new window to open up when I start firefox, I would prefer if it would just open up in the current window and not make any new ones.
I haven't made any changes to any of the config files, and I'm using urxvt. It also does this split-window thing if I try using xterm.
Thanks guys.
How are you starting Firefox? It sounds like you are opening up a terminal and typing in firefox. This will absolutely cause two windows to be open, one for the terminal and one for Firefox. You should use a keybinding or something like dmenu to run Firefox instead. Or, if you are set on running it from within a terminal, you could prefix the firefox command with setsid (type 'setsid firefox' in your terminal). This will make sure the Firefox process is outside that of your terminal, so you can safely close it and Firefox will still be running.

Good stuff. I don't have a panel installed either so opening up firefox through the terminal was really the only thing I could think of. I will try both of those suggestions. Thanks!

robstwd · 2013-10-14 08:55:16

kevinae91 wrote:

Good stuff. I don't have a panel installed either so opening up firefox through the terminal was really the only thing I could think of. I will try both of those suggestions. Thanks!

Other options that work really well are:

1. Set up a specific keybinding for firefox.
- assuming that you are using sxhkd
- edit your sxhkdrc to add a keybinding of your choice; mine is:

alt + f
    firefox

- make sxhkd reload its configuration files using the following at a terminal:

pkill -USR1 -x sxhkd

- then pressing alt & f together should launch firefox
- (note that you will need to have a unique keybinding, ie alt + f can't be used for something else)

2. Use a application launcher like dmenu
- info on wiki here here
- install & set up keybinding as per example above; mine is

Menu
    dmenu_run -fn '-*-*-medium-r-normal-*-*-*-*-*-*-100-*-*' -p 'run'

- reload sxhkd settings & run dmenu using the new keybinding
- at the dmenu prompt type fir and firefox has likely been highlighted; hit enter
- (what you type at the dmenu prompt may vary depending on what other things you have installed that start with "fi...")

Last edited by robstwd (2013-10-14 09:20:50)

Arch Linux

#751 2013-10-08 20:58:41

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

#752 2013-10-09 12:24:58

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

#753 2013-10-09 15:42:40

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

#754 2013-10-09 18:55:40

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

#755 2013-10-10 01:27:05

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

#756 2013-10-10 16:42:27

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

#757 2013-10-10 18:17:00

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

#758 2013-10-10 21:10:39

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

#759 2013-10-11 19:47:37

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

#760 2013-10-11 22:05:16

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

#761 2013-10-11 22:17:42

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

#762 2013-10-11 22:33:54

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

#763 2013-10-11 23:17:23

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

#764 2013-10-12 05:25:23

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

#765 2013-10-12 19:19:02

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

#766 2013-10-12 20:17:51

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

#767 2013-10-13 17:40:02

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

#768 2013-10-13 19:32:20

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

#769 2013-10-13 19:32:48

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

#770 2013-10-13 20:32:40

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

#771 2013-10-14 01:02:58

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

#772 2013-10-14 01:08:06

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

#773 2013-10-14 01:26:10

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

#774 2013-10-14 02:15:31

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

#775 2013-10-14 08:55:16

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

Board footer