kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 12/19/2015 2:57 AM, Henner Zeller wrote:
> On 18 December 2015 at 21:57, Henner Zeller <h.zeller@xxxxxxx> wrote:
>> On 18 December 2015 at 21:50, Chris Pavlina <pavlina.chris@xxxxxxxxx> wrote:
>>> On Fri, Dec 18, 2015 at 09:40:29PM -0800, Henner Zeller wrote:
>>>> On 18 December 2015 at 21:33, Chris Pavlina <pavlina.chris@xxxxxxxxx> wrote:
>>>>> I'm not going to argue about search methods, it'll suffice to say I
>>>>> disagree. I don't _want_ to search my library your way, and yes, I
>>>>> understand that it can work.
>>>>>
>>>>> I'm unconvinced that adding one option box is excessive complexity. It's
>>>>> not in the main UI, it's in the preferences dialog. What's wrong with
>>>>> preferences? Users can ignore those. Most do. Though the preferences
>>>>> dialog does need to be reorganized.
>>>>
>>>> The problem is, that people don't find it. They get frustrated because
>>>> they want to search with regular expressions, but it doesn't work. And
>>>> they never find the option to set it.
>>>
>>> Somehow I don't think that wildcard/regex search is going to be a big
>>> advertised feature that all the kids will be flocking to kicad for. I
>>> also doubt that the sort of person who would want it is the sort of
>>> person who couldn't be bothered to look at the options.
>>>
>>>>
>>>> If the dialog would do all matches in parallel and increases scores
>>>> for each matcher that triggers, then you get all the simple matching I
>>>> am proposing and all the extended regular expression searching that
>>>> you want. And it will work automatically without anyone ever setting
>>>> an option.
>>>
>>> Yes, and clutters up the results with false matches, just like searching
>>> for "ATXMEGA*D3" by typing "ATXMEGA D3" does.
>>
>> But if you have all scoring functions engaged, the relevant come first.
>>
>>>
>>> Seriously, what is it with this mailing list? Every time someone
>>> suggests a simple idea, everyone immediately piles on with their
>>> favorite way to overcomplicate it.
>>
>> Calm down. I make suggestions to _simplify_, not complicate.
>>
>>>
>>> I just suggested adding this because I thought it'd be a simple addition
>>> that might add some utility for some people. Never imagined wildcards
>>> could be so controversial.
>>
>> As I said, I like wildcards and regexp and like to see them supported.
>> But I suggested way to support them automatically.
>>
>>> Take it or leave it, I'm not going to keep
>>> revising it to make it more complex.
>>
>> You don't have to. I can do that.
> 
> Attached, the simplified patch, using your new matchers:
> 
>    * Uses all your matchers, but does not need to have the factory.
>    * No need for extra code to add option for users.
>    * Same effect. People can use any syntax they want and get matches
> accordingly.
>    * It is very unlikely to get unwanted results.
>    * Less code (366 vs 833 loc)
>    * More user friendly to use (no search for obscure options, if
> someone uses FOO*BAR or a regexp it just works as expected).

Is this the patch that should be committed?  I took a look at it and I
like it.  Nice work gentlemen.  One small comment.  Watch your curly
brace placement.  They should always go on the next line not after a
statement.

> 
> -h
> 
>>
>>>
>>>>
>>>> -h
>>>>
>>>>>
>>>>>
>>>>> On Fri, Dec 18, 2015 at 09:19:54PM -0800, Henner Zeller wrote:
>>>>>> On 18 December 2015 at 20:16, Chris Pavlina <pavlina.chris@xxxxxxxxx> wrote:
>>>>>>> As discussed earlier today, this patch adds support for both wildcard
>>>>>>> and regular expression search to the eeschema component chooser. An
>>>>>>> option is added to eeschema options to select the "Component search
>>>>>>> method", which defaults to "Simple" (the original behavior). Regular
>>>>>>> expression search was added as a "bonus", as it was used as a stepping
>>>>>>> stone to wildcard search.
>>>>>>
>>>>>> Cool, I'll try it.
>>>>>>
>>>>>> BUT: I am skeptical I must admit, as adding these features that are
>>>>>> undoublty more complicated for the non-software engineer to use and
>>>>>> also to choose from. More choices for the user to handle, and I am not
>>>>>> convinced yet that it is worth it.
>>>>>>
>>>>>> I would rather try to make the search as best as possible that a few
>>>>>> words will bring the result. If it doesn't, then the scoring function
>>>>>> needs to be tweaked. I am a big fan of simple user interfaces...
>>>>>>
>>>>>> Do you have some real world examples that are really hard to solve
>>>>>> with simple string-matching and scoring of the result as it is now
>>>>>> (the XMEGA example in the other thread can be done by just having a
>>>>>> space between the xmega and d3, so this is not really a good example).
>>>>>>
>>>>>> Having simple user interfaces is hugely important IMHO, so we should
>>>>>> add features and confusing user options only if the simple way of
>>>>>> dealing with it can't do it.
>>>>>>
>>>>>> -h
>>>>>>
>>>>>>>
>>>>>>> The existing behavior of Henner's component chooser wasn't changed, just
>>>>>>> the matching function it uses.
>>>>>>>
>>>>>>> Following Wayne's suggestion, an EDA_PATTERN_MATCH base class is defined
>>>>>>> in include/eda_pattern_match.h, and then:
>>>>>>>
>>>>>>> - EDA_PATTERN_MATCH_SUBSTR implements EDA_PATTERN_MATCH with the old
>>>>>>>   behavior
>>>>>>>
>>>>>>> - EDA_PATTERN_MATCH_REGEX implements EDA_PATTERN_MATCH providing regex
>>>>>>>   search via wxRegEx and wxRE_ADVANCED.
>>>>>>>
>>>>>>> - EDA_PATTERN_MATCH_WILDCARD extends EDA_PATTERN_MATCH_REGEX,
>>>>>>>   translating a wildcard string to a regular expression and then loading
>>>>>>>   it into the latter. This allows the nice, fast, wxString-compatible,
>>>>>>>   and well tested regex search to be reused for wildcard search.
>>>>>>>
>>>>>>> --
>>>>>>> Chris
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>> More help   : https://help.launchpad.net/ListHelp