[openbox] Multiple screens not considered correctly in Openbox-3.0-rc3

Kacper Wysocki kacperw at online.no
Sun Oct 12 10:06:58 EDT 2003

On 10/10/03 12:13:20, Ben Jansens wrote:
> > three days of hearing of it. Or is it a pure cut-n-paste job? ;-)

> Err, no, our code is not similar at all.

Sorry, just kidding.

> > Um, I assume a developer for a xinerama-supporting window manager
> uses
> > xinerama on a daily basis for his work?
> Nope, I would if I had any money with which to throw at a second
> monitor. I can borrow a monitor for testing purposes however, and did  
> to write it all.

That's too bad- still, openbox supports xinerama as well as, or better  
than, larger window manager projects out there, so props to ya!
CRT's have decreased in price considerably, and a decent used one  
should cost roundabout $80US- I wish I could donate, but I'm a poor  
student myself :( I'll look into it, maybe if I get a couple of friends  
together we'll get you an extra monitor eventually.
Did you know reasearch shows working on multiple screens increases your  
productivity, as featured on slashdot:

>> Docklets-in-Deadzones:
> Hm Im not sure what I should do about that. Filling only one head  
> with the desktop doesn't seem a right approach.

Well, the mouse has no problems staying out of the deadzone. Isn't  
there a way to keep launchers and docks out of there as well? I do know  
that the XFree86 people are slow at developing X, is this one of the  
things they never did? My only work-around for now has been to move my  
launcher from the bottom to the top of the screen. There might be a way  
of moving the deadzone to the top using XF86Config-4, but I don't know  
what that might be, and that still wouldn't solve the deadzone problem,  
merely work around it.

> Well, Openbox maximizes on one head.
> It is probly a few pixels over onto the primary or something. That
> code could use more intelligence.

Yes, a window will maximise to the primary if it's got a couple of  
pixels on it. This occurs consistently, and is mildly(read: not so  
mildly) annoying. I'm not sure anymore, but I think I saw it happening  
for other cases as well. I'll look some more into it. More intelligent  
behavior would be to maximise over whichever screen the larger part of  
the app was on, but being a novice programmer myself a I know that a  
special case would have to be considered if the app was exactly half- 
on-half on two screens (or possibly divided into four over four  
screens, if one had a sick setup)- in that case it should maximise over  
the screen containing the maximise button.

I'm also having trouble with new windows randomly choosing which screen  
they want to display on. It seems as if they open on the screen with  
the least clutter(?), but it's impossible to predict which screen a new  
window will open on. Key commands that launch windows have this problem  
too. A good (but not perfect) solution to this problem would be to  
launch the window onto whichever screen the mouse happens to be on, as  
that's likely to be the screen your attention is focused on. It's still  
nice to see a large window open on screen 2 if screen 2 is empty and  
screen 1 already has a bunch of or one maximised window on it.

Splash screens for applications such as xine, drscheme and openoffice  
will invariably show up in the middle of the desktop, half on the  
primary and half on the secondary screen. It's not extremely important,  
and most probably hardcoded into the apps themselves, but it'd look a  
whole lot better if these showed up in the middle of whatever screen  
the app itself plans to launch on (see paragraph above). It's not  
terribly important mainly because splashscreens aren't terribly useful  
(and in fact do not look like they are windows at all).

> > At least 4 out of 5
> > times openbox will crash if I fullscreen, then restore, then
> > fullscreen again a movie in xine, colorfully stating:
> > "Fuck yah. Core dump. (Signal=11)"
> http://openbox.org/bugs.php

Got your hint. Will do as soon as I've gathered enough information to  
give a useful bug report. LOL to the error message!


More information about the openbox mailing list