On 18 December 2015 at 21:50, Chris Pavlina <pavlina.ch...@gmail.com> wrote: > On Fri, Dec 18, 2015 at 09:40:29PM -0800, Henner Zeller wrote: >> On 18 December 2015 at 21:33, Chris Pavlina <pavlina.ch...@gmail.com> 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.ch...@gmail.com> >> >> 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@lists.launchpad.net >> >> > Unsubscribe : https://launchpad.net/~kicad-developers >> >> > More help : https://help.launchpad.net/ListHelp >> >> > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp