[PATCHv4] Add name event to xdg-output

[Jonas Ådahl]

Replying to both Pekka and Drew at the same time here:

On Mon, Apr 16, 2018 at 11:14:51AM -0400, Drew DeVault wrote:
> On 2018-04-16  2:57 PM, Jonas Ådahl wrote:
> > I'd still like a bit more clarification about what to expect of this
> > string. What I'm trying to avoid is one compositor sending "eDP-1" while
> > another sends "Built-in Display". For example, the first is suitable for
> > command line interfaces (e.g. movie-player --fullscreen-on HDMI-2), but
> > the second is suitable for GUI's (e.g. a widget for selecting what
> > monitor to play a movie on). If it can be either one, I don't see its
> > usefulness in a generic client.
> 
> I'm explicitly not trying to avoid that. To me it's acceptable that one
> compositor uses "eDP-1" and another uses "Built-in Display".

I'd be more fine if the expectation was clear that the string is
suitable for a graphical user interface and not as a keyword in a
command line or something similar.

> 
> > I'm suspecting, given what you've written in other E-mails in this
> > thread that you intend to use this for the "HDMI-1" style names, but at
> > the same time I've seen the word "human readable" been used which more
> > commonly refers to "Built-in Display" or "ASUS 24"", which might not
> > even be unique (there might be two 24 inch ASUS monitors connected).
> 
> HDMI-1 is human readable to the sort of humans that use my compositor.
> Each compositor has a different target audience and should cater their
> naming conventions accordingly.

How well users are educated doesn't have much to do with writing
specificaions. What we do here is target toolkit and application
developers, not end users.

> 
> > I don't want to end up with a situation where we get wildly different
> > results depending on what compositor is the one sending the value.
> 
> Why is this important?

Because it may result in unnecessary inconveniences and bugs. If
"console-movie-player" starts using a "human readable description" as a command
line argument because it's unclear what to expect from it, but
gnome-shell provides a descriptive string that may very well change,
that is localized etc, it's suddenly very unsuitable for how it the use
case the "consolemovie-player" intended to use it for.

Another thing to note is that a human readable description ala "Built-in
Display" or "Dell HD123456 24"" may not even be unique.

> 
> > What I'm assuming is a major reason for keeping things relatively vague
> > is to make sure that it's not specifically connector data, as that may
> > not be available for centain types of compositors.
> 
> Yes, that is a major reason. This also isn't some vague theoretical
> compositor either, my own compositor has situations where connector
> names don't make sense.

Right, so implying it has anything to do with connector is indeed
unwanted.

> 
> --
> Drew DeVault


On Wed, Apr 18, 2018 at 10:27:51AM +0300, Pekka Paalanen wrote:
> On Mon, 16 Apr 2018 11:14:51 -0400
> Drew DeVault <sir at cmpwn.com> wrote:
> 
> > On 2018-04-16  2:57 PM, Jonas Ådahl wrote:
> > > I'd still like a bit more clarification about what to expect of this
> > > string. What I'm trying to avoid is one compositor sending "eDP-1" while
> > > another sends "Built-in Display". For example, the first is suitable for
> > > command line interfaces (e.g. movie-player --fullscreen-on HDMI-2), but
> > > the second is suitable for GUI's (e.g. a widget for selecting what
> > > monitor to play a movie on). If it can be either one, I don't see its
> > > usefulness in a generic client.  
> > 
> > I'm explicitly not trying to avoid that. To me it's acceptable that one
> > compositor uses "eDP-1" and another uses "Built-in Display".
> 
> Hi,
> 
> FWIW, I would personally be ok with the vague definition. First, I
> don't think that apps that use command line or other textual interface
> to specify an output are a thing. We're aiming for a graphical user
> interface, after all. Second, even if they are, the app can still offer
> shorthands for the possibly complicated "names", e.g. by using the
> wl_output global's name (uint). A CLI would need an option to list the
> possible outputs for a user to pick in the first place.
> 
> The only thing I could criticise there is, is it really "name" or more
> like "description"? One still requires them to be unique anyway. I
> think calling it "description" would make people expect less of a
> standardized or single-alphanumeric-word spelling. But I won't insist
> on it.

The thing is that what is wanted here, AFAIU, is not a "description" but
really a name that can is potentially somewhat descriptive (as in not
completely arbitrary), but most importantly unique for a
software+hardware configuration (so that, for example one can script a
program to fullscreen itself on the same monitor each time).

What we probably want is rather two things, one "name" that is not
necessarily very descriptive, that is unique, doesn't change unless the
hardware+software configuration changes, and suitable for typing on a
command line (not that we should explicitly in the spec), and another
thing that really is descriptive, not necessarily unique, and
specifically suitable for using as a string in a graphical user
interface. If some compositors provides a "description" that is
identical as "name", so be it, but at least we won't end up with
situations described above.


Jonas

> 
> 
> Thanks,
> pq