Feature request: Monitors as list or regexp

[Vladimir-csp]

Issue description

Setting monitor as a single output number or name is too restrictive for a nomad laptop case, especially given how output numbering on wayland is not very predictable.

Please consider making monitor option also take a regexp matching output names and descriptions (models/serials):

monitor = "Dell.*FOO|AOC.*BAR|^eDP-1$"

[bynect]

Issue description

Setting monitor as a single output number or name is too restrictive for a nomad laptop case, especially given how output numbering on wayland is not very predictable.

Please consider making monitor option also take a regexp matching output names and descriptions (models/serials):

monitor = "Dell.*FOO|AOC.*BAR|^eDP-1$"

Interesting idea, however what if multiple monitors are matched? We still don't support multiple monitors at the moment

[Vladimir-csp]

A list of regexps or substrings then, so ordering can be set, returning first matched.

[bynect]

A list of regexps or substrings then, so ordering can be set, returning first matched.

If the list is of simple string it can be matched iteratively and the first found is taken. But if it is a regex different implementations could return different results. How would you define a ordering for the matches? Alphabetical?

[Vladimir-csp]

I meant list of regexps or list of substrings, so it's always an explicit list.

The question is then: how to match predictably against various fields. For example, wlr-randr gives this format:

...
${Output} "${Make} ${Model} ${Serial} (${Output})"
  Make: ...
  Model: ...
  Serial: ...
...

Assuming dunst has access to the same data, if list items are plain substrings, ambiguity can arise, i.e. DP-0 matching against output would match eDP-0 and DP-0 or if matching against each of the available fields (DP-0 substring can be in Model or Serial).

Regexp would give more control: ^DP-0$.

A prefix pointing to the specific field would give even more control: Output:^DP-0$ (that is, split Output: as field pointer, then apply the rest as regexp for Output field).

The second question is how to express a list of complex strings in dunst's config format.

[bynect]

at the moment we can express a list of string in the config parser.
for the regex part we will need to add something to the parser maybe.

my question about ambiguities was for this kind of cases:
regex: ".*DP."
in this case both eDP-0, DP-1, etc. will match. How do we decide which to actually choose?

[Vladimir-csp]

in this case both eDP-0, DP-1, etc. will match. How do we decide which to actually choose?

Either not care at all, or match from sorted list (i.e. by output names with natural sort).