[MPlayer-dev-eng] [PATCH] -geometry support in vo_corevideo

[Adrian Stutz]

On Sat, Dec 5, 2009 at 8:48 PM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de>wrote:

> On Sat, Dec 05, 2009 at 12:34:19PM -0700, Tim Wojtulewicz wrote:
> > I was using cascadeTopLeftFromPoint because it takes the menu bar into
> account for positioning.  I had tried calling both setFrameTopLeftPoint and
> setFrame.  Passing a position like 10:10 leaves the window stuck to the top
> of the screen directly under the menubar.  If it's preferred to call
> setFrame, I can make it do that.  Here's an updated version for the
> x/y/height/width variables.
>
> I think that setFrame is the more flexible/correct approach, however I do
> not
> use OSX myself so I'll happily leave the decision to whoever feels like
> maintaining the code.
>

I agree that setFrame: or setFrameTopLeftPoint: should be used.
cascadeTopLeftFromPoint: hides a lot of what it's actually doing and could
very well create problems by calling constrainFrameRect:toScreen: in the
background (here's[1] a good story of this).

What you'd have to do is to use [screen visibleFrame] instead, which takes
menu and dock into account (and makes point calculation more complicated
since the visibleFrame doesn't need to have an origin of 0,0).

But then I ask if that's actually intuitive since since it's not possible to
tell where the coordiantes you give -geometry actually start. Also, the docs
say "The x and y specifications are in pixels measured from the top-left of
the screen [...]" which means the coordinates are measured from the top-left
of the screen and not the top-left point below the menu bar. I don't know if
the other video outs actually handle -geometry this way but it seems more
clear to me to always specify coordinates from the top-left of the screen
and then let OSX move the window if it overlaps the menu bar or the dock.

[1]: http://lists.apple.com/archives/Cocoa-dev/2002/Feb/msg00339.html