herbstluftwm

mentat · 2012-01-04 15:42:45

Maybe one day the frame will be full transparency compatible
Thx for all Thorsten.

edit: for now I use conky to replace root-tail and it's work like a charm ^_^

Last edited by mentat (2012-01-05 10:59:15)

bloom · 2012-01-10 11:42:49

Can you add a focus_changed WINID hook?

Last edited by bloom (2012-01-10 11:45:04)

thorsten · 2012-01-10 16:42:31

bloom wrote:

Can you add a focus_changed WINID hook?

I will add it quite soon.

thorsten · 2012-01-10 21:22:28

thorsten wrote:

bloom wrote:
Can you add a focus_changed WINID hook?
I will add it quite soon.

I added it. But it only is emited if the focus changes (and not if the window title changes). The window_title_changed hook needs some more time i currently don't have

bloom · 2012-01-11 12:44:33

thorsten wrote:

thorsten wrote:
bloom wrote:
Can you add a focus_changed WINID hook?
I will add it quite soon.
I added it. But it only is emited if the focus changes (and not if the window title changes).
The window_title_changed hook needs some more time i currently don't have

That's what I thought after having posted the request, I should have edited my post, sorry.

bloom · 2012-01-14 13:27:12

Windows should to have two borders instead of one:

Disregarding the chosen active border color, there will be windows whose background color is close enough to make the active border nearly invisible.
Hence, a second border must be inserted between the boundary of the window and the existing one.
That way, a constant contrast between the outer and the inner border can be achieved.

Last edited by bloom (2012-01-14 17:17:55)

kcirick · 2012-01-14 17:16:02

Hello,

I just started using HLWM and I have to say I really like it. I was looking for a good mix of dwm and i3, and HLWM really is the best of both worlds. I like how I can customize the status bar using herbstclient, and I still feel like there are lot of things I can tweak around. The source code doesn't seem too scary either, but I haven't had a reason to go into it thus far.

One thing I still need to figure out is multiple-monitor configuration. I will be sure to ask about it here if I come across any issues :-). It would def. be nice for HL to support randr, I think...

thorsten · 2012-01-14 17:34:27

bloom wrote:

Windows should have two borders instead of one, here's why:
Whatever the chosen active border color, there will be windows whose background color is close enough to make the active border nearly invisible.
Hence a second border must be inserted between the boundary of the window and the existing one.
The color of this inner border should accomplish the proper (constant) contrast with the outer border.

I'll think about it. But in my opinion, there are some arguments against a double border:

you already can setup a double border by setting window-border and a frame-border
to give double border to a window, i would have to implement window-decorations (incl. reparenting windows). And I'm not sure if this is the right thing for hlwm. Maybe there will be such an option, maybe not.
It can be fixed with some applications which support an own frame around the content (e.g. urxvt, maybe Qt with QtCurve-Style)

And maybe an option (i.e. rule-condion) like a application-specific window border color would suit better. What do you think?

thorsten · 2012-01-14 17:44:23

kcirick wrote:

I just started using HLWM and I have to say I really like it. I was looking for a good mix of dwm and i3, and HLWM really is the best of both worlds. I like how I can customize the status bar using herbstclient, and I still feel like there are lot of things I can tweak around. The source code doesn't seem too scary either, but I haven't had a reason to go into it thus far.

Cool, thanks

kcirick wrote:

One thing I still need to figure out is multiple-monitor configuration. I will be sure to ask about it here if I come across any issues :-). It would def. be nice for HL to support randr, I think...

