herbstluftwm

thorsten · 2013-12-06 18:25:22

wirr wrote:

hi Thorsten
Are there any plans to include a cycle_frame command?
One could probably script that functionality, but it would be much cleaner witch a herbstclient command.
The reason behind the need is that I would like to bind my keys as follows:
mod+h cycle_frame -1
mod+j cycle +1
mod+k cycle -1
mod+l cycle_frame 1
But without the cycle_frame I cannot reach all frames.
Thank you

So what should this cycle_frame do? The same as cycle_all but going from frame to frame?

suija · 2013-12-07 12:04:07

Hi, I just have to ask for single floating windows. It's a shame this wm is so good, but is lacking this crucial feature. There are some things that just don't work tiled.

Also the current floating mode is just too buggy when resizing windows, and bad even with that fixed. Why would you want everything floating in a tiler?

Other than that, thanks for the great wm, it is probably gonna be my default one. Unless I get frustrated with the above issue and go back to awesome.

By the way can I set the default layout to grid for example, so I don't have to switch every time?

The Compiler · 2013-12-07 13:02:00

suija wrote:

Hi, I just have to ask for single floating windows. It's a shame this wm is so good, but is lacking this crucial feature. There are some things that just don't work tiled.

The problem is nobody of the developers needs this feature enough for it being implemented being a high priority. So if you can code C, please step in and submit a patch, we all would be more than happy!

If nobody does, I might do it at some point, but there are a lot of other things on my hlwm todo list which are more important to me.

That being said, you might want to try if floatmon.sh from the scripts/ directory is for you. That does single-window floating with a little hack involving multiple virtual monitors.

Also the current floating mode is just too buggy when resizing windows

How so?

By the way can I set the default layout to grid for example, so I don't have to switch every time?

Do something like this in your autostart (before creating tags):

hc set default_frame_layout 3
hc load default '(clients max:0)'

This sets the default layout for new tags to grid, and then loads a grid layout on the "default" tag which got created before loading the config.

Flo

Last edited by The Compiler (2013-12-07 13:02:20)

thorsten · 2013-12-07 13:06:10

suija wrote:

Hi, I just have to ask for single floating windows. It's a shame this wm is so good, but is lacking this crucial feature. There are some things that just don't work tiled.
Also the current floating mode is just too buggy when resizing windows, and bad even with that fixed. Why would you want everything floating in a tiler?

I never use applications which require floating, so I thought most tiling WM users don't need it neither. Some mistake But I plan to fix it, it may take some time.

suija wrote:

Other than that, thanks for the great wm, it is probably gonna be my default one. Unless I get frustrated with the above issue and go back to awesome.
By the way can I set the default layout to grid for example, so I don't have to switch every time?

You can adjust the default_frame_layout setting and should keep the according FAQ-Entry in mind:

Q: I set default_frame_layout to my favorite layout but it doesn’t work
with the root frame/existing frames

    Existing tags are not affected by a change of that variable (only
    new ones), so be sure to set it before creating any tags. A current
    workaround is to put hc split vertical 0.5; hc remove at the end in
    your autostart file. You can also cycle_layout in existing tags.

wirr · 2013-12-07 13:10:46

Thank you for the fast response.

thorsten wrote:

So what should this cycle_frame do? The same as cycle_all but going from frame to frame?

The same as cycle_all but only going from frame to frame. It would be (cycle ∪ cycle_frame) = cycle_all and (cycle ∩ cycle_frame) = ∅. I think you got it right

I set the default_frame_layout to 2. So to change the focus between windows of the same frame I have to use the cycle command. But when I bind Mod+J,K to cycle the frames above and below are unreachable.

thorsten · 2013-12-07 13:31:49

wirr wrote:

thorsten wrote:
So what should this cycle_frame do? The same as cycle_all but going from frame to frame?
The same as cycle_all but only going from frame to frame. It would be (cycle ∪ cycle_frame) = cycle_all and (cycle ∩ cycle_frame) = ∅. I think you got it right

Now it totally know what you want

wirr wrote:

