You are not logged in.
The man page is wrong. Vertical is 1, not 0.
Offline
Thanks for the quick answer! I'll try that as soon as I get home (which I won't until ~16:30 - damn german class)
Offline
Ok, now I've got problem. I set my default frame layout to vertical with
hc set default_frame_layout 0
in my autostart file, but I still get a horizontal layout as default.
the problem probably is, that it only affects _new_ frames from now on. You can check it by splitting a frame manually and check which algorithm is used to layout the things in the _new_ frame (not the one where focus stays!)
The man page is wrong. Vertical is 1, not 0.
I don't think so:
Vertical means: below/above each other.
Horizontal means: right/left to each other
Offline
When I read "vertical," I think of vertical columns/dividing windows vertically, and when I read "horizontal," I think of horizontal bars/dividing windows horizontally. I believe most people will understand the terms this way, but it is your party, and you're certainly entitled to name things in whatever way makes the most sense to you, so long as the rest of us know.
But it's good to know that this is your naming system. I was wondering myself why I couldn't figure out what the dump data meant. Makes a lot more sense now.
Offline
Doomcide wrote:Ok, now I've got problem. I set my default frame layout to vertical with
hc set default_frame_layout 0
in my autostart file, but I still get a horizontal layout as default.
the problem probably is, that it only affects _new_ frames from now on. You can check it by splitting a frame manually and check which algorithm is used to layout the things in the _new_ frame (not the one where focus stays!)
Ok I see. Do you plan to change this?
ninjaaron wrote:The man page is wrong. Vertical is 1, not 0.
I don't think so:
Vertical means: below/above each other.
Horizontal means: right/left to each other
Ok I thought the same way aaron did, but now that I know your "interpretation" it's cool
Offline
thorsten wrote:Doomcide wrote:Ok, now I've got problem. I set my default frame layout to vertical with
hc set default_frame_layout 0
in my autostart file, but I still get a horizontal layout as default.
the problem probably is, that it only affects _new_ frames from now on. You can check it by splitting a frame manually and check which algorithm is used to layout the things in the _new_ frame (not the one where focus stays!)
Ok I see. Do you plan to change this?
Hm This is dificult. Consider the following situation:
I have two frames with layout 0, and the default layout is 0. now i change the default layout from 0 to 1. now i can't know whether the existing frames have "layout 0" or "default layout", so i can't know which frame layouts i have to change from 0 to 1.
But it would be possible to provide a script to change every frame with layout 0 to a frame with layout 1
thorsten wrote:ninjaaron wrote:The man page is wrong. Vertical is 1, not 0.
I don't think so:
Vertical means: below/above each other.
Horizontal means: right/left to each otherOk I thought the same way aaron did, but now that I know your "interpretation" it's cool
now it is documented in the man page (it wasn't before).
Btw: There are many problems when using "vertical" and "horizontal" with certain actions.
e.g. there are many different implementations in image manipulation programs about the action "flip vertically" and "flip horizontally"
Offline
Offline
@ thorsten: Shouldn't the default layout apply to all frames initially?
because of the fact that everything is configured at runtime, the time "initially" does not exist.
But I will implement it, so that the layout is applied to all frames.
A solution would be: set the default layout very early in your autostart file (before creating the tags!). so you would only need to change the layout of your first tag manually:
herbstclient load ${TAG_NAMES[0]} '(clients vertical:0)'
Offline
When I read "vertical," I think of vertical columns/dividing windows vertically, and when I read "horizontal," I think of horizontal bars/dividing windows horizontally.
Yes. Both interpretations of "vertical" somehow make sense. I only hat the developer's view: in horizontal layout I leave the y-coordinate unchanged but only change x (and in vertical layout it's vice versa)
I believe most people will understand the terms this way, but it is your party, and you're certainly entitled to name things in whatever way makes the most sense to you, so long as the rest of us know.
But it's good to know that this is your naming system. I was wondering myself why I couldn't figure out what the dump data meant. Makes a lot more sense now.
I think the most important thing is, that it is documented now (instead of before...)... (and I am happier with the current behaviour )
Offline
I think the most important thing is, that it is documented now.
We may not agree on the meaning of 'vertical' and 'horizontal' with reference to window arrangement, but at least we agree on this.
P.S. Your comma usage is totally German. Everything about you and your WM is so German, and I mean that in a good way. Was deutsch ist, ist auch mir gut. Alles ist systematisch und... 'thoroughgoing,' as we say in English.
Offline
Offline
I would like there to be a way to make new windows fullscreen by default. I don't need a visible border or frame when there is only one window on the screen or a number of windows fullscreen.
Offline
I would like there to be a way to make new windows fullscreen by default. I don't need a visible border or frame when there is only one window on the screen or a number of windows fullscreen.
Do you mean something like:
hc rule fullscreen=on # Warning: not implemented yet ;)
hc rule class=XTerm fullscreen=on # warning: --^
Or something like in xmonad, where the border only is visible if there are at least two windows?
Offline
I can't seem to get xinerama with nvidia drivers working. Is there anything special needed to be done? I've configured it with separate X screens and xinerama enabled, which should be exactly the same as I used to do with xmonad. Right now herbstluft is reporting one big screen rather than two separate.
Offline
I can't seem to get xinerama with nvidia drivers working. Is there anything special needed to be done? I've configured it with separate X screens and xinerama enabled, which should be exactly the same as I used to do with xmonad. Right now herbstluft is reporting one big screen rather than two separate.
There is no Xinerama or xrandr support yet, because you can choose your monitors completely manual:
you can setup the monitors like this in your autostart:
hc remove_monitor 1
hc move_monitor 0 1280x1024+0+0
hc use "${TAG_NAMES[0]}"
hc add_monitor 1280x1024+1280+0 "${TAG_NAMES[1]}"
This would be the code to setup two monitors with a resolution of 1280x1024. The format for the monitor geometry is: WIDTHxHEIGHTxHORIZONTALOFFSETxVERTICALOFFSET. This means that you can setup multiple monitors, even if you just have one large monitor (e.g. a strange 22inch screen with 1920x1600 pixels).
So it actually is a feature: setup monitors independet from real monitors, xrandr, xinerama,...
Offline
Or something like in xmonad, where the border only is visible if there are at least two windows?
Yes, that would be awesome (no pun intended!) .
Even if there were options where I could code the desired behaviour myself in the config that would be fine. I have musca set up so workspaces and the windows opened in them are borderless by default (if there are no splits). Borders are only turned on when there is a split. When all splits are removed, the windows go back to being borderless. This is all done using hooks and it works great for me.
Offline
thorsten wrote:Or something like in xmonad, where the border only is visible if there are at least two windows?
Yes, that would be awesome (no pun intended!) .
Even if there were options where I could code the desired behaviour myself in the config that would be fine. I have musca set up so workspaces and the windows opened in them are borderless by default (if there are no splits). Borders are only turned on when there is a split. When all splits are removed, the windows go back to being borderless. This is all done using hooks and it works great for me.
If you want to remove the border (and the window_gap) of a certain client (and its frame) then the only way is to put the client to fullscreen (so it filles the entire monitor and also covers the panel). I don't think that it is currently scriptable easily. But it is similar to ninjaaron's gap-scripts: https://bbs.archlinux.org/viewtopic.php … 1#p1005411
Offline
There is no Xinerama or xrandr support yet, because you can choose your monitors completely manual:
you can setup the monitors like this in your autostart:hc remove_monitor 1 hc move_monitor 0 1280x1024+0+0 hc use "${TAG_NAMES[0]}" hc add_monitor 1280x1024+1280+0 "${TAG_NAMES[1]}"
This would be the code to setup two monitors with a resolution of 1280x1024. The format for the monitor geometry is: WIDTHxHEIGHTxHORIZONTALOFFSETxVERTICALOFFSET. This means that you can setup multiple monitors, even if you just have one large monitor (e.g. a strange 22inch screen with 1920x1600 pixels).
So it actually is a feature: setup monitors independet from real monitors, xrandr, xinerama,...
I sort of got this working using twinview, but as far as I know twinview doesn't allow me to rotate one of the monitors (I have it rotated 90 degrees). I found a way to do this with separate X screens and xinerama, but then obviously herbstluftwm wouldn't work correctly... Maybe I'll try nouveau and see if I get that working. EDIT: Just tried nouveau, and it's not working well, so I'm going to have to stick with nvidia. Any plans for implementing xinerama support? A deal breaker if I can't get my second monitor going...
Last edited by sablabra (2011-11-05 13:41:34)
Offline
I sort of got this working using twinview, but as far as I know twinview doesn't allow me to rotate one of the monitors (I have it rotated 90 degrees). I found a way to do this with separate X screens and xinerama, but then obviously herbstluftwm wouldn't work correctly... Maybe I'll try nouveau and see if I get that working. EDIT: Just tried nouveau, and it's not working well, so I'm going to have to stick with nvidia. Any plans for implementing xinerama support? A deal breaker if I can't get my second monitor going...
Did you get it work with any other window manager? if yes, stay at this setup and just replace the windowmanager by herbstluftwm and then setup the monitors manually with the add_monitor and move_monitor command. You don't need Xinerama-Support in hlwm for this.
Offline
Ok, had another herbstluftwm revelation today. I wanted to do a new theme, but I didn't want to ditch my old one. I did a script that changes my settings, and I can run it whenever I want this theme. I also use rxvt-unicode for my terminal, and all the settings can be set from the launch command, so I redefined my terminal launch commands right in the script with entirely new color schemes.
It occurs to me that I could do this lots of times to create lots of new schemes that can be interchanged simply by running a script.
Anyway, this is the result (can you guess what I was going for? ):
and this is the script I used to change my settings:
#!/bin/bash
#changing herbstluft settings
herbstclient set frame_border_width 0
herbstclient set window_border_normal_color '#040404'
herbstclient set window_border_active_color '#91ff91'
herbstclient set window_gap 0
#stuff to reconfigure conky
echo 4 > ~/.config/herbstluftwm/conkyconf
if [ `cat ~/.config/herbstluftwm/conkon` = 1 ];then
~/bin/conksel
fi
#stuff to change the theme for dmenu and my terminals
herbstclient keybind Mod4-d spawn dmenu_run -i -fn -*-bitocra -nb '#040404' -nf '#5ec95e' -sb '#aaffaa' -sf '#1e1e1e'
herbstclient keybind Mod4-Return spawn urxvtc -fg rgb:5e/c9/5e -bg rgb:04/04/04 --color0 rgb:33/77/33
herbstclient keybind Mod4-Alt-Return spawn urxvtc -fg rgb:5e/c9/5e -bg rgb:04/04/04 --color0 rgb:33/77/33 --color1 rgb:5e/c9/5e --color2 rgb:5e/c9/5e --color3 rgb:5e/c9/5e --color4 rgb:5e/c9/5e --color5 rgb:5e/c9/5e --color6 rgb:5e/c9/5e --color7 rgb:5e/c9/5e --color8 rgb:91/FF/91 --color9 rgb:91/FF/91 --color10 rgb:91/FF/91 --color11 rgb:91/FF/91 --color12 rgb:91/FF/91 --color13 rgb:91/FF/91 --color14 rgb:91/FF/91 --color15 rgb:ff/ff/ff
This script also changes my conky settings. I switched from dzen2 to strait-up conky, but `~/bin/conksel` is based on `~/bin/dzen` in the second post.
Last edited by ninjaaron (2011-11-06 15:40:51)
Offline
Did you get it work with any other window manager? if yes, stay at this setup and just replace the windowmanager by herbstluftwm and then setup the monitors manually with the add_monitor and move_monitor command. You don't need Xinerama-Support in hlwm for this.
I must've been doing something else wrong, because I got it working right away now.
One thing I haven't found is how to send a window to a specified monitor. Or rather; send a window to the tag currently displayed on the specified monitor. Is there such an option?
Last edited by sablabra (2011-11-06 22:30:59)
Offline
thorsten wrote:Did you get it work with any other window manager? if yes, stay at this setup and just replace the windowmanager by herbstluftwm and then setup the monitors manually with the add_monitor and move_monitor command. You don't need Xinerama-Support in hlwm for this.
I must've been doing something else wrong, because I got it working right away now.
One thing I haven't found is how to send a window to a specified monitor. Or rather; send a window to the tag currently displayed on the specified monitor. Is there such an option?
If you mean automatically assigning windows to a new tag when they spawns based on class, then yes there is. You need to use the `rule` flag with herbstclient. The man page has a good section on rules with examples of exactly what you want to do.
Last edited by ninjaaron (2011-11-07 00:35:55)
Offline
One thing I haven't found is how to send a window to a specified monitor. Or rather; send a window to the tag currently displayed on the specified monitor. Is there such an option?
No, that's not possible yet. But currently I don't know why you need this. Per default new clients spawn on the current monitor on the current tag. you could always assign a special tag to this monitor (by only showing this tag on the monitor) and add a rule that moves some clients to this tag. (This would be a workaround if you don't need multiple tags on that extra-Monitor)
Offline
No, that's not possible yet. But currently I don't know why you need this. Per default new clients spawn on the current monitor on the current tag. you could always assign a special tag to this monitor (by only showing this tag on the monitor) and add a rule that moves some clients to this tag. (This would be a workaround if you don't need multiple tags on that extra-Monitor)
It's more of a habit from xmonad. Often I just want to send a window to another monitor without having to bother checking what tag is displayed there. E.g in xmonad I used these keybindings:
- Mod-w Switch focus to monitor x
- Mod-Shift-w Send window to the tag currently displayed on monitor x
Not really that big of a deal, but if it's a quick implementation then maybe...?
Offline
It's more of a habit from xmonad. Often I just want to send a window to another monitor without having to bother checking what tag is displayed there. E.g in xmonad I used these keybindings:
- Mod-w Switch focus to monitor x
- Mod-Shift-w Send window to the tag currently displayed on monitor xNot really that big of a deal, but if it's a quick implementation then maybe...?
That's something different. This is easy:
This is a script that sends a window to monitor that is passed as parameter:
tag=$(herbstclient list_monitors | grep "^$1: "|cut -d'"' -f2)
herbstclient move "$tag"
This is the keybinding to switch to monitor $w
for i in $( herbstclient list_monitors | cut -d':' -f1 ) ; do
herbstclient keybind $Mod-$i focus_monitor $i
done
Offline