bspwm — A tiling window manager based on binary space partitioning

Neuromatic · 2013-07-15 13:54:10

Stebalien wrote:

Somewhere before you start bspwm?

mkfifo is called in the panel_test.sh. There is a

 [[ -p $PANEL_FIFO ]] || mkfifo -m 600 "$PANEL_FIFO"

Have I write this in the .xinitrc?

I restarted bspwm a few times, when I changed the panel script. The fifo is therefore already available.

Neuromatic · 2013-07-15 14:16:21

Sorry for the double post, but I wrote

 [[ -p $PANEL_FIFO ]] || mkfifo -m 600 "$PANEL_FIFO"

in the .xinitrc now, and now the bspwm-information is now in the FIFO. Thank you guys.

Another issue: Yesterday I tryed to subscribe your mailing list. But my Mail-Provider says that no Mail-Service existing on bspwm at librelist dot com. Is the mailing list canceled?

bloom · 2013-07-15 19:41:09

Neuromatic wrote:

Is the mailing list canceled?

No it isn't.

bloom · 2013-07-16 08:24:22

Regarding tags: it is in fact possible to implement tags via the vacant state mechanism.

Vacant nodes as used to prevent floating windows from leaving holes in the layout. The property propagates from the leaves to the root: when brother nodes are vacant their parent becomes vacant and so on...

I can then think of only two approaches to tagging:

Make a complete transition from desktops to tags: it would mean to have one tree per monitor and to loose support for EWMH desktops.
Tags on top of desktops: each desktop (and each node) would have a bit field tags property.

Supplantr · 2013-07-16 12:10:48

Stebalien wrote:

When combined with '-d <desktop>', focus the desktop if it isn't the current (follow the window to its desktop).

Thanks. Maybe the documentation should instead read: -a, --add <pattern> [-d DESKTOP_SEL [--follow]] [--floating]

bloom wrote:

Make a complete transition from desktops to tags: it would mean to have one tree per monitor and to loose support for EWMH desktops.
Tags on top of desktops: each desktop (and each node) would have a bit field tags property.

My initial thought is: "one tree per monitor" seems like it would be a step backwards.
Could you expound both of these approaches a bit?

---

Would it be possible to add an urgent modifier to the window command?
[edit] I guess if this were added it would also be to the desktop command.

Lastly, when the rule Skype -d DESK exists and Skype's "file transfer" window is spawned, DESK is automatically focused. I'm not sure wherein lies the problem, so I'll try to investigate further.

Last edited by Supplantr (2013-07-16 12:17:18)

Sirsurthur · 2013-07-18 07:06:02

Regarding the locked windows, by purpose, they can not be closed. I was wondering if they should as well stay as the same location in the desktop/monitor, even when spawning new clients (especially in automatic mode) ? Should the locked windows stay visible even when --toggle-visibility option is activated ?

milomouse · 2013-07-18 21:29:21

Sirsurthur wrote:

Regarding the locked windows, by purpose, they can not be closed. I was wondering if they should as well stay as the same location in the desktop/monitor, even when spawning new clients (especially in automatic mode) ? Should the locked windows stay visible even when --toggle-visibility option is activated ?

I really like this idea. I lock windows all the time and it would be great for them to keep their geometry/position if new windows are opened around it. I don't really mind about --toggle-visibility but it may be helpful sometimes, perhaps with an optional --toggle-visibility --locked or something like that.

bloom · 2013-07-19 08:33:17

Supplantr wrote:

Would it be possible to add an urgent modifier to the window command?

Brought by 7606b0b.

bloom · 2013-07-19 09:05:30

milomouse wrote:

Sirsurthur wrote:
Regarding the locked windows, by purpose, they can not be closed. I was wondering if they should as well stay as the same location in the desktop/monitor, even when spawning new clients (especially in automatic mode) ?
I really like this idea. I lock windows all the time and it would be great for them to keep their geometry/position if new windows are opened around it.

Keeping the position/geometry of a tiled window constant might be tricky: how would the window react to --flip, --rotate, etc.?

Sirsurthur · 2013-07-19 17:34:13

Maybe the position/geometry of the tiled window should stay " as constant as possible ", even when flip and rotate are used ?

milomouse · 2013-07-19 20:53:28

There could be a compromise; say only check for "locked window" size and position when opening new windows, and let the user --flip, --rotate, etc. if desired.

I realize it may be tricky when "swapping" windows, now that I think about it. Since the locked window is probably not the same size as the target window and everything will need to be "rebalanced" around it once swapped.

Sirsurthur · 2013-07-20 12:18:22

I agree with this proposal ; maybe we could say that the location / geometry of a locked window could be kept for automatic tiling but not when user wants to perform a specific action (flip, rotate, swap, etc.) ?

bloom · 2013-07-20 13:10:24

Sirsurthur wrote:

I agree with this proposal ; maybe we could say that the location / geometry of a locked window could be kept for automatic tiling but not when user wants to perform a specific action (flip, rotate, swap, etc.) ?

What you're after is a kind of attach aside automatic mode triggered by specific windows?

Sirsurthur · 2013-07-20 14:01:22

Yes definately, it looks like it, but a function that would concern all locked windows.

