Openbox application position setting not working as expected

icetonic · 2011-08-24 18:49:43

Recently I started using two monitors with TwinView and wanted to configure OpenBox to open specific applications on specific monitors...

The weird thing is - if I use

<position>
<monitor>2</monitor>
</position>

it has no effect, the window is opened on my primary monitor anyway..

It only works when I also add x- and y-coordinates... Then it appears on the correct monitor.

But I don't want the coordinates for all windows of that type fixed (like opening 5 xterms on the same spot), but just make them appear on the specified monitor, at some free place (as it works usually)...

Is this a bug in openbox or is there at least some way to set a coordinate-range where the window can open? This would be acceptable as well..

MoonSwan · 2011-08-24 22:22:45

I don't know about the co-ordinate range but I do know that your twinview desktop is seen by X as one big desktop, essentially a desktop with both monitor's resolutions squashed together. For example, I too run twinview and my combined "resolution" is roughly 3600 x 2250 [1920+1680=width and 1200 + 1050=height ... my monitors are not the same sizes unfortunately]. In short, no twinview doesn't have a bug.

What you can do, and I have done in the past, is run separate X sessions on each monitor. The advantage of this approach is you can configure both monitors very differently, IE one could be in landscape mode with the other is in portrait mode. I used to run a game on my primary monitor and irc sessions on the other one while I played. Worked great!

Edit: See the 3rd post (BurntShusi) explanation about how twinview and separate monitors works. He summed it all up far more precisely that my clumsy post above.https://bbs.archlinux.org/viewtopic.php?id=116502

Last edited by MoonSwan (2011-08-24 22:35:01)

icetonic · 2011-08-25 13:12:30

Thanks for your suggestion...

I do know that X kinda treats it as one huge screen, but somehow OpenBox still seems to know that there are 2 "viewports" and as I said, it works fine if I specify coordinates (which are MONITOR-RELATIVE by the way - setting it to 0,0 without telling which monitor is meant moves the window to 0,0 of the monitor the window is on)...
And I suspected an OpenBox bug, not a TwinView bug

About 2 independent X sessions... then it would be not possible to drag windows from one screen to the other... or do the OpenBox sessions play so extremely nicely together? Because being able to move a window at any time to any monitor is for me kind of the main feature of multi-monitor setups...

Last edited by icetonic (2011-08-25 13:15:01)

BurntSushi · 2011-08-25 15:39:40

Openbox is Xinerama aware (and therefore, TwinView aware). X may see two monitors as one big desktop, but that is of no consequence. Openbox will see them as two separate monitors.

I don't have time at the moment to recreate your bug or dig into Openbox's code, but I will say that window placement is not a simple task. There are many factors at work, and it can be rather difficult to nail down how an application is placed. (This includes hints that are set by your terminal...)

My first suggestion is that you make sure you have an up-to-date configuration file. If you've been using Openbox for a long time, it's likely that there are a few inconsistencies between yours and a more recent one.

My second suggestion is to try

<position force="yes"><monitor>2</monitor></position>

My third suggestion is to play with the settings in the '<placement>' section of your rc.xml file.

My fourth suggestion is to try my own variation of Openbox called Openbox Multihead. It won't solve your problem directly, but it is more monitor-centric. For example, you could focus your second monitor and any windows you open will open on that monitor. /shameless plug

Last edited by BurntSushi (2011-08-25 15:39:54)

icetonic · 2011-08-25 17:46:42

Thanks for your detailed answer.

To your first three suggestions - I tried (and now retried) all of them, unfortunately none of those worked..

It really seems odd that I cant set just the monitor for the application start, but at least this is working:

    <keybind key="C-Left">
      <action name="MoveResizeTo">
          <monitor>prev</monitor>
      </action>
    </keybind>
    <keybind key="C-Right">
      <action name="MoveResizeTo">
          <monitor>next</monitor>
      </action>
    </keybind>

At least this way I can quickly move windows between monitors without having to drag them with the mouse...

Openbox Multihead sounds interesting, maybe I'm going to try this one..

UPDATE: I tried it and and pleasently surprised! (And it fixes my problem) But I do find it a bit confusing how the workspaces are assigned to monitors..

