[openbox] Multiple screens not considered correctly in Openbox-3.0-rc3
ben at orodu.net
Fri Oct 10 12:13:20 EDT 2003
On Fri, Oct 10, 2003 at 04:15:15AM -0400, Kacper Wysocki wrote:
> >> The new feature in rc3, the black frame border while window cycling
> >> was a very nice idea indeed.
> >It's really stolen from metacity :) I can't take credit for it.
> It's still very nice, and I know you implemented and released it within
> three days of hearing of it. Or is it a pure cut-n-paste job? ;-)
Err, no, our code is not similar at all.
> >Ya, use xinerama, there is no support for dual head in non-xinerama
> >setups. Changing this would be extremely non-trivial at this point so
> >its going to stay that way. However, take heart, Openbox is pretty
> >smart about xinerama, and ideas for further smartness would be
> >Running 2 Openbox's does not work. They end up fighting over focus
> >since they both keep losing track of the focus (since it disappears
> >off to the other screen).
> >Sorry, you'll have to learn to love xinerama or run Openbox 2 or
> Okay, so I'm "learning to love" xinerama, for now.
> I'm sorry to hear that there will be no non-xinerama openbox 3. Running
> openbox 2 again is impractical, since I now have some applications (for
> example gDeskCal) that don't work with ROX' compatability mode, and old
> openbox doesn't work properly without rox' compatability mode.
> 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.
> The biggest trouble with xinerama isn't that window managers aren't
> trying to be smart about it, because most are, but that X applications
> are super-dumb about xinerama. In a common xinerama setup where the two
> screens aren't the same model, one screen will invariably run at a
> higher resolution than the other, resulting in rox, and other
> applications attached to the bottom of the screen to disappear into the
> deadzone created by the difference in resolutions. I haven't seen any
> windowmanager handle this properly, which makes me think maybe this is
> a xinerama limitation.
Hm Im not sure what I should do about that. Filling only one head with the
desktop doesn't seem a right approach.
> A second problem is that some applications adjust their initial width/
> height according to the desktop area, which makes for some pretty
> ridiculously x-stretched windows. Maximising a window over two screen
> is fun, but confusing and perfectly useless.
Well, Openbox maximizes on one head.
> Lastly, sort of on a side note, openbox has some issues with certain
> applications maximising/restoring in xinerama. 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)"
> Where did this core go, anyways? (Ideally, though, xine would play the
> movie in duplicate on both screens at once. Irrelevant, since I'm
> pretty sure this is driver-depenent and has to do with the way video
> overlay works.)
That shouldn't crash Openbox.
> Sometimes a window will maximise to a different screen than it's
> running on. I guess it must be a focus thing, but I'm not quite sure.
> It's hard to consistently reproduce these bugs.
It is probly a few pixels over onto the primary or soemthing. That code
could use more intelligence.
> I'll certainly try working with xinerama and keep posting any
> difficulties I have here, if it helps.
To be perfectly honest, I'd rather support 2 screens than xinerama, but
that's just not practical for me at this time. It would pretty much require
a rewrite/organization of the entire codebase.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the openbox