[PATCH 2/3 v2'] xserver: Introduce negated conditions in Match patterns

[Oleh Nykyforchyn]

On Tue, 21 Jun 2011 06:05:51 -0700
Dan Nicholson <dbn.lists at gmail.com> wrote:

> On Sat, Jun 18, 2011 at 12:07 AM, Oleh Nykyforchyn <oleh.nyk at gmail.com> wrote:
> > Well, if people are so accustomed to single arguments and "|" as "or",
> > what about:
> >
> > 1) adding logical '&' to logical '|';
> >
> > 2) "regex:|pat|" = "regex:/pat/" = "regex:%pat% = .... (like sed);
> >
> > 3) single argument, with multiple conditions (probably regexes).
> >
> > This way we obtain the same (and even more) functionality.
> 
> The issue isn't about single arguments, but rather adding more
> features and complexity when they're not necessary. You asked in
> another email why we weren't following the UNIX way of allowing more
> flexibility if it didn't interfere with the existing functionality.
> The reason is because adding that flexibility has more costs than the
> initial patch.
> 
> 1. It makes the code more complex to handle the various cases. This in
> turn makes the code more difficult to understand and more difficult to
> maintain. This is why Peter's opinion is so important - he's the one
> that's going to be supporting this code down the road when drive-by
> developers like you and me aren't around. The easiest way to make code
> more maintainable is to remove complexity.
>
OK, it is up to Peter to decide. On my side, I tried to do my best to
make the code as clear and structured as possible.

> 2. These changes become part of the Xorg interface, so they need to be
> considered carefully. If it becomes apparent in a year that one of
> these features wasn't a good idea, the removal of that feature might
> not be possible because now there are working setups using those
> features. It's not impossible, but breaking people's configurations
> should only be a last resort.
> 
> 3. The added flexibility is more difficult for users to understand and
> easier for them to get wrong. The InputClass matching is already
> somewhat difficult to explain, so adding more features on top doesn't
> make things easier.
We can appeal to natural understanding of "or", "and" and "not". Such a syntax
is close to human language. I think that most of complexitity with InputClass
is related to the idea of filtering attributes of input devices, not to the syntax
of match statements.

> Furthermore, the users have apparently been happy
> with the current functionality because I haven't seen any other
> reports that suggesting that they're too limited.
Multiseat setups are too rare for You to hear a lot of complaints.

> 
> I still feel like that's a useful
> feature, but in hindsight I can see how that's not something the
> typical user needs.
Of course, but without similar changes we can't have multiseat at all and
leave this field to proprietary products. 

> And at the end of the day, Peter's one of the
> maintainers of this project, so his opinion carries more weight for
> me.
I completely agree.
> 
> Like I said, I think there's some useful work in these patches, but I
> believe the agreed upon end point was getting "regex:blah" supported.
> Instead, each iteration of these patches adds more features that push
> them further away from getting in.
It is only parser function where complexity was added. You
can see that overall size and complexity of patches do not increase.

> 
> Hope that helps and doesn't discourage too much,
It is only a question of permanent patching of each new installed release of Xorg.
Nothing pleasant, but no tragedy. I would also like other people to benefit from
my efforts. Existing howtos on Multiseat on the web propose difficult, inefficient,
and not robust ways of distributing input devices between seats. 
> 

Best regards,
Oleh