herbstluftwm

The Compiler · 2014-02-05 05:20:07

milomouse wrote:

Edit: Although, I've decided not to push to public unless I've made considerable changes, and in that case I'll probably just contact on IRC about possible merge, etc.

Oy, why not? Can't hurt after all!

I started coding on hlwm with no previous C experience on computers (only on microcontrollers, which is quite a difference). I learned a lot in the process and now I'm one of the main developers I'd say. If a patch isn't good in some way, we're happy to help! We don't bite. (Okay, I might if I'm asked to )

IMHO, nobody benefits when doing changes without handing them upstream. Not even you, because then you have to handle merge conflicts when there are new changes upstream.

Just my $.02.

Flo

mentat · 2014-03-16 19:20:59

hi Thorsten,

just update my git version and now when I close a windows there is a kind of "green glitch flash".
I've check all my color settings but all seem fine (background, border ...).

thorsten · 2014-03-17 17:22:35

mentat wrote:

hi Thorsten,
just update my git version and now when I close a windows there is a kind of "green glitch flash".
I've check all my color settings but all seem fine (background, border ...).

Yes, it's the main bug of decorations, I don't know how to fix it yet.

thorsten · 2014-03-18 08:28:41

thorsten wrote:

mentat wrote:
hi Thorsten,
just update my git version and now when I close a windows there is a kind of "green glitch flash".
I've check all my color settings but all seem fine (background, border ...).
Yes, it's the main bug of decorations, I don't know how to fix it yet.

Hey Mentat, I just fixed that bug. Please try again the current git version.

mentat · 2014-03-18 08:33:13

Ok.
I miss the bug tracking was made on the ML.
Thanks for taking care

EDIT --
Thorsten, just read your answer.
After update, herbstluftwm work (again) like a charm ^_^
Thank you !

Last edited by mentat (2014-03-18 08:39:33)

mentat · 2014-03-19 10:19:09

Thorsten,

Can I report an other (maybe ?) bug?

When I use scribus in floating mode or not and launch some menu item like "export > save to pdf".
The pdf export window appear but only the first time.
If I redo export, nothing appear so I need to quit scribus and relaunch.

Same comportment with a *specific type* of windows like "preview print", other exports options, ....

I've made test with an other wm (evilwm) and all work fine.
How can I help to debug ?

Edit: fix typo

Last edited by mentat (2014-03-19 10:23:18)

The Compiler · 2014-03-19 17:14:39

I've tried to reproduce that on both the current git HEAD and 0.5.3, and couldn't.

Interesting points:

What version of hlwm are you using? (herbstclient version)
What version of Scribus are you using?
What's the output of herbstclient stack after the window doesn't appear? Does it show up there?

mentat · 2014-03-20 08:49:49

Hi The Compiler.

I've tried to reproduce that on both the current git HEAD and 0.5.3, and couldn't.

So need to find own my config.
Here the informations:

What version of hlwm are you using? (herbstclient version)

herbstluftwm 0.5.3-git (9cd80a1) (built on Mar 18 2014)

What version of Scribus are you using?

Scribus 1.4.3

Qt version 4.8.5

With GTK+ apparence motif.

What's the output of herbstclient stack after the window doesn't appear? Does it show up there?

Before with the pdf export window open:

╾─┐ 
  └─┐ Monitor 0 with tag "3"
    ├─┐ Focus-Layer
    │ └─╼ Client 0xe00087 "urxvt"
    ├─╼ Fullscreen-Layer
    ├─┐ Normal Layer
    │ ├─╼ Client 0xe00087 "urxvt"
    │ ├─╼ Client 0x1a0001c "Vérificateur"
    │ └─╼ Client 0x1a00015 "Scribus 1.4.3 - [/home/mentat/Scribus-Test.sla]"
    └─┐ Frame Layer
      └─╼ Window 0xa00015

After

╾─┐ 
  └─┐ Monitor 0 with tag "3"
    ├─┐ Focus-Layer
    │ └─╼ Client 0xe00087 "urxvt"
    ├─╼ Fullscreen-Layer
    ├─┐ Normal Layer
    │ ├─╼ Client 0xe00087 "urxvt"
    │ └─╼ Client 0x1a00015 "Scribus 1.4.3 - [/home/mentat/Scribus-Test.sla]"
    └─┐ Frame Layer
      └─╼ Window 0xa00015

