← Back to team overview

kicad-developers team mailing list archive

Re: PATCH: making component choosing (much!) more usable

 

On 12 February 2014 16:01, Blair Bonnett <blair.bonnett@xxxxxxxxx> wrote:
> This time, posting to the list rather than only to Tomasz...
>
> On 13 February 2014 11:54, Tomasz Wlostowski <tomasz.wlostowski@xxxxxxx>
> wrote:
>>
>> On 02/12/2014 09:34 AM, Henner Zeller wrote:
>>>
>>> Hi,
>>> Choosing components in the schematics editor is very cumbersome right
>>> now.
>>> (...)
>>>
>>>
>>> So I sat down and thought about how it _should_ be.
>>>
>>> This is what I came up with, see patch:
>>>
>>>    - interactive search-as-you-type
>>
>>
>> Hi Henner,
>>
>> I just compiled eeschema with the patch. The browser is simply *awesome*!
>> I sincerely hope we'll see more cool stuff from you :-)
>
>
>
> Agree very much with this.

As long as you provide a nice github mirror of KiCad :) Thanks for
that BTW, it helped concentrating on coding instead of tinkering with
yet another VCS.

>
>
>>>
>>> There is another feature I'd like to add in a separate patch: show a
>>> little
>>> drawing of the currently selected component in the left bottom corner
>>> (left blank right now) when selected with the mouse popping up the
>>> library
>>> viewer. I left it as a dummy in this patch as I didn't want to make it
>>> too big.
>>
>> > (...)
>>
>> > Of course, you might have suggestions - let me know what to improve.
>>
>>
>> Few extra features that came to my mind:
>> - footprint/3D preview,
>> - browser as a dockable window instead of dialog,
>> - possibility to assign the footprint on the schematic,
>> - and save the above to the SCH library.
>
>
> Definitely would like to see this as a dockable window.

I'll play with that (though probably would do this as an iteration
starting from this patch as
separate change)

>
> I am also wondering if it would be better presented as a table rather than a
> tree, say one column for the component name, one for the source library, and
> one for the description (and maybe even other fields from the component,
> allowing the user to show and hide columns as they see fit).

The problem with tables is: the columns need to be as wide as the widest column.
Also, you have to display the full name of the library you are in,
while in the tree case, this
is merely an indentation. Also with less repetition in each line,
which decreases visual clutter and increases usability as
only relevant information is shown. In particular if we want to use
this in a (smallish) dockable
window, we want to be compact.

> This would mean
> a component with a low-scoring match wouldn't be dragged to near the top
> because it is in a library with a high-scoring match. (If I have
> misunderstood how the ordering works, just say so).

You are right, this is how it works, so it essentially displays things
out of order in that case as
each subtree is sorted in itself. Which is the downside of this approach.

This could be solved by dropping lower scoring parts or hiding them
behind collapsed nodes.

Ultimately my goal is that this shouldn't be a problem: the highest
scoring part for a good query should be on top anyway, if it isn't,
the scoring needs fixing :)

> Does the order of matches matter for multi-word searches? For example, a
> search for "power amp" promotes "Dual op-amp (low power)" components from
> the linear library over an "audio power amp" in the same library. The audio
> library is also the second library in the results despite having a lot of
> components with "power amp" in the description. Is there some way to score
> matches so those where keywords are in the same order as the query are
> weighted higher?

There is not right now, but having things that show up 'in sequence'
score higher than not would be a good idea. This is the very first
version of the scoring algorithm and will see tweaks along the way.
Best is to do this with data: we should find a good set of typical
queries to test new scoring algorithms. So I suggest to give this
initial version a go and I am gladly accepting example queries that
should do better.

> How is the order of the libraries decided? The one with the highest
> component score, or the one with the highest sum of scores, or something
> else?

Right now max score of any of its childs. Sum wouldn't make too much
sense as each item is scored individually.
(There is an #ifdef 0 in the component_tree_search_container.cpp which
you can set to 1 to see the given score)

> As an aside, I think this will require some cleanup in the libraries
> themselves. For example, a search for "resistor" does not turn up the main
> resistor component, which has the description "resistance". The same with
> "capacitor" (condensateur non polarise). There are also a number of
> amplifiers which are abbreviated amp or ampli and so won't be found in a
> search for "amplifier".

Fully agree. While playing with the chooser, I noticed that there are
many things that can be improved: missing, too short or unrelated
descriptions; various abbreviations, languages ..)
Better descriptions and keywords will provide a better search
experience. Since this chooser actually takes them into account, I
hope this will increase the incentives for someone working on the
libraries.
(Also, we need a concept of distinguishing languages. There should be
language attributes for multiple descriptions to be able to show the
one best fitting the users' locale first).

-h

>
> Keep up the good work!
> Blair
>
>
>>
>>
>> This may soon become possible thanks to the DLLization work being done.
>>
>>
>>>
>>> Download it here:
>>>
>>> https://github.com/hzeller/kicad/compare/master...component-chooser-experiment.diff
>>>
>> BTW. Are you using git-bzr-ng or some other tool to work on bzr repos with
>> git?
>>
>> Cheers,
>> Tom
>>
>>
>> _______________________________________________
>> 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
>


References