On Tue, 21 Jun 2011 06:05:51 -0700 Dan Nicholson <[email protected]> wrote:
> On Sat, Jun 18, 2011 at 12:07 AM, Oleh Nykyforchyn <[email protected]> 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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
