kicad-developers team mailing list archive

[Henner Zeller <h.zeller@xxxxxxx>]

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.

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.

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