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

[Peter Hutterer]

On Tue, Jun 21, 2011 at 06:11:52PM +0300, Oleh Nykyforchyn wrote:
> 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.

sorry, I'm backlogged and I have a tendency to just say yes to features so I
have to restrain myself from some patches and let them sink in for longer
before I can make a decision.
fwiw, I'm still positively skewed towards the features (haven't looked at
the patches yet though).

> > 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.

Human language is not particularly easy to understand. At least || and &&
are actually defined. So getting rid of human language in configurations is
usually a win.

I do agree with you that the complexity is probably more in the stacking and
combination of Match* patterns rather than the actual match patterns
themselves.

> > 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.

sorry if you've already done this in another thread but do you have an
example of a configuration you're trying to attempt? As in, not a made up
one but an actual configuration. It would help greatly to see the
shortfalls of the current options and who knows even show other ways of
getting this configuration.

Wouldn't be the first time that upon seeing the actual problem instead of an
abstraction we either realize that we're going too far or not far enough.

Cheers,
  Peter

> > 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