And I don't understand how it is determined which monitor is the "active" one when I change desktops. Currently, I have to click a window or the background of the monitor I want to have focused, if I don't, it often does strange things.
For me it would be more intuitive if the monitor the mouse is currently inside would change workspaces, not the one with an active window (?).. it would be great to have this as an option (I guess that is what FocusRoot is for but I can't imagine how to apply it the way I want it to behave (focus monitor on mouse move or something))..

Also, I'd like to have an option to set default monitor-> workspace settings (like start up with monitor 1 with workplace 1 and monitor 2 with workplace 4)... or even better would be if each monitor would have an own set of workspaces, which normally do not interfere with each other and add a command so "swap" 2 workspaces from 2 different monitors, that means expanding the workplaces into the 2nd dimension. I think such an "isolation" would make it a lot easier to use - being able to move windows wherever I want while still having the monitors clearly as seperate entities... I hope you get the idea

Well, this are just my 2 cents and I'm really looking forward to the next releases! If I had such deep C skills, I maybe would even try to implement some of this myself

Last edited by icetonic (2011-08-25 18:25:36)

BurntSushi · 2011-08-26 01:42:02

icetonic wrote:

UPDATE: I tried it and and pleasently surprised! (And it fixes my problem)

Thanks for trying :-) I don't know of many people using it yet, but it's cool to know some people are trying it.

icetonic wrote:

But I do find it a bit confusing how the workspaces are assigned to monitors..

The main selling point of Openbox MH is that it changes the desktop model from "one and only one desktop viewable at a time" to "one desktop viewable for each active monitor."

icetonic wrote:

And I don't understand how it is determined which monitor is the "active" one when I change desktops. Currently, I have to click a window or the background of the monitor I want to have focused, if I don't, it often does strange things.

Here are some keybindings that I use to change the monitor focus:

<keybind key="A-w">
      <action name="FocusRoot">
        <monitor>1</monitor>
        <pointer><x>0</x><y>0</y></pointer>
      </action>
    </keybind>
    <keybind key="A-e">
      <action name="FocusRoot">
        <monitor>2</monitor>
        <pointer><x>0</x><y>0</y></pointer>
      </action>
    </keybind>

