You are not logged in.
This is totally awesome, but be sure to make the syntax resembles either C or Bash, as those are the "native languages" of herbstluftwm, so to speak.
That was my first thought. But ... math, string maniupulation, even internal variables are outside the scope of this proposed language. So I though it might make more sense to make the syntax more similar to logical languages. A colon doesn't assign a variable. It simply gives a statement a name.
Anyways, off track. My reason for responding is because I bagged that idea anyway (see progress below on the bash version of herbstlogic)...
Other thought: it would be ideal if, like herbstluftwm, there was a convenient way to use this proposed program as part of a shell script, rather than having to play in its own sand box. Whatever you make, I assume it will not be as powerful as existing shell languages. I'm having trouble visualizing how that would be implemented, but I'll leave that to the CS majors to figure out.
Other other thought: the ultimate evolution of this idea must inevitably be the server-side implementation; that is, this functionality built into herbsluftwm itself, so you could run a command like this:
[...]
Not that this has to be the exact syntax (or that these specific commands would do anything anyone would ever consider useful), but you see where I'm going with this. This should ultimately become a feature hlwm, rather than a weird hacky program to create mad-science-esque chain/and/or commands. If that seems too ambitious at this point, at least work on the project with that eventuality in mind.
I completely agree with the sandbox thing. I soon realized that without math, variables, or really -anything-, doing pre-parsing of user settings and such would be a pain. We'd have to use a different dereference symbol for herbstlogic junction names, and use the $names of bash variables or something for mutable data, and then let bash do the parsing and substitutions before sending it off to herbstclient for binding. Not very efficient, especialy when I can just use bash to do the same thing.
The thing is, the syntax in my bash script-script is, yeah, hackish. So I've been thinking of solutions.
This is what I just whipped up in bash:
───|$ cat example
#! /bin/bash
source ~/.herbs/herbstlogic
# one, two, three, and four are just bash variable names, which hold
# a junction string.
### Junctions
hl one "foo & bar"
# Another way to write it.
hl two "
baz |
$one |
qux "
### If statements
hl three if "$one" then "$two" else "fez"
# Another way to write it.
hl four \
if \
"$one" \
then \
"$two" \
else \
fez
herbstclient $four
I personally think that is clear enough syntax to put my my proposed scripting language on hold and just work on 'query'. It completely hides the mad science too (for better or worse) and its completely functional. All I need to do is to make another function to parse a script file (maybe using context to make if/thens possible on seperate lines, and get ride of all the quotes), pass each line to "hl," and let bash take care of all the substitution.
I'll edit my post above with the new herbstlogic script, and the modified 'swap' script as well, which should serve as a better demonstration.
[edit] This post ended up on a new page, so I'll leave my old post for prosperity, and just link the herbstlogic script here and the swap script here.
[edit2] Added added a lock/unlock combo to each command. While it improving performance is a 'duh' thing, I'm surprised it sped up the execution as much as it did. Noted.
Is anyone else having trouble using 'close' in a chain? I'm not sure if this is a bug, intentional, or just looked over...
Last edited by wretch (2012-12-04 05:56:45)
Offline
Rather than inventing a new language for herbstluftwm, why not just make a herbstclient-like library which can then be used in other languages like C or Python (with ctypes)?
I think that's actually what was on thorsten's radar as soon as he has time.
>>> from __future__ import braces
File "<stdin>", line 1
SyntaxError: not a chance
Offline
Rather than inventing a new language for herbstluftwm, why not just make a herbstclient-like library which can then be used in other languages like C or Python (with ctypes)?
I think that's actually what was on thorsten's radar as soon as he has time.
This. Bindings for the win. I'd love to be able to fiddle my herbst without resorting to Python's subprocess module (or anything like it).
Offline
The Compiler wrote:Rather than inventing a new language for herbstluftwm, why not just make a herbstclient-like library which can then be used in other languages like C or Python (with ctypes)?
I think that's actually what was on thorsten's radar as soon as he has time.This. Bindings for the win. I'd love to be able to fiddle my herbst without resorting to Python's subprocess module (or anything like it).
I actually tried to do a native implementation of herbstclient in Python, but I use Python3 only and couldn't port python-xlib to Python3 because of some pretty sick self-modifying code, so after a few days I gave up with that approach.
>>> from __future__ import braces
File "<stdin>", line 1
SyntaxError: not a chance
Offline
Sorry for the double post, just noticed I didn't reply to that yet.
@The Compiler
I finally compiled your sig and my mind was blown. What is it?
It's a Mandelbrot fractal. I believe I stole the sig from this page with mandelbrot signatures.
Flo
>>> from __future__ import braces
File "<stdin>", line 1
SyntaxError: not a chance
Offline
I actually tried to do a native implementation of herbstclient in Python, but I use Python3 only and couldn't port python-xlib to Python3 because of some pretty sick self-modifying code, so after a few days I gave up with that approach.
You got further than I did - I took a look at Python-Xlib and gave up on the spot.
Offline
Rather than inventing a new language for herbstluftwm, why not just make a herbstclient-like library which can then be used in other languages like C or Python (with ctypes)?
I think that's actually what was on thorsten's radar as soon as he has time.
I agree and think bindings would be a great idea. However, that's not the point.
The point of a c lib would be to extend the current client-server model, correct? This is a good thing, and the client-server model is one of the main reasons why I love this wm. The point of my last few posts though was to expose the internal scripting language of the window manager with the introduction of 'and' and 'or'. This bypasses the client-server model (except to 'load scripts', you still need to use a client), which has its own advantages (speed, low number of processes, low number of ipc calls) and disadvatages (binary [nondynamic] decisions, silly syntax). Silly syntax is what my herbstlogic script seeks to fix, by introducing a metalanguage. This metalanguage 'compiles' to hlwm understandable syntax. (Ps. The syntax for and, or, and chain are actually really straight forward, don't think I'm saying otherwise. But keeping track of seperators is cumbersome, and the creation of junctions allows easy substitution.)
Ultimately, what would be the most powerful thing to do is to create libs for herbstlogic in C that work along side libs for herbstclient in C. This, unfortunately, would still involve a 'metalanguage' (string manipulation functions to create junctions) and a 'compiler' (in the form a function that passes junctions to the herbstclient functions), but how much of that process needs to be known to the programmer using the library depends on how it's implimented.
Of course, if you mean building an interpreter for an already existing scripting language into the window manager itself (to bypass ipc), that's a different story. I don't know if I would like that, it kinda goes against the philosophy of the project (if such a philosophy exists). Herbsclient bindings = good. Herbstluftwm interpreter = bad?
[edit]
Upon further thought, if we wrote a c library that parses dump, then dynamically applied keybindings with existing junctions depending on the current layout, that would only take 1.5 ipc calls (a call being bidirectional, a request then response, assuming we don't care about the response of the second hc request). Further, if we get the wm to emit a hook containing the current layout whenever the layout is changed, and then we set an ipc client to idle and respond to layout changes, it would only take one. This would actually be ideal, in my opinion, though initially obfuscated.
[edit2:To avoid the double post]
Is anyone using any kind of dynamic keybindings right now? After my last edit I thought about it and whipped this up quick in bash:
#! /bin/bash
# A (simple) demonstration of using dynamic keybinding.
# This example uses hooks to set the state, then applies
# the keybinding accordingly.
# Note this is NOT equivilent to --
# hc keybind $Mod-v or , focus left , focus right
# -- when there are more than two windows.
Mod=Mod4
herbstclient --idle | while read line ; do
case $line in
*toggle_right*)
herbstclient keybind $Mod-v chain , focus right , emit_hook toggle_left
;;
*toggle_left*)
herbstclient keybind $Mod-v chain , focus left , emit_hook toggle_right
;;
esac
done
I don't think I've seen anyone say anything about it yet, but its definitely useful.
Last edited by wretch (2012-12-04 21:22:43)
Offline
[edit2:To avoid the double post]
Is anyone using any kind of dynamic keybindings right now? After my last edit I thought about it and whipped this up quick in bash:
I don't think I've seen anyone say anything about it yet, but its definitely useful.
I only have dynamic keybindings in the way of keychains http://wwwcip.cs.fau.de/~re06huxa/herbs … 00051.html(please mail me if this link isn't current anymore). The problem is that currently you can't cycle between some custom states without using an external script. I.e. there is no way to cycle between states just using chain and keybind. So your solution is currently the only (and best) one.
Offline
eh, on an unrelated note, any chance you could keep the command `herbstclient close` from exiting until the window actually closes? I suppose this probably has to do with the X server and is outside of hlwm's domain of control, but I have a use for this.
Last edited by ninjaaron (2012-12-06 06:52:53)
Offline
eh, on an unrelated note, any chance you could keep the command `herbstclient close` from exiting until the window actually closes? I suppose this probably has to do with the X server and is outside of hlwm's domain of control, but I have a use for this.
This too has bothered me. However, a workaround that works in many (but not all) cases is just to call close last. For example, in the case of 'swap', that means shifting windows and removing frames first, then focusing the first-focused-window and closing. This is what close in my 'swap' script currently looks like:
hl do_stack_alone "remove , cycle , unlock , close"
hl check_stack_empty if "$query_frame_empty" then "remove" else "unlock , close"
hl do_in_stack if "$query_window_alone" then "$do_stack_alone" else "$check_stack_empty"
hl check_stack "focus -e $stack_dir , $do_in_stack"
hl remove_master "focus -e $master_dir , remove , cycle , unlock , close"
hl new_master "shift -e $master_dir , cycle , unlock , close"
hl check_stack_for_master if "$query_window_alone" then "$remove_master" else "$new_master"
hl do_master_alone "focus -e $stack_dir , $check_stack_for_master"
hl check_no_master_window if "$query_frame_empty" then remove else "unlock , close"
hl do_in_master if "$query_window_alone" then "$do_master_alone" else "$check_no_master_window"
hl close_do_sub if "focus -e $master_dir" then "$check_stack" else "$do_in_master"
hl close_do "lock , $close_do_sub , unlock"
#hc keybind $Mod-r $close_do
...
I only have dynamic keybindings in the way of keychains http://wwwcip.cs.fau.de/~re06huxa/herbs … 00051.html(please mail me if this link isn't current anymore). The problem is that currently you can't cycle between some custom states without using an external script. I.e. there is no way to cycle between states just using chain and keybind. So your solution is currently the only (and best) one.
Aye! Keychains is also an option in many cases too. Thanks for the tip.
An additional solution, and one that I think what would be the most elegant, which doesn't require an external daemon script like my example would be to add a command like 'keybind_swap' which swaps the command for for one keybind with another. (Or 'keybind_copy' which, well, copies the command from a target keybind to the destination).
Then add support for some modifiers that don't actually exist (Mod6, Mod7, ect., or names more exotic since they only exist in hlwm and aren't actually bound to anything) that can be used as 'banks'. Then my script above would work like this:
#! /bin/bash
# A (simple) demonstration of using dynamic keybinding.
# This example uses hooks to set the state, then applies
# the keybinding accordingly.
# Note this is NOT equivilent to --
# hc keybind $Mod-v or , focus left , focus right
# -- when there are more than two windows.
Mod=Mod4
Bank1=Mod6
Bank2=Mod7
herbstclient chain then \
keybind $Bank1-v chain , focus right , keybind_copy $Bank2-v into $Mod-v \
then \
keybind $Bank2-v chain , focus left , keybind_copy $Bank1-v into $Mod-v \
\
then \
keybind-copy $Bank1-v into $Mod-v
Of course, keybind_copy and keybind_swap would have to do their work after the current command chain finishes, to avoid races. Yes, my example above could be implimented using a keychain. But if there were more than two state-action-chains in the bank, you could use [and] and [or] to determine which state to enter. Still, I can't help but wonder if this is possible with (and functionally identical to) keychains (relying on 'substitution' with the windowmanager instead of bash substitution). Am I misinterpretting how keychains work? Could you give me an example of when keychains/this solution don't work?
[edit]Ahh, I see. Toggling states, like the example above, would require a circular reference, and therefore a fixed resolution using the keychain method in your example. I suppose my idea isn't all that bad
[edit2]Adding made-up modifiers is sorta a hackish solution. So I guess I should use hackish methods instead modifying the source (I have mod 3 and 5 unmapped ). I think we could actually add real keybanks, but I gotta study up on GLib.
Last edited by wretch (2012-12-06 23:26:41)
Offline
This too has bothered me. However, a workaround that works in many (but not all) cases is just to call close last. For example, in the case of 'swap', that means shifting windows and removing frames first, then focusing the first-focused-window and closing. This is what close in my 'swap' script currently looks like:
Hmm... I don't have the query command yet (what? you people think I know how to patch source? 8^p ), so I guess I need a way to parse whether or not the window is alone out of the dump... I tried doing some wild stuff with a `herbstclient -i | while read line` to figure out when the frame was empty, which works for windows that don't close immediately, but then if the frame isn't empty, the while loop would stay active and weird things would happen the next time I ran the command and a frame was emptied (both loops would exit at the same time, and command would execute twice... or however many times).
So back to fighting with bash text manipulation it is... perhaps associative arrays are what I need here... God bless bash 4.
Last edited by ninjaaron (2012-12-07 03:22:45)
Offline
Hmm... I don't have the query command yet (what? you people think I know how to patch source?
Its looking like query, or a query-like command, wont be a part of the master branch for some time.
so I guess I need a way to parse whether or not the window is alone out of the dump...
So youve probably found a way to do this by now via parsing, but if your split is horizontal and your layouts (of both master and stack) is vertical (...or vice versa), you can find this out like this:
( focus up && focus down ) || ( focus down && focus up )
...
hc or chk, and 1, focus up 1, focus down chk, and 2, focus down 2, focus up
This will return a nonzero if the current window is alone.
[Edit] ps, if you need the opposite, (alone window returning 0) negation got merged today to the git master.
Last edited by wretch (2012-12-10 01:31:41)
Offline
I have made a little [hook handler for herbstluftwm]. It can launch scripts, binaries, and shell functions to handle hooks sent by the WM.
It handles its own reload hook, so you only have to launch it once per X session. To have it reload when the WM does, add herbstclient emit_hook hook_handler reload (preferably after your reload hook) in your [autostart file].
Offline
I have made a little [hook handler for herbstluftwm]. It can launch scripts, binaries, and shell functions to handle hooks sent by the WM.
Hey, I'm just letting you know that I've been using your script and it works awesome. I'm using it for dynamic keybindings, like the post above, to create modal keybindings for my version of aaron's swap script. (Id share my scripts [functions, actually, good work on that], but alas, my version of swap still relies on my query patch, which isnt gunna be merged upstream . I should depreciate my use of that patch so I can share more... )
I dont know if you've been listening on irc (and this comment is also a heads up for users not on irc), but your question earlier about a spawn-consequence got somewhat solved by your script in conjunction to the hook-consequence that was merged recently. Hopefully it helps
Offline
Is there any step by step tutorials for multi-head support? I am relatively new to hlwm and am having problems getting my laptop scripted to a plug and play like support for multi head. I've been playing around with this idea of adding an if in my autostart and trying to check the output of xrandr to see if the screen is connected (usually I am out and about with my laptop) and if it is set it to 1920x1080+1366+0. What I tend to wind up with is a mess. Interestingly I get the same 1366x768 on both screens and then what I assume is the start of the second monitor on the larger screen so it looks like this
+----------------------------------------+ +-----------------------------------------------------------------------+
| Laptop screen | | Monitor [same image as laptop screen] | Image I think |
| | | | is meant to |
| | | | be my |
| | | | second |
| | | | screen |
| | | | |
| | | | |
+----------------------------------------+ +-----------------------------------------------------------------------+
I've tried to do this about a dozen different ways and lament the idea of posting any code as it would probably not be representative of the majority of my attempts. Not to mention that by this point my configs are so messed up from screwing around with this that after I get it worked out I will have to go in and clean them out.
Thanks in advance
Offline
@lhoffman: Uuuhm, just do "herbstclient detect_monitors" or "herbstclient set auto_detect_monitors 1"?
This should be in since 0.4 I believe.
>>> from __future__ import braces
File "<stdin>", line 1
SyntaxError: not a chance
Offline
@lhoffman: Uuuhm, just do "herbstclient detect_monitors" or "herbstclient set auto_detect_monitors 1"?
This should be in since 0.4 I believe.
I think he is having a different issue than WM-monitor issues.
What I tend to wind up with is a mess. Interestingly I get the same 1366x768 on both screens and then what I assume is the start of the second monitor on the larger screen so it looks like this
+----------------------------------------+ +-----------------------------------------------------------------------+
| Laptop screen | | Monitor [same image as laptop screen] | Image I think |
| | | | is meant to |
| | | | be my |
| | | | second |
| | | | screen |
| | | | |
| | | | |
+----------------------------------------+ +-----------------------------------------------------------------------+
It sounds like you have both monitors set to the same origin (0x0). Is this the output of xrandr? If so, you need to configure your monitors so that your second monitor starts at X coordinate to the right edge of the laptopscreen (1366x0). I prefer to use xrandr for this (though you can do this in your xorg conf).
This is the script I launch in my autostart:
#! /bin/bash
cvt 1280 720
xrandr --newmode "1280x720_60.00" 74.50 1280 1344 1472 1664 720 723 728 748 -hsync +vsync
xrandr --addmode VGA-0 1280x720_60.00
xrandr --output VGA-0 --mode 1280x720_60.00
xrandr --output VGA-0 --pos 1280x80
xrandr --output LVDS --pos 0x0
You can find a guide for this with your own dimensions here. After this, detect_monitors should work. If you need something more robust (I, for example, put trayer on monitor 1 if it exists, otherwise put it on monitor 0), this is the monitor section of my autostart:
if xrandr | grep "VGA-0 disconnected" ; then
hc remove_monitor 1
echo 0 > /tmp/hlwmmm
# Start system tray
killall trayer
trayer --edge top --align right --SetDockType true --SetPartialStrut true --expand true --width 3 --transparent true --tint 0x111111 --height 10 &
else
if [ $(cat /tmp/hlwmmm) != 1 ] || [ "$1" == "forcemon" ]; then
/home/marsh/bin/startup/multimonitor
hc remove_monitor 1
hc move_monitor 0 1280x800+0+0
hc use "${TAG_NAMES[0]}"
hc add_monitor 1280x720+1280+80 "${TAG_NAMES[1]}"
echo 1 > /tmp/hlwmmm
fi
# Start system tray
killall trayer
trayer --edge top --align right --SetDockType true --SetPartialStrut true --expand true --distance 80 --width 3 --transparent true --tint 0x111111 --height 10 &
fi
If this doesn't work, could you maybe post the output of xrandr and maybe a link to your autostart (whatever state it's in)?
Last edited by wretch (2012-12-30 05:12:29)
Offline
Wow, thanks for the quick reply. I am going to fiddle with this some today and if I cant figure out a script of some sort by the end of the day I'll clean up my start scripts and post em.
Thanks again.
Offline
Alright. I was making this way more complicated than it needed to be. I wrote a little script called screens that uses xrandr to check for multi monitors then sets them up through xrandr. I was simply confused because the arch wiki for HLWM for some reason had me feeling like xrandr was not necessary and that all that was necessary was to play wit add_monitors and move_monitors.
Really really enjoying the WM by the way. And it's forcing me to learn bash scripting.
Once I get everything all cleaned up and pretty like I will post a .files on my git.
Offline
herbstluftwm 0.5.0 is out! There are many new commands and settings, some of them are:
Naming of monitors
Chaining of commands using the commands: chain, or, and
More readable error messages
More usefull exit codes for commands (very usefull with the or/and command)
See the NEWS for a full list of new features and changes. If you notice any problems, please report them on herbstluftwm-devel _at_ lists.sourceforge _dot_ net.
I also updated the herbstluftwm PKGBUILD in the AUR.
Offline
0.5.0 introduced environment variables, which made my "use_prev" hook (https://bbs.archlinux.org/viewtopic.php … 9#p1104899) a bit less clumsy. Then 0.5.1 introduced a use_previous command! Really herbstluftwm, for me, is the perfect WM. Thank you so much for all your hard work.
Offline
Hi there.
Thanks for an interesting WM.
Is there a (fixable) reason why fake transparency on i.e. urxvt doesn't work? I tested my .Xdefaults with awesome and everything seems fine. frame_bg_transparency is set (and worx for an empty frame).
foyrkopp
Offline
Is there a (fixable) reason why fake transparency on i.e. urxvt doesn't work? I tested my .Xdefaults with awesome and everything seems fine. frame_bg_transparency is set (and worx for an empty frame).
Pseudo-Transparency in urxvt works without any problems here and the window manager doesn't do anything (because it's *pseudo* transparency = the client reads the pixmap from the root window). Are you sure you activated pseudo-transparency instead of true transparency?
The following is in my .Xdefaults:
URxvt.transparent: true
URxvt.shading: 25
And any true transparency option is disabled (.depth, .inheritPixmap, .reverseVideo).
Offline
Thanks for the quick reply - the problem was definitly on my end, I got it fixed.
foyrkopp
Offline
Is there some sort of event notification that is flagged or triggered when a window enters fullscreen mode?
I'm looking to find a way to disable the screen locker and jiggle the mouse every few minutes to prevent the screen from blacking to save power whenever I go fullscreen and reverse that on exit.
Offline