Re: Replacing gdk_display_open(char*)



On Sat, Nov 13, 2010 at 11:55:16PM -0500, nobled wrote:
> gdk_display_open() is really only even meaningful on libX11 - it's
> basically a paper-thin wrapper around XOpenDisplay(). The idea of a
> display name string doesn't seem to have much meaning on other
> platforms*: neither the win32 or quartz backends have any use for a
> 'char *display_name' parameter, and just require it to be NULL; even
> the stub xcb backend branch just has a comment that it has no idea
> what to do with it, either.
> 
> Since even if the other platforms had a use for it, the format of a
> "display name" string would be platform-specific, gdk_display_open()
> seems like a bad abstraction - the only cross-platform way to use it
> is to just pass NULL. I'd propose that for GTK3, it be removed and
> replaced by either calls to gdk_display_get_default(), or, if an app
> does need to open a specific display, calls to new backend-specific
> function like these:
> 
> gdk_x11_display_open (Display *xdisplay);
> gdk_xcb_display_open (xcb_connection_t *xconn);
> 
> There's no apparent need for or even an obvious way to do
> platform-specific variants for other backends yet: The current win32
> and quartz implementations both just initialize a singleton global
> GdkDisplay that's declared in gdkglobals-win32.c and
> gdkglobals-quartz.c, respectively, with a bunch of esoteric init()
> calls, and then reuse that on subsequent calls.
> 
> Any usage of gdk_display_open(NULL) can probably be replaced with
> gdk_display_get_default() (assuming the gdk_init(), etc functions
> already set the default)**. An app that calls gdk_display_open() with
> an actual string is already going to fail on anything but libX11, so
> there's no loss in cross-platform-ness in changing an app to include
> the X11 headers and call XOpenDisplay() itself first.
> 
> There aren't many uses of gdk_display_open() in the tree - the first
> two, at least, are pretty much X11-specific already:
> demos/gtk-demo/changedisplay.c
> tests/testmultidisplay.c
> tests/testerrors.c (just calls it with NULL)
> tests/testgtk.c (should #ifdef X server display-name stuff out)
> gdk/gdk.c
> 
> I don't know how many or which apps depend on this function right now,
> though - thoughts?

Well I don't know any application ATM, but it would be very nice,
if GTK allowed for application openning another screen. Consider
any app that wants to display something well-defined using the
video-projector, without beeing disturbed by the desktop.

E.g. presentation program that displays some slides on the projector
in fullscreen, while on the LCD of a laptop one can read the notes
belonging to each slide, or even start another apps without disturbing
what is beeing shown on the projector. The same for moovie player
or image viewer.

So this would be really needed and I think Gtk should have some
way to support an application simultaneusly using more than one
"screen"s.

The current "bottleneck" on X is however the inability of XrandR to create
new screens on the fly... :-(

-- 
Petr Tomasek <http://www.etf.cuni.cz/~tomasek>
Jabber: butrus jabbim cz

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
EA 355:001  DU DU DU DU
EA 355:002  TU TU TU TU
EA 355:003  NU NU NU NU NU NU NU
EA 355:004  NA NA NA NA NA
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]