Thx!

mentat · 2014-03-20 08:59:55

I've made some other tests:

Killall process who start in my xinitrc (unclutter, ...):
same problem.

Retry with a complete new document in Scribus:
It's work perfect if if you export with no error ...
but if you have the warning window (for example insert a low resolution image), you can export only one time.
The window "won't" appear after.

xwininfo: Window id: 0x40001c "Vérificateur"

  Absolute upper-left X:  530
  Absolute upper-left Y:  254
  Relative upper-left X:  1
  Relative upper-left Y:  1
  Width: 306
  Height: 259
  Depth: 24
  Visual: 0x20
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x22 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: yes
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +530+254  -530+254  -530-255  +530-255
  -geometry 306x259+529+253

Edit -- xwininfo

Last edited by mentat (2014-03-20 09:04:34)

thorsten · 2014-03-27 02:13:59

mentat wrote:

When I use scribus in floating mode or not and launch some menu item like "export > save to pdf".
The pdf export window appear but only the first time.
If I redo export, nothing appear so I need to quit scribus and relaunch.
Same comportment with a *specific type* of windows like "preview print", other exports options, ....
I've made test with an other wm (evilwm) and all work fine.

I've just fixed it and released the fixed version as 0.6.2. Please try again, because I only could reproduce the same thing for qjackctl and not for scribus directly. (It should be the same issue and thus be fixed now in hlwm)

mentat wrote:

How can I help to debug ?

As you did: providing as much information as possible via xprop/xwininfo/ herbstclient stack/... helps quite a lot

mentat · 2014-03-28 11:29:52

thorsten wrote:

I've just fixed it and released the fixed version as 0.6.2. Please try again,
because I only could reproduce the same thing for qjackctl and not for scribus
directly. (It should be the same issue and thus be fixed now in hlwm)

Thorsten your next release fix the bug in scribus.
No problem at all.

Thank you very much.

PieterGen · 2014-04-28 10:58:30

Hi devs & users:

