Identifying the real display server

Mattias Andrée maandree at member.fsf.org
Mon Apr 13 14:08:59 PDT 2015


On Mon, 13 Apr 2015 13:49:07 -0700
Thiago Macieira <thiago at kde.org> wrote:

> On Monday 13 April 2015 19:33:23 Mattias Andrée wrote:
> > > If we're going to do that, why not put the full
> > > identifiers in the variable? Then we wouldn't have to
> > > look up another environment variable for the details.
> > 
> > Are you asking why we should have PREFERRED_DISPLAY=x11
> > rather than PREFERRED_DISPLAY=DISPLAY or are you asking
> > why we should have PREFERRED_DISPLAY=x11 rather than
> > PREFERRED_DISPLAY=x11=:0?
> 
> The latter.
> 
> > If the latter:
> > 
> > If we do not to it this way, it makes the example above,
> > and similar things, more complex.
> > I think that WAYLAND_DISPLAY &c should _not_ be removed.
> > So it would be redundant, and doing a second look up is
> > cheap. And a program that only supports Wayland would
> > have to parse PREFERRED_DISPLAY.
> 
> That's until someone figures out another display server
> besides the ones that already exist. This avoids having
> 4+ environment variables set when one could do it just
> fine.
> 
>   # pseudo-code, I don't know Python
>   for url in os.environ['PREFERRED_DISPLAY'].split():
>     if isDisplaySupported(url.scheme()):
>        initDisplay(url.path())
>   else:
>     croak()
> 

Consider the URL parsing code too, and
the fact that you need in object oriented
languages need to create an instance of an
URL class. Additionally, we cannot assume
that the generic syntax covers all display
server's syntax. In fact, x11 is not
covered. There is also the complexity of
URL encoding the pathnames. In shell scripts.
Furthermore at least DISPLAY must remain
for because of legacy programs.


More information about the xdg mailing list