You can setup the multiple-monitor configuration manually by calling the add_monitor and move_monitor. It is completely independent from xrandr, xinerama, ... There will be a setup_monitors_by_xrandr command in the future, but it is actually not really needed (it's just candy...).

Most users have their own multimonitor-scripts bound to a key which are doing both xrandr --output ... and herbstclient add_monitor; so it is very comfortable if you attach and detach an external screen (e.g. a video projector) very often.

bloom · 2012-01-14 20:02:41

thorsten wrote:

bloom wrote:
Windows should have two borders instead of one, here's why:
Whatever the chosen active border color, there will be windows whose background color is close enough to make the active border nearly invisible.
Hence a second border must be inserted between the boundary of the window and the existing one.
The color of this inner border should accomplish the proper (constant) contrast with the outer border.
I'll think about it. But in my opinion, there are some arguments against a double border:
you already can setup a double border by setting window-border and a frame-border
to give double border to a window, i would have to implement window-decorations (incl. reparenting windows). And I'm not sure if this is the right thing for hlwm. Maybe there will be such an option, maybe not.
It can be fixed with some applications which support an own frame around the content (e.g. urxvt, maybe Qt with QtCurve-Style)

Not exactly, because frame borders are surrounding frames not windows and active/inactive window borders have to be outer, not inner.
I didn't know about that, what are the disadvantages of reparenting?
I would prefer to solve the problem in the general case.

thorsten wrote:

And maybe an option (i.e. rule-condion) like a application-specific window border color would suit better. What do you think?

It wouldn't work because some applications (e.g. web browsers) have a dynamic background.
Thanks for taking the time to consider the problem.

Last edited by bloom (2012-01-15 10:43:19)

thorsten · 2012-01-14 20:17:48

bloom wrote:

Not exactly, because frame borders are surrounding frames not windows and active/inactive window borders have to be outer, not inner.
I didn't know about that, what are the disadvantages of reparenting?
I would prefer to solve the problem in the general case.

The disadvantage of reparenting is: It's more work. hlwm has to create a decoration window and has to place the client-window within this decoration and has to draw the content of the decoration window. With only one border, it is easier: hlwm tells X the border width and border color and that's all. (That's just the reason why there is no few-lines-patch with a quick fix for this feature request)

bloom wrote:

thorsten wrote:
And maybe an option (i.e. rule-condion) like a application-specific window border color would suit better. What do you think?
I wouldn't work because some applications (e.g. web browsers) have a dynamic background.

That's a good point. I'll keep that in mind and i added it to the list of planned features in the BUGS file.

bloom · 2012-01-14 20:40:05

thorsten wrote:

The disadvantage of reparenting is: It's more work. hlwm has to create a decoration window and has to place the client-window within this decoration and has to draw the content of the decoration window. With only one border, it is easier: hlwm tells X the border width and border color and that's all. (That's just the reason why there is no few-lines-patch with a quick fix for this feature request)

I'm wondering if it wouldn't be possible to emulate the inner/outer borders by applying a dynamicly drawn pixmap to the border?

thorsten · 2012-01-14 20:55:16

bloom wrote:

thorsten wrote:
The disadvantage of reparenting is: It's more work. hlwm has to create a decoration window and has to place the client-window within this decoration and has to draw the content of the decoration window. With only one border, it is easier: hlwm tells X the border width and border color and that's all. (That's just the reason why there is no few-lines-patch with a quick fix for this feature request)
I'm wondering if it wouldn't be possible to emulate the inner/outer borders by applying a dynamicly drawn pixmap to the border?

Maybe. But i don't know how this exactly works, if I have more time, i can play with it.

kcirick · 2012-01-14 21:08:25

In case you missed or didn't notice, I've started a screenshot sharing thread under "Artwork and Screenshots" section. Feel free to share your config there

https://bbs.archlinux.org/viewtopic.php?id=133557

bloom · 2012-01-15 09:49:02

thorsten wrote:

bloom wrote:
I'm wondering if it wouldn't be possible to emulate the inner/outer borders by applying a dynamically drawn pixmap to the border?
Maybe. But i don't know how this exactly works, if I have more time, i can play with it.

I forgot the fact that you seem to be able to draw rectangles, if so, here's a simple way to do it:

Let (w, h) be the size of the window content, b1 the size of the separation border, c1 its color, b2 the size of the focus border, c2 its color.
Draw a rectangle of size (w, h) + 2 * (b1 + b2, b1 + b2) and color c2, above it, draw a rectangle of size (w, h) + 2 * (b1, b1) and color c1, above it, draw the actual window of size (w, h) with a transparent border of size b1 + b2.

EDIT
Shadows (if any) shouldn't be applied to the rectangles (I think they must be of type 'desktop', have a 'skip_taskbar' hint, etc.)

*

There's also another problem: you implemented frame gaps (and that's great) but you don't provide window gaps. If shadows are applied to windows (through xcompmgr for example) they're gonna bleed on neighboring window's borders. Also, in the manual, you called the frame gap 'window_gap'.

*

EDIT #2

I realized a third border is needed to protect the focus border from the outside.

Last edited by bloom (2012-01-18 10:40:11)

Doomcide · 2012-01-20 13:58:39

Two more suggestions:
- Please let the focus stay in the same window when toggling fullscreen off
- Please add WM_NAME as a property for rules, as some launchers have the same wm class as the windows they launch; e.g. I want the desura-launcher in pseudo-tile, but not the main desura window

thorsten · 2012-01-20 15:35:49

Doomcide wrote:

Two more suggestions:
- Please let the focus stay in the same window when toggling fullscreen off
- Please add WM_NAME as a property for rules, as some launchers have the same wm class as the windows they launch; e.g. I want the desura-launcher in pseudo-tile, but not the main desura window

the focus switching thing actually is a bug, and I am searching for a nice solution
the WM_NAME will be added to the property for rules. (by the way there are two entries in the window class, you can check them with the instance- and with the class-condition)

Last edited by thorsten (2012-01-20 15:36:44)

Doomcide · 2012-01-20 16:25:45

thorsten wrote:

Doomcide wrote:
Two more suggestions:
- Please let the focus stay in the same window when toggling fullscreen off
- Please add WM_NAME as a property for rules, as some launchers have the same wm class as the windows they launch; e.g. I want the desura-launcher in pseudo-tile, but not the main desura window
the focus switching thing actually is a bug, and I am searching for a nice solution
the WM_NAME will be added to the property for rules. (by the way there are two entries in the window class, you can check them with the instance- and with the class-condition)

Ok, thank you for the quick answer. I know about the WM class, doesn't help in my case(s).

Doomcide · 2012-01-21 16:07:22

It's me again Since I switched from seperate urxvt-terminals to urxvtd &urxvtc the spawn_at function doesn't work anymore on start-up. Any thoughts on this? Here's the script I use:

#!/bin/bash

spawn_at() {(
    herbstclient rule once pid=$BASHPID maxage=10 index="$1"
    shift
    exec "$@"
    ) &
}

spawn_at 10 urxvtc
spawn_at 001 urxvtc -e centerim
spawn_at 11 urxvtc -e ranger
herbstclient spawn urxvtc
while [ ! $(pidof mpd)]; do
    sleep 1s
done
spawn_at 01 urxvtc -e ncmpcpp

thorsten · 2012-01-21 16:40:23

Doomcide wrote:

It's me again Since I switched from seperate urxvt-terminals to urxvtd &urxvtc the spawn_at function doesn't work anymore on start-up. Any thoughts on this? Here's the script I use:

It doesn't work anymore because the pid in the window property is the pid of urxvtd (and not of urxvtc). In the case of urxvt (or any other application that accepts the -name argument), you can do a workaround by setting the instance-name:

#!/bin/bash

spawn_at_by_name() {(
    local id="$2-$BASHPID"
    herbstclient rule once instance="$id" maxage=10 index="$1"
    shift
    local command="$1"
    shift # remove command from $@
    exec "$command" -name "$id" "$@"
    ) &
}

spawn_at_by_name 10 urxvtc
spawn_at_by_name 01 urxvtc -e ncmpcpp
spawn_at_by_name 001 urxvtc -e cat
spawn_at_by_name 11 urxvtc -e tty-clock

Doomcide · 2012-01-21 17:00:10

Thank you, again. Works like a charm.

kcirick · 2012-01-21 18:04:08

I have a request:

In floating mode, when you resize ($mod+right click in default) it anchors the client in the center and resizes in all directions. This is kind of annoying in practice... Is it possible to modify it so that it only resizes in the direction of the nearest corner where the mouse is (i3 does this... if the mouse is in the lower-right quadrant of the window, then it only resizes in that direction)

thorsten · 2012-01-21 18:25:37

kcirick wrote:

In floating mode, when you resize ($mod+right click in default) it anchors the client in the center and resizes in all directions. This is kind of annoying in practice... Is it possible to modify it so that it only resizes in the direction of the nearest corner where the mouse is.

It's just a matter of configuration. Replace the mousebind-block in your autostart by this:

# mouse
hc mouseunbind
hc mousebind $Mod-Button1 move
hc mousebind $Mod-Button2 zoom
hc mousebind $Mod-Button3 resize

bootleg · 2012-01-28 12:35:39

Hello,
I can't manage to get the "focus on click" behavior which should happen if the "focus_follows_mouse" setting is unset (according to the man). When set however, it works as expected (focus follows the mouse).

Here is my autostart:

#!/bin/sh                                                                                                                                                     

term='urxvtc -b 5'
confdir="$XDG_CONFIG_HOME/herbstluftwm"

# be sure to kill idle clients in background
killall herbstclient 2>/dev/null

function hc() {
    herbstclient "$@"
}

hc emit_hook reload
hc keyunbind --all

hc keybind Mod1-q               reload
hc keybind Mod1-Return          spawn $term
hc keybind Mod1-Shift-q         quit
hc keybind Mod1-BackSpace       close
hc keybind Mod4-BackSpace       remove

hc keybind Mod1-t focus -i d
hc keybind Mod1-s focus -i u
hc keybind Mod1-c focus -i l
hc keybind Mod1-r focus -i r
hc keybind Mod1-Tab cycle_all +1
hc keybind Mod1-Shift-Tab cycle_all -1

hc keybind Mod1-space fullscreen toggle
hc keybind Mod1-f     floating toggle
hc keybind Mod4-Tab   cycle_layout

step=0.05
hc keybind Mod4-t       resize d +$step
hc keybind Mod4-s       resize u +$step
hc keybind Mod4-c       resize l +$step
hc keybind Mod4-r       resize r +$step

hc keybind Mod1-v split v 0.5
hc keybind Mod1-h split h 0.5

hc keybind Mod1-dollar spawn $confdir/toggle_dzen
hc keybind Mod4-0 spawn $term -e tmux attach -t rtorrent -d
hc keybind Mod4-1 spawn luakit
hc keybind Mod4-2 spawn claws-mail
hc keybind Mod4-3 spawn $term -e ncmpc -c
hc keybind Mod4-Shift-3 spawn sonata
hc keybind Mod4-4 spawn mpc toggle

hc keybind Mod1-b spawn dmenu_run -nb '#303030' -nf '#97d599' -sb '#97d599' -sf '#303030' -fn '-misc-fixed-*-*-*-*-12-*-*-*-*-*-*-*'
hc keybind Mod1-Delete spawn slock

hc rename default un
hc add deux
hc add trois
hc add quatre

hc keybind Mod1-1 use un
hc keybind Mod1-2 use deux
hc keybind Mod1-3 use trois
hc keybind Mod1-4 use quatre

hc mouseunbind
hc mousebind Mod1-Button1 move
hc mousebind Mod1-Button3 resize

hc set window_gap                 0
hc set frame_border_active_color  '#80a673'
hc set frame_border_normal_color  '#404040'
hc set frame_bg_transparent       1
hc set frame_border_width         1
hc set window_border_width        1
hc set window_border_active_color '#97d599'
hc set window_border_normal_color '#404040'
hc set focus_follows_mouse        0
hc set tree_style                 '╾│ ├└╼─┐'

hc unrule --all

hc rule focus=on
hc rule windowtype~'_NET_WM_WINDOW_TYPE_(DIALOG|UTILITY|SPLASH)' pseudotile=on
hc rule windowtype='_NET_WM_WINDOW_TYPE_DIALOG' focus=on
hc rule windowtype~'_NET_WM_WINDOW_TYPE_(NOTIFICATION|DOCK)' manage=off

herbstclient --idle tag_changed | while read dontcare; do $confdir/toggle_dzen refresh; done

/home/bootleg/config/scripts/startup

Last edited by bootleg (2012-01-28 12:36:10)

thorsten · 2012-01-28 16:01:45

What is wrong, if you disable the "focus_follows_mouse"? You click on another window but the focus doesn't change? If yes, then it is a bug, which sometimes appears if:

gnome-settings-daemon is running
you want to click on a google-chrome window
you want to click on a java7-application
you are using a sun-ray-thinclient

Does one of these conditions match do your setup? If no, are you using other special (in most cases proprietary) applications?

Arch Linux

#126 2012-01-04 15:42:45

Re: herbstluftwm

#127 2012-01-10 11:42:49

Re: herbstluftwm

#128 2012-01-10 16:42:31

Re: herbstluftwm

#129 2012-01-10 21:22:28

Re: herbstluftwm

#130 2012-01-11 12:44:33

Re: herbstluftwm

#131 2012-01-14 13:27:12

Re: herbstluftwm

#132 2012-01-14 17:16:02

Re: herbstluftwm

#133 2012-01-14 17:34:27

Re: herbstluftwm

#134 2012-01-14 17:44:23

Re: herbstluftwm

#135 2012-01-14 20:02:41

Re: herbstluftwm

#136 2012-01-14 20:17:48

Re: herbstluftwm

#137 2012-01-14 20:40:05

Re: herbstluftwm

#138 2012-01-14 20:55:16

Re: herbstluftwm

#139 2012-01-14 21:08:25

Re: herbstluftwm

#140 2012-01-15 09:49:02

Re: herbstluftwm

#141 2012-01-20 13:58:39

Re: herbstluftwm

#142 2012-01-20 15:35:49

Re: herbstluftwm

#143 2012-01-20 16:25:45

Re: herbstluftwm

#144 2012-01-21 16:07:22

Re: herbstluftwm

#145 2012-01-21 16:40:23

Re: herbstluftwm

#146 2012-01-21 17:00:10

Re: herbstluftwm

#147 2012-01-21 18:04:08

Re: herbstluftwm

#148 2012-01-21 18:25:37

Re: herbstluftwm

#149 2012-01-28 12:35:39

Re: herbstluftwm

#150 2012-01-28 16:01:45

Re: herbstluftwm

Board footer