On Fri, Apr 10, 2015 at 6:44 PM, Mattias Andrée
<[email protected]> wrote:
On Fri, 10 Apr 2015 18:24:52 -0700
Thiago Macieira <[email protected]> wrote:
On Saturday 11 April 2015 00:33:50 Mattias Andrée wrote:
> Is there another way to identify which display server is
> actually running? If not, I propose we add the
> environment variable REAL_DISPLAY. The value of
> REAL_DISPLAY should be then name of the environment
> variable used by the display server that is actually
> running. For example if Wayland is running with an X
> compatibility layer, the value of REAL_DISPLAY should
> be WAYLAND_DISPLAY.
I'd recommend having one common variable that lists all
the options, in the order of preference of the
compositing server. Suppose it's a Wayland server with
Mir and X compatibility layers and the X layer is better
supported, we'd have:
wayland:///run/user/1000/wayland-0|x11::0|mir:///run/user/1000/mir-0
I chose to use the pipe character (|) because it cannot
appear unencoded in URLs, so you can easily tokenise and
parse each item as a URL. The space character would have
served just as well.
As for the name of the variable itself... I'll leave the
bikeshed to others :-)
List of preference is a good idea. But I think the
URL is overly complicated and redundant. The *DISPLAY
variable must still be set for each protocol.
I suggest the same specifications as my original
proposal with the addition that the value is a
space (\x20) separated list in order of preference.
Leading, duplicate and trailing spaces should be
allowed by are ignored.
The reason for using a space character as the
delimiter is that single ASCII character
delimiters is simplest to implement, it is
a character that never causes any problems
except for in once case that we can utilise,
shells do not support them in environment
variable names. Similarly, = is not supported
in variable environment names, but using it
as a delimiter is not as readable, and it
does not have the same nice property as
whitespace: $REAL_DISPLAY, without quotes,
in a shell is evaluated to one argument
display server listed in it.
Well, at this point you're essentially reinventing GDK_BACKEND, but at
server side. Given that the level of support is very much toolkit
specific, what's the advantage of this proposal over setting the
variables for the different toolkits with the compositor preferred
order?
(I would expect Qt and SDL to have similar environment variables, but I
don't know)
Cheers
Giovanni
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