'Alt-w' will now move focus to the first monitor and move the mouse to the top left corner. (You can remove the '<pointer>...</pointer>' parts if you don't want to move the mouse.)

Whichever monitor the currently active window is on is the focused monitor. If there aren't any windows, then you can change focus via "FocusRoot". There really isn't a way to visibly tell which monitor is active though. You'll need my pager for that :-)

Truthfully, Openbox MH is only barely usable without my pager. Namely, switching desktops in the old way (go to "next desktop") is really weird.

Also, the weirdness may increase if you have 'greedy' enabled.

If you know some Python, my pager can be heavily customized. The big thing lacking is documentation; it's something I really need to work on. But I can give answers to any specific questions you may have.

icetonic wrote:

For me it would be more intuitive if the monitor the mouse is currently inside would change workspaces, not the one with an active window (?).. it would be great to have this as an option (I guess that is what FocusRoot is for but I can't imagine how to apply it the way I want it to behave (focus monitor on mouse move or something))..

You're the second person to ask for that (and the second person I know of to try Openbox MH lol). I absolutely plan on adding this if it's feasible. It would be an option since I wouldn't want it It actually should be fairly easy, I just have to find a few hours of free time...

icetonic wrote:

Also, I'd like to have an option to set default monitor-> workspace settings (like start up with monitor 1 with workplace 1 and monitor 2 with workplace 4)...

Eh. Perhaps I'll add something to the "<desktops>" section of rc.xml to specify a monitor. (i.e., <names><name monitor="1">1</name><name>2</name><name monitor="2">4</name></names>.) This has lower priority than your other feature request IMO.

icetonic wrote:

or even better would be if each monitor would have an own set of workspaces, which normally do not interfere with each other and add a command so "swap" 2 workspaces from 2 different monitors, that means expanding the workplaces into the 2nd dimension.

This is how i3 works, minus the swapping. Personally, I don't like that. I like having a set of workspaces and being able to choose which monitor to show each workspace on; it gives a lot more freedom. I understand the advantage to your setup though; it makes functions like "next desktop" work more sensibly again. Unfortunately, I view this change as fundamental to the desktop model and probably means that I won't implement it. :-(

icetonic wrote:

Well, this are just my 2 cents and I'm really looking forward to the next releases! If I had such deep C skills, I maybe would even try to implement some of this myself

If you know a little C, I'd actually suggest you check out the Openbox source. If you have some good programming experience and experience with X, you might be able to get somewhere. (Especially by looking at the diffs between Openbox MH and the regular Openbox master branch.)

Honestly though, the best customization is going to be with my pager. It completely changes the way you use and switch desktops. They more accurately represent workspaces, where you can dynamically add or remove them. For example, I like to bind "Ctrl + Alt + a", "Ctrl + Alt + b", ... "Ctrl + Alt + z" to switch to workspaces that have names starting with the corresponding letter. (And will cycle in alphabetical order if there are multiple hits.) This is included by default in my pager. When I want to work on my Haskell webapp for example, I press "Alt + Enter" and my pager's workspace prompt comes up. I type "hask-webapp." Since that workspace doesn't exist, it gets created. Maybe now I want to switch to my email, and I do that by pressing "Ctrl + Alt + m" (since it's on "mail"). Then I can go back to "hask-webapp" with "Ctrl + Alt + h".

If you know some Python, I'd be more then willing to lend a hand if you want to use my pager. The above is only the beginning :-)

icetonic · 2011-08-26 15:57:11

Ok, I installed your pager too... its really quite nice!

Unfortunately I found some things not working... I've already opened Github Issues..

And one question about the config - what is so dangerous about turning the dock flag off while using openbox-multihead? I've done it and experienced no problems (until now at least)..

Last edited by icetonic (2011-08-26 16:15:56)

MoonSwan · 2011-08-26 18:37:18

[off-topic] I have always ♥ your name; made me laugh when I first saw it, and it still does make me smile. [/off-topic]

I've used Pytyle (it was a great app for me because I still don't understand tiling wm's but I want to use one) and it's stil in development isn't it? Now you have MH and a pager! I'm so excited (good gods I sound like a real geek ...) Frankly, the idea of working with so many desktops, and a pager which understands those desktops, makes me a very happy person because that will mean I can let my ADD take over and have free reign on my computer.

Thank you for all of your hard work, it is appreciated.

~Heather/MS

BurntSushi · 2011-08-27 03:39:12

icetonic wrote:

Ok, I installed your pager too... its really quite nice!
Unfortunately I found some things not working... I've already opened Github Issues..

Thanks for trying it out and reporting your issues! I've responded to all of them.

icetonic wrote:

And one question about the config - what is so dangerous about turning the dock flag off while using openbox-multihead? I've done it and experienced no problems (until now at least)..

Well, I believe it's because if it isn't a dock, it will include itself as a window that should be tracked. Which is terrible and only due to pure laziness on my part.

I find it very odd that you haven't experienced any problems. o_0

BurntSushi · 2011-08-27 03:42:06

MoonSwan wrote:

[off-topic] I have always ♥ your name; made me laugh when I first saw it, and it still does make me smile. [/off-topic]

Haha. I got it off a booth at the best hotdog place in the world a number of years ago.

MoonSwan wrote:

I've used Pytyle (it was a great app for me because I still don't understand tiling wm's but I want to use one) and it's stil in development isn't it? Now you have MH and a pager! I'm so excited (good gods I sound like a real geek ...) Frankly, the idea of working with so many desktops, and a pager which understands those desktops, makes me a very happy person because that will mean I can let my ADD take over and have free reign on my computer.

I'm glad you like it. If you know some Python, you can be arbitrarily ADD with the pager by assigning whatever functions you want to any keybindings of your choice. :-)

icetonic · 2011-08-27 12:34:01

Well, even though the pager is not/shouldn't be in the dock, it does not show itself... I've just set dock=False and above=False and do NOT have any special settings in openbox for it (like skipPager or something).. Oo

Either it is still a dock app (which would be a bug), or it works fine without explaination (which is odd, but still a good thing )

BurntSushi · 2011-08-27 13:21:41

icetonic wrote:

Well, even though the pager is not/shouldn't be in the dock, it does not show itself... I've just set dock=False and above=False and do NOT have any special settings in openbox for it (like skipPager or something).. Oo
Either it is still a dock app (which would be a bug), or it works fine without explaination (which is odd, but still a good thing )

I admit that's definitely strange. When you have those settings enabled, could you run `xprop` in a terminal and click on the pager (your mouse will turn to crosshairs after you run the commad). Then copy & paste the output here?

Setting 'dock' to False just means that the window type will be kept at normal instead of 'DOCK', but so long as 'struts' is still True, struts will be set. (Which is what creates the "dock area.")

icetonic · 2011-08-27 14:22:45

xprop does tell something interesting:

_NET_WM_STATE(ATOM) = _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_SKIP_PAGER

SKIP_PAGER is set, but thats nothing that I've set... must be the pager or OpenBox themselves somehow?

I now disabled struts too, it still works fine (to be honest I have no idea what struts is supposed to be and what it has to do with the dock )

Another strange behaviour I noticed is, after moving a workspace to a monitor, then moving it back to the other one, the window size is not quite the same as it was before...

Is it one of your features to scale windows according to monitor resolution? If it is, that's another thing to have a look at..

EDIT:
I experimented and noticed that the windows seem to grow bigger and bigger, when moving workspaces between monitors... seems to be a kind of rounding error somewhere..

And it would be good to have the scaling optional, cause when I move a 100x30 terminal from my 1440x900 monitor to the 1024x768 one and the terminal resizes to 71x26, that is not very useful (especially cause it COULD fit in the correct size)

EDIT2:
I just checked out the new MonitorFollowMouse option... it is AWESOME! Thanks a lot! )

Last edited by icetonic (2011-08-27 23:28:25)

BurntSushi · 2011-08-27 23:53:19

icetonic wrote:

xprop does tell something interesting:
_NET_WM_STATE(ATOM) = _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_SKIP_PAGER
SKIP_PAGER is set, but thats nothing that I've set... must be the pager or OpenBox themselves somehow?
I now disabled struts too, it still works fine (to be honest I have no idea what struts is supposed to be and what it has to do with the dock )

Well, struts is what makes room for the dock

I'm not entirely sure what's going on either, and it's quite possible that other funky stuff was happening when I wrote it was dangerous to disable 'dock'. And certainly, the extent of 'dangerous' is only that Openbox locks up. (Which is not pleasant.)

icetonic wrote:

Another strange behaviour I noticed is, after moving a workspace to a monitor, then moving it back to the other one, the window size is not quite the same as it was before...
Is it one of your features to scale windows according to monitor resolution? If it is, that's another thing to have a look at..
EDIT:
I experimented and noticed that the windows seem to grow bigger and bigger, when moving workspaces between monitors... seems to be a kind of rounding error somewhere..
And it would be good to have the scaling optional, cause when I move a 100x30 terminal from my 1440x900 monitor to the 1024x768 one and the terminal resizes to 71x26, that is not very useful (especially cause it COULD fit in the correct size)

Nice find! I have two 1920x1080 monitors and a 1680x1050 monitor, so the changes in sizes weren't something I caught. (Plus, I use my tiler, pytyle3, which manages most of my window sizes/placement anyway.)

I fixed the problem where windows were growing size. I figured it'd be a rounding error too, but it turned out to be a funky problem related to the difference between the width/height of a client and the width/height of a client plus its decorations.

I also added an option to stop window scaling when workspaces switch monitors to hammer it home. (See README.MULTIHEAD.)

icetonic wrote:

EDIT2:
I just checked out the new MonitorFollowMouse option... it is AWESOME! Thanks a lot! )

Damn you're quick! But yeah, it was as easy as I thought. I still don't like it

I updated the openbox-multihead-git package, so a `yaourt -Syua` should be sufficient.

icetonic · 2011-08-28 10:11:51

Ok, I tested the scaling of the new version - now windows do not grow any longer, BUT: xterms shrink now! And LibreOffice gradually moves upwards (keeping its size, just changing location)

For now I'm turning it off anyway... but I have another feature request - it would be nice to set the scaling on application basis, too! That way I could e.g. stop terminals and other problematic windows from scaling, but allow it for the rest! And the global scaleWindows would just be the default for windows..

I guess probably there will always be some disobedient windows with strange behaviours, you can't take care of all of them, so this might be the easiest solution

Theres also a problem with the monitorFollowMouse feature - after some time / some unknown condition it "deactivates"... the focus stops following the mouse until I do a openbox --restart

I hope I am not a too much annoying tester

Last edited by icetonic (2011-08-28 10:23:25)

Arch Linux

#1 2011-08-24 18:49:43

Openbox application position setting not working as expected

#2 2011-08-24 22:22:45

Re: Openbox application position setting not working as expected

#3 2011-08-25 13:12:30

Re: Openbox application position setting not working as expected

#4 2011-08-25 15:39:40

Re: Openbox application position setting not working as expected

#5 2011-08-25 17:46:42

Re: Openbox application position setting not working as expected

#6 2011-08-26 01:42:02

Re: Openbox application position setting not working as expected

#7 2011-08-26 15:57:11

Re: Openbox application position setting not working as expected

#8 2011-08-26 18:37:18

Re: Openbox application position setting not working as expected

#9 2011-08-27 03:39:12

Re: Openbox application position setting not working as expected

#10 2011-08-27 03:42:06

Re: Openbox application position setting not working as expected

#11 2011-08-27 12:34:01

Re: Openbox application position setting not working as expected

#12 2011-08-27 13:21:41

Re: Openbox application position setting not working as expected

#13 2011-08-27 14:22:45

Re: Openbox application position setting not working as expected

#14 2011-08-27 23:53:19

Re: Openbox application position setting not working as expected

#15 2011-08-28 10:11:51

Re: Openbox application position setting not working as expected

Board footer