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

[Ben Jansens]

On Sun, Oct 12, 2003 at 10:06:58AM -0400, Kacper Wysocki wrote:
> >>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.

Ah, I was talking of Desktop windows. Dock windows should generally do this
themselves. Openbox doesn't place/size them. I spose Desktops should as
well. GNOME's tools are pretty good about xinereama.

> >It is probly a few pixels over onto the primary or something. That
> >code could use more intelligence.
> [/snipplet]
> 
> 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've made this somewhat smarter in CVS, you'll see it in rc4.

> 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  

This might be appropriate in a sloppy focus world, but I'm pretty sure its
not outside that. It places windows with the intention to allow as many
windows to be placed without overlapping as possible. It uses both heads
equally. I thought of doing some sort of scoring system where th head with
the mouse gets a little boost.

> 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.

Ya, just following the mouse blindly is not the answer.

> 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).

Yes, the splash screens request that position. Openbox won't know where it
is going to put the app because it depends on the size of the window it maps
after the splash screen. I'll consider centering splash screens on one
screen always, though it probably won't be related to where further app
windows open.

Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://icculus.org/pipermail/openbox/attachments/20031012/3e125dbe/attachment.pgp>