I set the default_frame_layout to 2. So to change the focus between windows of the same frame I have to use the cycle command. But when I bind Mod+J,K to cycle the frames above and below are unreachable.

You do not necessarily need to use cycle to switch between windows in a grid-layout frame. You can use directional focus up/down/left/right. If you really want to use cycle between windows, then you can bind the directional focus command for frames to it: focus -e up

But if you want to use cycle_frame anyways, you can compose it using chain, cycle_all, focus_nth. The nearly equivalent command to cycle_frame +1 is:

    chain , focus_nth -1 , cycle_all +1

The only problem is, that doing the reverse directly afterwards

    chain , focus_nth 0 , cycle_all -1

focuses the last child of the previously focused frame. If it doesn't suite you, we can implement it directly, it shouldn't be much code.

wirr · 2013-12-07 14:37:08

Not to be a besserwisser but:

2: max; 3 : grid

One could argue that the max layout should be a stack layout. In a stack the window behind is above and bevore is below or vice versa. Then the directional movement would work with the max layout.

The other solution would be to have a command which swiches windows inside one frame (cycle) and another command that swiches the frames (cycle_frame). This would allow wmii like key-bindings. Sorry for beeing stucked in that wmii mindset.

I will experiment a bit with your chain examples, but it seems that the order of the chain depends on which window is focused (first/last/middle). I thought of filling `herbstclient dump` tho arrays and indexes and then use those to determine which client will get focus. It would probably need more code than an intern implementation:

it shouldn't be much code.

But it would be very useful

suija · 2013-12-07 16:28:01

Very fast responses thanks.
About the resizing - yesterday I was running gvim in floating mode, cause when you change font, it resizes the window and it shows me the difference in font spacing. When I try to resize gvim with the mouse it immediately gets several screens big and crashes. Also the way windows resize is wonky (from the middle outwards..).

By the way the reason I like hlwm so much is the combination of manual tiling and max layout. Several frames, each frame has 2 clients, and I flick them with tab, so great. I think I haven't seen this before. Please don't ever get rid of this

Last edited by suija (2013-12-07 17:00:42)

The Compiler · 2013-12-08 11:04:10

suija wrote:

About the resizing - yesterday I was running gvim in floating mode, cause when you change font, it resizes the window and it shows me the difference in font spacing. When I try to resize gvim with the mouse it immediately gets several screens big and crashes.

Yeah, this is some weird resize-focus-bug waiting to be fixed, which occurs in a handful of applications - there are also weird effects in tiling mode.
Thanks for reporting, the more we know about it, the better.

Also the way windows resize is wonky (from the middle outwards..).

That's just an insane default setting really. Use the middle button to resize the window like you'd expect, or swap the bindings:

hc mousebind $Mod-Button2 zoom
hc mousebind $Mod-Button3 resize

Flo

wirr · 2013-12-08 16:00:33

So here is the hlwm_cycle_frames.sh script:

#!/bin/bash