Couple of questions, if I can read the answers somewhere please point me to it (yes I DID look myself, but I'm kinda new to modifying windowmanagers - so help me make my first baby steps, please :-)

1. My volume knobs don't work (Thinkpad). Any clues on what settings to change?

2. Is it possible to rechange the size of windows *inside* a frame?

3. If I change frame sizes (ctrl mod4 h or l) most apps reflow the content nicely. But, xterm does not. It pushes all text inside a narrow column and keeps it narrow even if I make the frame wide again. Is this an xterm bug?

Thanks!

Slithery · 2014-05-06 14:08:23

Just a heads up, herbstluftwm is now in the main repos.

Thanks to Jonathan Steel for adopting this package.

octref · 2014-05-14 14:24:18

Oh finally found this thread. The-Compiler I saw you yesterday in IRC

I'm also having the "green glitch" problem. And it happens when I have multiple windows open in a frame and change frame layout.
However, when I pkill compton, the "green glitch" is gone. It's a little bit annoying but I can stand it.

Been using hlwm for several days and quite happy with it. Keep the great work

@PieterGen:
1. I'm not sure but you can try xev, spin the knob and see what events get generated. If it's a XF86RaiseVolume keypress or something like that just map it to amixer commands or whatever volume manager you are using.
2. I didn't find such commands. I'd just give that window a new frame and resize it.
3. I tried xterm for like 5 min and ditched it. I suggest you try urxvt. When I was searching for a great terminal in this forum many people recommends it. I tried it and really like it. Haven't encountered **any** problem during my wm-hopping(i3, openbox, awesome, xmonad, and hlwm of course).
People of suckless.org seems to bash against xterm (http://st.suckless.org/) violently.

thorsten · 2014-05-15 08:02:33

octref wrote:

Oh finally found this thread. The-Compiler I saw you yesterday in IRC
I'm also having the "green glitch" problem. And it happens when I have multiple windows open in a frame and change frame layout.
However, when I pkill compton, the "green glitch" is gone. It's a little bit annoying but I can stand it.

Which version are you using? herbstluftwm from community? herbstluftwm-git from aur? Some custom version? Because this "green glitch" is actually fixed since 0.6.0 (I'm also using compton). Does the color change if you modify the theme.background_color attribute? (via herbstclient attr theme.background_color red).

Regarding Window resizing:

octref wrote:

2. I didn't find such commands. I'd just give that window a new frame and resize it.

Right, it isn't possible to resize windows within a frame. But you can split the frame easily with split explode (Bound to Mod-Control-space per default). Then you can resize the frames.

octref · 2014-05-15 14:44:06

thorsten wrote:

Which version are you using? herbstluftwm from community? herbstluftwm-git from aur? Some custom version? Because this "green glitch" is actually fixed since 0.6.0 (I'm also using compton). Does the color change if you modify the theme.background_color attribute? (via herbstclient attr theme.background_color red).

Thank you so much for responding so promptly!

I'm using the community one, version 0.6.2-2.
When I've disabled all

hc attr

in my autostart, and

hc attr theme.background_color

gave no output, there was the green glitch.
Then when I did

hc attr theme.background_color red

and confirmed the color was red by

hc attr theme.background_color

The green glitch problem still persists.

I have

hc keybind $Mod-space cycle_layout 1 vertical horizontal

And this problem would happen when I have multiple windows open in a frame and toggle the layout.

A behaviour that I've observed is:
The green glitch always happen within a certain area.

If there are two windows in a frame, and I toggle the layout.
I use the following graph to represents the screen. (0, 0) is the upperleft area from middle of screen to upperleft point, and (1, 1) is the lowerright area from middle of screen to lowerright point.
(0, 0) (1, 0)
(0, 1) (1, 1)
The green glitch is always in (1, 1) area.

If I have three windows:
(0, 0) (1, 0) (2, 0)
(0, 1) (1, 1) (2, 1)
(0, 2) (1, 2) (2, 2)
When I toggle from vertical -> horizontal, the green glitch is always in (2, 1) and (2, 2) (Both are green in that glitch)
When I toggle from horizontal -> vertical, the green glitch is always in (1, 2) and (2, 2) (Both are green in that glitch)

If I have four windows:
(0, 0) (1, 0) (2, 0) (3, 0)
(0, 1) (1, 1) (2, 1) (3, 1)
(0, 2) (1, 2) (2, 2) (3, 2)
(0, 3) (1, 3) (2, 3) (3, 3)
When I toggle from vertical -> horizontal, the green glitch is always in (3, 1) (3, 2) and (3, 3) (All three are green in that glitch)
When I toggle from horizontal -> vertical, the green glitch is always in (1, 3) (2, 3) and (3, 3) (All three are green in that glitch)

The pattern seems to be:
With n window,
vertical -> horizontal: green glitch in column n except (n, 0)
horizontal -> vertical: green glitch in row n except (0, n)

Hopefully I didn't confuse you.
Is there anything else you need me to test?

May I also make a feature request?
default_frame_layout doesn't seem to change the layout of the frame created at startup.
I've done this to change the layout of them at startup:

hc rename default "${tag_names[0]}" || true
for i in ${!tag_names[@]} ; do
    hc add "${tag_names[$i]}"
    key="${tag_keys[$i]}"
    if ! [ -z "$key" ] ; then
        hc keybind "$Mod-$key" use_index "$i"
        hc keybind "$Mod-Shift-$key" move_index "$i"
    fi
+  hc use_index "$i"
+  hc set_layout horizontal
done

But can you make this built-in?
Or is there any other way I can modify the default layout of the frame created at startup time?

And I want thank you for creating this wonderful WM! I really like it.
It's super wunderbar! (That's like all the German I know )
After this month I'd have some free time so maybe I'd be able to contribute some code.

Last edited by octref (2014-05-15 14:46:15)

octref · 2014-05-15 15:32:06

@thorsten:
The green glitch also happens when I split explode the frame. It appears in the frame borders created when splitting the frames.

Last edited by octref (2014-05-15 15:32:27)

wirr · 2014-05-15 17:37:06

thorsten wrote:

Regarding Window resizing:
octref wrote:
2. I didn't find such commands. I'd just give that window a new frame and resize it.
Right, it isn't possible to resize windows within a frame.

Somehow I forgot to post that yesterday:

#!/bin/bash

hstep=${2-15}
vstep=${3-16}

window=$(xdotool getactivewindow)
winfo=$(xwininfo -id $window)
width=$(awk '/^  Width: /{print $NF}' <<< "$winfo")
height=$(awk '/^  Height: /{print $NF}' <<< "$winfo")

herbstclient pseudotile on

case $1 in 
        +)op=+;;
        -)op=-;;
        *)echo "$0 +|- [hstep] [vstep]";exit 1;;
