On Fri, 10 Apr 2015 18:48:02 -0700 Giovanni Campagna <[email protected]> wrote:
> > > 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 > Was not aware of GDK_BACKEND. But perhaps we should standardise this. Having this toolkit-dependant is just silly. We should not have to enumerate all toolkits and add a variable for each of them. And programs that do not use toolkits should not have too look enumerate all toolkits and look at their variables to figure out what to use.
pgpXM1f_ZOQ8r.pgp
Description: OpenPGP digital signature
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