case $1 in
  [-+][0-9]*)
    activewinid="0x$( bc <<< "ibase=10;obase=16;$(xdotool getactivewindow)")"
    while read -r l; do
      dump+=("$l")
      if grep -qi "$activewinid" <<< $l ; then
        activeindex=$(( ${#dump[@]} - 1 ))
      fi
    done < <(herbstclient dump | sed 's/(clients /\n/g;s/(//g;s/)//g' | tail -n +2)

    newindex=$(( ($activeindex + ($1)) % (${#dump[@]}) ))
    nextframe=( ${dump[$newindex]} )
    xdotool windowactivate "${nextframe[((${nextframe[0]##*:}+1))]}"
    ;;
  *)
    echo Usage:
    echo "    $0 +n"
    echo "    $0 -n"
    ;;
esac

edit: new code

Last edited by wirr (2013-12-10 14:34:22)

thorsten · 2013-12-24 16:57:49

thorsten wrote:

wirr wrote:
thorsten wrote:
So what should this cycle_frame do? The same as cycle_all but going from frame to frame?
The same as cycle_all but only going from frame to frame. It would be (cycle ∪ cycle_frame) = cycle_all and (cycle ∩ cycle_frame) = ∅. I think you got it right
Now it totally know what you want

I just implemented it, the new command is called 'cycle_frame'. If it's not exactly what you expected just tell.

thorsten · 2013-12-24 22:04:15

Some minutes ago, herbstluftwm 0.5.3 has been released. It also includes the new cycle_frame command and many other features like respecting of size hints, improvement of transparent frames, faster floating mode, intelligent automatic tiling via the new split mode explode. See the NEWS for a full list of new features.

milomouse · 2014-01-09 16:47:51

I genuinely enjoy using herbstluftwm and thank you for the creation and dedicated maintenance of the project. So, yes, thanks! A few queries, if I may:

Have you thought of adding an option for "use_index [RELATIVE]" such as "--occupied", which focuses the next/prev index that is occupied by a client? I personally think it would be a great feature since I often find myself scrolling through desktops to get to the next one where I had something opened. If so, this could even lead to a "--skip-occupied" option for those wanting the next empty tag.
Do you think there is a way to add a "padding" option instead of (along side of existing option, I mean) set_monitors geometry changes to entire screen? It could simply offset managed window placement by that many pixels (eg. unmanged bars would of course use set_monitor aspects while managed windows would also check for padding offset). This could possibly remedy the fullscreen issue; allowing fullscreen applications to ignore padding and take up full set/detected screen size and covering bars unmanaged and outside of the padding? I'm sure this would involve some work but could be easier than trying a whole built-in true fullscreen deal or whatnot. Just an idea, anyway.

That's all, really. Thought I had more but this is problem enough for now, haha.

The Compiler · 2014-01-09 20:03:12

Heya!

milomouse wrote:

Have you thought of adding an option for "use_index [RELATIVE]" such as "--occupied", which focuses the next/prev index that is occupied by a client? I personally think it would be a great feature since I often find myself scrolling through desktops to get to the next one where I had something opened. If so, this could even lead to a "--skip-occupied" option for those wanting the next empty tag.

I made a script for that some while ago: tagswitch.
I think I also implemented skipping to the next empty tag for someone who wanted that, but can't find that...

Implementing this properly in hlwm itself is on my hlwm todo list (which is finally getting a bit smaller) for a while already though, so there's a good chance I'll implement it somewhen in the next days/weeks/months.

milomouse wrote:

Do you think there is a way to add a "padding" option instead of (along side of existing option, I mean) set_monitors geometry changes to entire screen? It could simply offset managed window placement by that many pixels (eg. unmanged bars would of course use set_monitor aspects while managed windows would also check for padding offset). This could possibly remedy the fullscreen issue; allowing fullscreen applications to ignore padding and take up full set/detected screen size and covering bars unmanaged and outside of the padding? I'm sure this would involve some work but could be easier than trying a whole built-in true fullscreen deal or whatnot. Just an idea, anyway.

I'm not sure if I understand you correctly, isn't what you describing "hc pad" already?

       pad MONITOR [PADUP [PADRIGHT [PADDOWN [PADLEFT]]]]
           Sets the pad of specified monitor to the specified padding. If no or an empty padding is given, it is not changed.

That's also what's used to give the panels the needed space.
So from what I understand, this is all already implemented, including the "whole built-in true fullscreen deal". Also not sure what fullscreen issue you mean.

Flo

milomouse · 2014-01-09 20:13:10

The Compiler wrote:

I made a script for that some while ago: tagswitch.
I think I also implemented skipping to the next empty tag for someone who wanted that, but can't find that...
Implementing this properly in hlwm itself is on my hlwm todo list (which is finally getting a bit smaller) for a while already though, so there's a good chance I'll implement it somewhen in the next days/weeks/months.

Nice -- didn't see the script before. I will give it a try!

The Compiler wrote:

I'm not sure if I understand you correctly, isn't what you describing "hc pad" already?
...
That's also what's used to give the panels the needed space.
So from what I understand, this is all already implemented, including the "whole built-in true fullscreen deal". Also not sure what fullscreen issue you mean.

I missed this completely. Wow, my mistake! I was going off information in the first post of this thread since I saw it was getting Edit [updates] every so often. I now see that you can pad for bars and let fullscreen apps cover them. I am content and humbled (and reading the entire manpage). Seems like there is everything I desire already here.. will be using this window manager more frequently now if not exclusively. Thanks!

Last edited by milomouse (2014-01-09 20:29:10)

milomouse · 2014-01-18 01:40:23

I notice that some commands always return 0 even if they've already been issued such as "lock_tag" and "unlock_tag", but I expect it's because they ran without error. This is fine but would it be possible for these commands (and maybe other similars I haven't checked yet) to return a non-zero exit status if they've already been executed correctly once before? For example, "lock_tag" could return 0 if tag is not already locked, but return 1 if it's currently in a locked state (and therefore no need to lock again)? And likewise, "unlock_tag" to return 0 if it successfully unlocks tag, else return 1 if tag is not currently locked (and therefore no need to unlock).

Anyway, just an idea as these return values could give commands like "and" + "or" a bit more use. If not, no big deal. Keep up the good work!

wirr · 2014-01-18 16:08:44

thorsten wrote:

I just implemented it, the new command is called 'cycle_frame'. If it's not exactly what you expected just tell.

Oh, I'm sorry I didn't see this on christmas. But I saw it on my birthday

Thank you very much, it's exactly what I wanted and way better than my script.

Everything is absolutely great and feature complete!

Bmpanel works out of the box and I can start/stop tags as before with that other wm but herbstluftwm can 'reload the layout'. After many years a dream comes through.
Thank you!

The Compiler · 2014-01-20 09:31:20

milomouse wrote:

I notice that some commands always return 0 even if they've already been issued such as "lock_tag" and "unlock_tag", but I expect it's because they ran without error. This is fine but would it be possible for these commands (and maybe other similars I haven't checked yet) to return a non-zero exit status if they've already been executed correctly once before? For example, "lock_tag" could return 0 if tag is not already locked, but return 1 if it's currently in a locked state (and therefore no need to lock again)? And likewise, "unlock_tag" to return 0 if it successfully unlocks tag, else return 1 if tag is not currently locked (and therefore no need to unlock).
Anyway, just an idea as these return values could give commands like "and" + "or" a bit more use. If not, no big deal. Keep up the good work!

Added to my giant wishlist of trivial hlwm things people requested
So expect this to be implemented somewhen in the next days/weeks/months when I feel like it

Flo

milomouse · 2014-01-20 22:09:26

The Compiler wrote:

Added to my giant wishlist of trivial hlwm things people requested
So expect this to be implemented somewhen in the next days/weeks/months when I feel like it
Flo

Figured I'd throw it into the list before more were added. FIFO reasoning!

Agent69 · 2014-01-22 03:12:23

Just wanted to say that I am enjoying playing with this window manager and to give a hearty thank you to its creator. Even coming from Ratpoison, there is a bit of a learning curve, but I am starting to grok it.

Cheers!

milomouse · 2014-02-02 20:53:40

Not sure if I'm doing something wrong but my mousebinds dont seem to do anything? I never really tried them until now which is why I haven't reported earlier.

Mod=Mod4
herbstclient mouseunbind --all
herbstclient mousebind $Mod-Button1 move
herbstclient mousebind $Mod-Button2 zoom
herbstclient mousebind $Mod-Button3 resize

Pressing and holding Mod4 (Super/Win key) and then left-clicking (or right-clicking) on a floating window doesn't do anything. While holding Mod4 + mouse button, I try to move the window around but the mouse pointer simply moves and window stays the same.

For information purposes I'm using herbstluftwm from git and I'm on a laptop with a touchpad (synaptics). Maybe this only works with regular mice and not touchpads? Or do I have to click in a certain spot like window or frame border or something? I tried using example /etc/xdg/herbstluftwm/autostart and also calling mousebind with herbstclient in terminal and still no luck.

The Compiler · 2014-02-03 08:21:00

milomouse wrote:

Not sure if I'm doing something wrong but my mousebinds dont seem to do anything? I never really tried them until now which is why I haven't reported earlier.

That looks right, and I never heard about someone having problems with mousebind.

For me it works with any input device - clitmouse Trackpoint, Touchpad, Wacom-Pen, so that shouldn't be the issue.

Are you sure you're actually on a floating tag? You saying "a floating window" confuses me a bit, as there isn't single window floating in hlwm (yet). Maybe your window is actually pseudotiled?

Flo

milomouse · 2014-02-03 23:42:02

The Compiler wrote:

Are you sure you're actually on a floating tag? You saying "a floating window" confuses me a bit, as there isn't single window floating in hlwm (yet). Maybe your window is actually pseudotiled?

I guess I thought "pseudotile" was considered floating.. but YES the mousebinds work on floating tags. My mistake. I apparently never used the floating command until toggling it today. But, I like tiling so I think I'll settle for no resize/moving of pseudotile for now. I actually forked herbstluftwm the other day so I can mess with some features I like/dislike so maybe I'll help look at this after I get a better feel for the source. Thanks for the quick response as always!

The Compiler · 2014-02-04 05:44:57

milomouse wrote:

I actually forked herbstluftwm the other day so I can mess with some features I like/dislike so maybe I'll help look at this after I get a better feel for the source. Thanks for the quick response as always!

I really hope you mean cloned and not forked, or at least forked in that weird github way, but not "I made my own herbstluftwm"

Anyways - resize/moving of pseudotiled windows is a feature request I've heard a few times now, so I'd guess there'll be some people who'd be glad! So feel free to experiment, and if you need any help regarding development, drop by in #herbstluftwm on Freenode. We really need more devs!

Flo

milomouse · 2014-02-05 00:14:39

The Compiler wrote:

I really hope you mean cloned and not forked, or at least forked in that weird github way, but not "I made my own herbstluftwm"

I meant the github term of "fork". I guess I should clarify anywhere I mention this. Haha.

The Compiler wrote:

Anyways - resize/moving of pseudotiled windows is a feature request I've heard a few times now, so I'd guess there'll be some people who'd be glad! So feel free to experiment, and if you need any help regarding development, drop by in #herbstluftwm on Freenode. We really need more devs!

Well, I work a short work-week but long hours but this also means I have a longer weekend, so on my days off I can continue looking over hlwm code (among other things). I'll be sure to channel over Freenode if I run into anything or simply want to talk about this wonderful WM.

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.

Last edited by milomouse (2014-02-05 02:06:54)

Arch Linux

#351 2013-12-06 18:25:22

Re: herbstluftwm

#352 2013-12-07 12:04:07

Re: herbstluftwm

#353 2013-12-07 13:02:00

Re: herbstluftwm

#354 2013-12-07 13:06:10

Re: herbstluftwm

#355 2013-12-07 13:10:46

Re: herbstluftwm

#356 2013-12-07 13:31:49

Re: herbstluftwm

#357 2013-12-07 14:37:08

Re: herbstluftwm

#358 2013-12-07 16:28:01

Re: herbstluftwm

#359 2013-12-08 11:04:10

Re: herbstluftwm

#360 2013-12-08 16:00:33

Re: herbstluftwm

#361 2013-12-24 16:57:49

Re: herbstluftwm

#362 2013-12-24 22:04:15

Re: herbstluftwm

#363 2014-01-09 16:47:51

Re: herbstluftwm

#364 2014-01-09 20:03:12

Re: herbstluftwm

#365 2014-01-09 20:13:10

Re: herbstluftwm

#366 2014-01-18 01:40:23

Re: herbstluftwm

#367 2014-01-18 16:08:44

Re: herbstluftwm

#368 2014-01-20 09:31:20

Re: herbstluftwm

#369 2014-01-20 22:09:26

Re: herbstluftwm

#370 2014-01-22 03:12:23

Re: herbstluftwm

#371 2014-02-02 20:53:40

Re: herbstluftwm

#372 2014-02-03 08:21:00

Re: herbstluftwm

#373 2014-02-03 23:42:02

Re: herbstluftwm

#374 2014-02-04 05:44:57

Re: herbstluftwm

#375 2014-02-05 00:14:39

Re: herbstluftwm

Board footer