[openbox] Multiple screens not considered correctly in Openbox-3.0-rc3
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
> > 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:
> 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)"
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