esac

xdotool windowsize $window $(($width$op$hstep)) $(($height$op$vstep))

It has no effect in a terminal when hstep<charwidth or vstep<lineheight.
Everything is possible with herbstluftwm

thorsten wrote:

(I'm also using compton)

Thats interesting. With the tabbed layout there are two minor inconveniences when you put many windows in one frame. The shadows get darker and you cannot see the wallpaper through transparent windows, only the other windows. You see they are minor. Would it still be feasible to move those normally hidden windows out of the screen?

octref · 2014-05-15 18:29:44

wirr wrote:

Thats interesting. With the tabbed layout there are two minor inconveniences when you put many windows in one frame. The shadows get darker and you cannot see the wallpaper through transparent windows, only the other windows. big_smile You see they are minor. Would it still be feasible to move those normally hidden windows out of the screen?

Yes I had the same issue!
I found tabbed layout is the real screen-estate saver, but I'm not using it either on my i3 or hlwm due to this specific issue.
Hopefully this will get fixed. Instead of moving tabbed windows out of screen I guess hiding them will be OK & easier to implement.

thorsten · 2014-05-15 21:08:07

wirr wrote:

thorsten wrote:
(I'm also using compton)
Thats interesting. With the tabbed layout there are two minor inconveniences when you put many windows in one frame. The shadows get darker and you cannot see the wallpaper through transparent windows, only the other windows. You see they are minor. Would it still be feasible to move those normally hidden windows out of the screen?

Theoretically, this would be possible, but you have to handle it with care: If you have a pseudotiled dialog, one normally is interested in seeing the other windows behind that. Maybe some people want that current behaviour, because they can see, what's behind the focused semi-transparent terminal. Maybe one can make it configurable.

Regarding the autostart request: I can't merge that, because it changes the currently focused desktop when reloading the autostart (it's the use_index). Furthermore, if you explicitly set the layout on some tag, then reloading your autostart destroys the configured layout. So my suggestion is: Just set the default layout before creating the tags (i.e. before the line hc add...).

Normally, changing the default does not happen that often, so just restart hlwm. If you want to change it very often, then just use your code-snippet.

octref · 2014-05-16 03:53:14

thorsten:
Oh sorry I wasn't clear. That was just a workaround I came up with, and I definitely don't want it to be merged.
I thought default_frame_layout wouldn't affetct the root frame and was requesting changing it so it does affect the root frame.

But I just founnd it in the FAQ:
Existing tags are not affected by a change of that variable (only new ones), so be sure to set it before creating any tags
So I moved my settings above the tag creation snippet, and now I don't have to use this workaround.

Thanks!

wirr · 2014-05-18 10:20:20

thorsten wrote:

wirr wrote:
thorsten wrote:
(I'm also using compton)
Thats interesting. With the tabbed layout there are two minor inconveniences when you put many windows in one frame. The shadows get darker and you cannot see the wallpaper through transparent windows, only the other windows. You see they are minor. Would it still be feasible to move those normally hidden windows out of the screen?
Theoretically, this would be possible, but you have to handle it with care: If you have a pseudotiled dialog, one normally is interested in seeing the other windows behind that. Maybe some people want that current behaviour, because they can see, what's behind the focused semi-transparent terminal. Maybe one can make it configurable.

First I don't think it is that much a showstopper as octref says. I disabled opacity in compton and use the old fashioned pseudotransparency in urxvt. I'm using the tabbed layout almost exclusively.

Yes, the difficult part is not sending them off screen but to figure out when they should come back. And those two examples make it even harder. But in both cases I suspect that one window in addition to the active one would be enough. Maybe there would be an interest in having a 'number_of_windows_in_tabbed' setting?

doubleshot · 2014-06-05 18:27:58

I'am having a problem with tags displaying clients in stacking mode on my secondary monitor. Each new window or dialog is shifted to the right, making it sometimes impossible to see them, simply because they're outside of the viewport.
It's more than annoying, since I prefer to use certain applications (like gimp) with floating windows.

Btw: this problem doesn't occur on my primary monitor...

Is there a solution for my problem in the current version of herbstluft? I really like this wm, but I tend to use different full blown desktops or wms just because of this .

Baryon · 2014-06-10 17:46:54

Hmm, having upgraded to 0.6.2 using the official repository, herbstluftwm is now acting sluggish for me - it takes about 2 seconds to respond to mouse clicks for example. Other wms are working fine.

Last edited by Baryon (2014-06-10 17:47:18)

thorsten · 2014-06-10 20:21:36

doubleshot wrote:

I'am having a problem with tags displaying clients in stacking mode on my secondary monitor. Each new window or dialog is shifted to the right, making it sometimes impossible to see them, simply because they're outside of the viewport.
It's more than annoying, since I prefer to use certain applications (like gimp) with floating windows.
Btw: this problem doesn't occur on my primary monitor...
Is there a solution for my problem in the current version of herbstluft? I really like this wm, but I tend to use different full blown desktops or wms just because of this .

The problem is that the application requests a very large x-coordinate and herbstluftwm treats the coordinates relative to the monitor position. Instead of switching to another window manager you can join the two monitors using:

herbstclient set_monitors $(xwininfo -root|grep '[-]geometry'|awk '{print $2; }')

and then you can switch back to the multimonitor-setup with detect_monitors

Baryon wrote:

Hmm, having upgraded to 0.6.2 using the official repository, herbstluftwm is now acting sluggish for me - it takes about 2 seconds to respond to mouse clicks for example. Other wms are working fine.

Does it also happen with simple terminals? E.g. if you try to select some text in xterm? I heard of similar problems after upgrading to the new window decorations and it sounds graphics-driver-dependent. (I still guess that it's hlwm's fault, I just have problems reproducing & debugging it)

Arch Linux

#376 2014-02-05 05:20:07

Re: herbstluftwm

#377 2014-03-16 19:20:59

Re: herbstluftwm

#378 2014-03-17 17:22:35

Re: herbstluftwm

#379 2014-03-18 08:28:41

Re: herbstluftwm

#380 2014-03-18 08:33:13

Re: herbstluftwm

#381 2014-03-19 10:19:09

Re: herbstluftwm

#382 2014-03-19 17:14:39

Re: herbstluftwm

#383 2014-03-20 08:49:49

Re: herbstluftwm

#384 2014-03-20 08:59:55

Re: herbstluftwm

#385 2014-03-27 02:13:59

Re: herbstluftwm

#386 2014-03-28 11:29:52

Re: herbstluftwm

#387 2014-04-28 10:58:30

Re: herbstluftwm

#388 2014-05-06 14:08:23

Re: herbstluftwm

#389 2014-05-14 14:24:18

Re: herbstluftwm

#390 2014-05-15 08:02:33

Re: herbstluftwm

#391 2014-05-15 14:44:06

Re: herbstluftwm

#392 2014-05-15 15:32:06

Re: herbstluftwm

#393 2014-05-15 17:37:06

Re: herbstluftwm

#394 2014-05-15 18:29:44

Re: herbstluftwm

#395 2014-05-15 21:08:07

Re: herbstluftwm

#396 2014-05-16 03:53:14

Re: herbstluftwm

#397 2014-05-18 10:20:20

Re: herbstluftwm

#398 2014-06-05 18:27:58

Re: herbstluftwm

#399 2014-06-10 17:46:54

Re: herbstluftwm

#400 2014-06-10 20:21:36

Re: herbstluftwm

Board footer