You are not logged in.

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

mentat
Member
From: France
Registered: 2009-01-13
Posts: 138
Website

Re: herbstluftwm

Maybe one day the frame will be full transparency compatible wink
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)

Offline

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

bloom
Member
Registered: 2010-08-18
Posts: 749
Website

Re: herbstluftwm

Can you add a focus_changed WINID hook?

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


gh · da · ds · cr · ab · fkr

Offline

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

thorsten
Member
From: Germany
Registered: 2010-02-24
Posts: 148

Re: herbstluftwm

bloom wrote:

Can you add a focus_changed WINID hook?

I will add it quite soon.

Offline

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

thorsten
Member
From: Germany
Registered: 2010-02-24
Posts: 148

Re: herbstluftwm

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 wink

Offline

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

bloom
Member
Registered: 2010-08-18
Posts: 749
Website

Re: herbstluftwm

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 wink

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


gh · da · ds · cr · ab · fkr

Offline

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

bloom
Member
Registered: 2010-08-18
Posts: 749
Website

Re: herbstluftwm

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)


gh · da · ds · cr · ab · fkr

Offline

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

kcirick
Member
Registered: 2010-06-21
Posts: 364

Re: herbstluftwm

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...

Offline

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

thorsten
Member
From: Germany
Registered: 2010-02-24
Posts: 148

Re: herbstluftwm

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?

Offline

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

thorsten
Member
From: Germany
Registered: 2010-02-24
Posts: 148

Re: herbstluftwm

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 smile

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.

Offline

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

bloom
Member
Registered: 2010-08-18
Posts: 749
Website

Re: herbstluftwm

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)


gh · da · ds · cr · ab · fkr

Offline

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

thorsten
Member
From: Germany
Registered: 2010-02-24
Posts: 148

Re: herbstluftwm

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.

Offline

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

bloom
Member
Registered: 2010-08-18
Posts: 749
Website

Re: herbstluftwm

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?


gh · da · ds · cr · ab · fkr

Offline

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

thorsten
Member
From: Germany
Registered: 2010-02-24
Posts: 148

Re: herbstluftwm

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.

Offline

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

kcirick
Member
Registered: 2010-06-21
Posts: 364

Re: herbstluftwm

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

Offline

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

bloom
Member
Registered: 2010-08-18
Posts: 749
Website

Re: herbstluftwm

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)


gh · da · ds · cr · ab · fkr

Offline

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

Doomcide
Member
Registered: 2011-08-22
Posts: 221

Re: herbstluftwm

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

Offline

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

thorsten
Member
From: Germany
Registered: 2010-02-24
Posts: 148

Re: herbstluftwm

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  wink

  • 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)

Offline

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

Doomcide
Member
Registered: 2011-08-22
Posts: 221

Re: herbstluftwm

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  wink

  • 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).

Offline

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

Doomcide
Member
Registered: 2011-08-22
Posts: 221

Re: herbstluftwm

It's me again big_smile 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

Offline

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

thorsten
Member
From: Germany
Registered: 2010-02-24
Posts: 148

Re: herbstluftwm

Doomcide wrote:

It's me again big_smile 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

Offline

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

Doomcide
Member
Registered: 2011-08-22
Posts: 221

Re: herbstluftwm

Thank you, again. Works like a charm.

Offline

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

kcirick
Member
Registered: 2010-06-21
Posts: 364

Re: herbstluftwm

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)

Offline

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

thorsten
Member
From: Germany
Registered: 2010-02-24
Posts: 148

Re: herbstluftwm

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

Offline

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

bootleg
Member
Registered: 2010-12-08
Posts: 38

Re: herbstluftwm

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)

Offline

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

thorsten
Member
From: Germany
Registered: 2010-02-24
Posts: 148

Re: herbstluftwm

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?

Offline

Board footer

Powered by FluxBB