bloom · 2013-07-21 19:16:52

Ensuring that no locked windows are affected by the insertion of a new window at a window in automatic mode would require to solve a constraint satisfaction problem.

Almehdin · 2013-07-23 15:21:47

When trying to make predefined desktops.. I am wondering if I am doing it right or if there are a better way.

Right now this is how I do it in autostart:

## Predefined desktop 3
urxvtc -name URthree && vlc &
sleep 3 && urxvtc -name rtorrent -e rtorrent

_______________
|rtorrent | vlc |
| | |
| |________|
| | urxvt |
|______|________|

I am wondering if it is possible to get this without the 'sleep' command. I had to put it there as Vlc takes longer to start
than the other two. I am also wondering if I can select a predefined size for a window. I don't want to put in multiple
'bspc window -e left push' in the config file. It would be better if I could do 'bspc window -r 50 -e left push' or something
similar.

Last edited by Almehdin (2013-07-23 15:22:20)

Stebalien · 2013-07-23 16:18:57

For the first part, why not just start vlc later:

urxvtc -name rtorrent -e rtorrent
#presel right
bspc window -p right
urxvtc -name URthree
#presel up
bspc window -p up
vlc &

For the second part, `bspc window -e left RATIO` should work. However, if you are already using presel, you could just add `-r RATIO` flags to the presel commands.

Last edited by Stebalien (2013-07-23 16:20:34)

bloom · 2013-07-23 17:29:15

Almehdin wrote:

bspc window -r 50 -e left push or something similar.

Probably:

bspc window -e left 0.5

Almehdin · 2013-07-24 14:45:34

Thanks a lot guys. Didn't think the ratio should be percentage but pixels.. so that was why I couldn't get it yo work. Understand now how it works.

I used the '&&' so it would finish the first command before launching the next one and then the sleep. I knew there would be another more clean way
but couldn't figure it out.

Maybe examples like this should be documented somewhere so mortals like me can find it and understand the syntaxes better..
Anyway, great job so far.

Last edited by Almehdin (2013-07-24 14:46:31)

Almehdin · 2013-07-24 17:01:38

I tired this..

urxvtc -name rtorrent -e rtorrent
bspc window $(bspc query -W -d 3) -p right
urxvtc -name URthree
bspc window $(bspc query -W -d 3|tail -1) -p up
vlc &
bspc window $(bspc query -W -d 3|tail -1) -e left 0.4
bspc window $(bspc query -W -d 3|tail -1) -e up 0.7

Even though it looks more pure it doesn't work because of the race condition. If I run from terminal it works but not from the autostart as everything
seems to be executed the same time and not sequential like a bash script.

ict · 2013-07-26 21:48:56

Hi,

I'm contemplating changing from i3 to bspwm and I like it a lot so far. But I can't seem to get conky to draw to the background and not all over my windows.

What settings do I need to use here?
I tried own_window no and various combinations of own_window yes and window_type {widget,dock,override,desktop}, but it either gets put in its own tiled window or overlaps everything else.
Is it possible?

Thanks

bloom · 2013-07-27 19:04:04

ict wrote:

Is it possible?

No.

It's due to the rough approach I've taken for the implementation of the z-order.

bloom · 2013-07-29 08:32:44

The default configuration file is now: ${XDG_CONFIG_HOME}/bspwm/bspwmrc.

The path of the configuration file can now be specified via bspwm's -c option.

ict · 2013-07-29 12:59:08

bloom wrote:

No.
It's due to the rough approach I've taken for the implementation of the z-order.

OK thanks, it's not a big deal.
Still, do you have plans to support this one day?

Supplantr · 2013-07-30 04:21:16

Three things I've noticed:

bspc {restore,control,pointer,rule} don't exit with status 1 when called without options, while the other commands do.
When bspc rule -a fails (and no rule is actually added), the UID counter is still incremented.
In the documentation for WINDOW_SEL, the automatic and manual modifiers are missing.

Just wondering, has any more thought been put into/progress been made regarding the possible tagging implementations?

Arch Linux

#376 2013-07-15 13:54:10

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

#377 2013-07-15 14:16:21

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

#378 2013-07-15 19:41:09

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

#379 2013-07-16 08:24:22

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

#380 2013-07-16 12:10:48

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

#381 2013-07-18 07:06:02

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

#382 2013-07-18 21:29:21

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

#383 2013-07-19 08:33:17

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

#384 2013-07-19 09:05:30

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

#385 2013-07-19 17:34:13

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

#386 2013-07-19 20:53:28

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

#387 2013-07-20 12:18:22

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

#388 2013-07-20 13:10:24

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

#389 2013-07-20 14:01:22

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

#390 2013-07-21 19:16:52

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

#391 2013-07-23 15:21:47

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

#392 2013-07-23 16:18:57

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

#393 2013-07-23 17:29:15

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

#394 2013-07-24 14:45:34

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

#395 2013-07-24 17:01:38

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

#396 2013-07-26 21:48:56

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

#397 2013-07-27 19:04:04

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

#398 2013-07-29 08:32:44

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

#399 2013-07-29 12:59:08

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

#400 2013-07-30 04:21:16

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

Board footer