Re: Replacing gdk_display_open(char*)
- From: Paul Davis <paul linuxaudiosystems com>
- To: Tor Lillqvist <tml iki fi>
- Cc: gtk-devel-list gnome org
- Subject: Re: Replacing gdk_display_open(char*)
- Date: Mon, 15 Nov 2010 07:18:13 -0500
On Mon, Nov 15, 2010 at 4:38 AM, Tor Lillqvist <tml iki fi> wrote:
>> * BTW, are there any plans to add multihead on other platforms?
>
> Not for Windows, at least. I am not even sure what multihead would
> mean on Windows. Note that I am not talking about mutiple monitors in
> a user session's Windows desktop; that works mostly fine in GTK+ since
> a long time.
The situation is broadly similar on OS X. Multiple monitors work, but
the concepts exposed by Quartz don't really map sensibly into the X
model, at least not fully. GdkScreen does vaguely correspond to
NSScreen, but for example, see these notes from the top of the
GdkScreen implementation for Quartz:
/* A couple of notes about this file are in order. In GDK, a
* GdkScreen can contain multiple monitors. A GdkScreen has an
* associated root window, in which the monitors are placed. The
* root window "spans" all monitors. The origin is at the top-left
* corner of the root window.
*
* Cocoa works differently. The system has a "screen" (NSScreen) for
* each monitor that is connected (note the conflicting definitions
* of screen). The screen containing the menu bar is screen 0 and the
* bottom-left corner of this screen is the origin of the "monitor
* coordinate space". All other screens are positioned according to this
* origin. If the menu bar is on a secondary screen (for example on
* a monitor hooked up to a laptop), then this screen is screen 0 and
* other monitors will be positioned according to the "secondary screen".
* The main screen is the monitor that shows the window that is currently
* active (has focus), the position of the menu bar does not have influence
* on this!
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]