kicad-developers team mailing list archive

[Henner Zeller <h.zeller@xxxxxxx>]

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.

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