By now, this should have filtered through into the various nightly builds. I’m looking for feedback and testing from any users who are adventurous to use/try nightly builds. (Be warned, please don’t do this if you don’t already understand why you shouldn’t. ;))
The component chooser adds the following:
Footprint preview! For components that have a preset in their Footprint field, it will be displayed.
Additional information displayed in the info box
Including directly clickable datasheet link
No more faux columns with monospace type
It does not have yet, but will soon:
Footprint selection via a simple dropdown, so you can pick a footprint before even placing the component. This will present a nicely filtered list of footprints.
3D footprint preview.
Reduced information redundancy (no need to show hidden fields in the graphical preview when all fields are listed in the info box) just added this
There are a couple known bugs that have been fixed since the last nightlies were built, that you may still encounter until the next nightly build:
Info and preview panes are not updated when a part is preselected (i.e. the last part you placed is highlighted the next time) or if you choose parts by pressing the arrow keys while the Filter box is focused.
Debug builds will display an assertion failure dialog; this can be dismissed and the dialog will still work. Non-debug builds, including most official nightlies, do not have this problem.
Maybe just make a button that opens the footprint browser?
Because otherwise you will need to give the user the options for setting their filters similar to what cvpcb does right now.
This will be available. The dropdown will contain:
Whatever is in the Footprint field
Everything matching the footprint filter list and has the correct number of pins
“Other…” which calls up the footprint browser
If you need different filtering, pick Other.
The idea is to make this much quicker than calling up the footprint browser is, but that will require libraries to have properly curated footprint filters. Hopefully, once the capability is there, library maintainers will adopt it. An example intended workflow is to place an 0402 resistor: open component browser, type ‘R’ for resistor, pick 0402 from the dropdown. With a proper filter list, the dropdown will have a relatively small set of very suitable footprints, making this very quick.
Wishlist.
Have more than 1 preset footprint.
Possible to add fields footprint2 etc as for the amount of alternative footprints you see fit.
This is of course not meant to be used to select between dip or so as that would imply completely different parts numbers.
Rather small, medium, large footprint or some other reason.
But each to his own…
The footprint filter I never use.
I would go so far as to call it a dead painful end.
My symbols/parts always carries a footprint attached.
Wish list 2
Separate symbols from the task of also working double as parts…
It’s a first step in long trip to combine footprints and symbols into parts and create integrated libraries. But now I think you might consider refactor this code to move it from modal dialog into dockable toolbox.
you can do that already using the footprint filter. Just make sure your footprints are called something like [footprint name]-[size code] than you can set your filter as [footprint name]*
This is basically what the filter list is, if you don’t use wildcards. There was recently discussion about extending that to support library:part syntax too, I’m not sure if that was merged yet but if not it will be. Just switch to using the filter list and you can have this.
This isn’t going to happen until the applications themselves are upgraded to wxAUI, which I believe is going to happen at some point in the maybe-kinda-sorta-distant future. Something I’d like to work on, but I have limited time.
Note however that in the process I did move even more of the relevant code out of the dialog itself, so it should be easy to transplant into a dockable toolbox later
Ok.
But filters are illogical.
2 solutions to 1 problem.
Keep the footprint field(s) and ditch the filters.
Or make the footprint field(s) able to be filters also.
Only 1 footprint would under normal circumstances match that part.
But sometimes I want an alternative footprint.
For example decoupling 0402 size caps under a bga would need rounded corners.
You would like to be able in layout to pick footprint2 or footprint 3 etc.
Not get a list of filtered footprints.
It just doesn’t make sense to filter a name.
And if it does make sense for some people why not just put it in footprint field.
Why 2 different places?
Many things are placed in either fields or in property of the symbol/part.
Could move all of it down to fields.
This would visualize easier the incoherencies.
Why is not description down in the fields?
Same for keywords and filters etc
Now you need to toggle between 2 places to get to grips of the part.
Once you have filters and footprints next to each others in the field section you might start to think to yourself : "well what happened here now? “
Can we please move this discussion to a different thread? It’s a very valid discussion to have, but I still would like as much input as I can get on this specific bit and I’m worried that if we derail it too far, I won’t.
A) long component names (currently necessary for identifying things in the selector) cause small previews of the actual component… don’t know if that is an issue?
B) lot’s of white space and redundant information (C-ALU_WTser-100u-50V_SMD-8.0DIA-10.5H appears 3 times)
C) a picker tree is IMHO inferior to a flat folder/content picker for speed and overview. It’s THE thing I really really don’t like. Please have a look at the component browser and how it’s done there. It’s way faster and one doesn’t lose the overview as easily as the library information and content information keeps being separated while browsing (I have just like 20-25 libs there… don’t know what someone with the KiCAD libs has to endure).
D) I can only put in single letters into the search field… won’t let me put in ‘Logic’ for example. It swaps them out and only takes one letter at a time as the whole line is being automatically selected after a new letter is being added (to get ‘Lo’ in there I used the arrow keys in between letters, it deselects the line).
E) you’re vertically restricting the available space to search for a component visually by putting additional information under that space (the component field information). I would not do that.
F) upon selecting a component without footprint it shows ‘Footprint not found’ but leaves the former footprint in place. Selecting yet another symbol without footprint clears the preview though…
Overall comment…
I’m not sure one want’s to see the footprint (and then the 3D model) straight away looking for a part. Maybe this should be solved by some sort of hover over functionality?
Where you have a small preview of the linked footprint/3Dmodel and when hovering over with the mouse it get’s bigger to maybe 200x200 or whatever?
Same for the detailed information on the part.
Stopping with the mouse over an entry in the content list could bring up a tooltip with all the information about that component.
A reply to myself…
I naturally see the problem when one searches for components via the filter vs. the browser approach of keeping libraries/content in separate panes. How does the GUI deliver the results to the user in such a case?
Can the content pane be dynamic and contain the results of the filter search instead of just one library from the left?
To make this visually apparent to the user that this is not library content one could adjust the library pane to grey out libraries that don’t contain the content of the filter.
Maybe even shuffle it and bring all the contributing (to the filter result) libraries to the top of the library list.
On the right show ALL results that match the filter and maybe put a separator between them when the next component in that list belongs to another library than the one above/below it…?!
Or if one filters get rid of the two panes and just show a single result pane with a tree view?
So that the tree view is only active if filtered search is being used?
Good catch. Most of the names in my own library are much shorter than that, so I didn’t notice. I’ll fix this.
As above.
I very much like having the tree when displaying an overview of a large number of libraries. I think it might help if the libraries were expanded automatically once the filtered list is sufficiently short?
Yeah, this is a Windows-specific bug - I think it should be fixed in the next Windows nightly build, but I don’t have a good Windows build system set up right now to test quickly. I’ll look into it in more depth if the next nightly doesn’t fix it.
To me, part of searching for a component is flipping through the search results and looking at their properties. The whole reason I did this was that I find KiCad almost unbearable at the component selection stage without a good overview of the details of a part I’m choosing. Perhaps I will add another resize pane so you can shrink this.
Interesting, I haven’t encountered this bug. Can you give me an exact set of steps to reproduce it (including which components you click on)?
See answer to E. Also keep in mind that footprint selection will also be provided here in the future, so it isn’t only a preview. The idea is that a component consists of a symbol and a footprint, and it is quite reasonable that someone may wish to immediately refine and place an “0402 resistor” rather than “a resistor”, for instance.
I like your mockup, except I strongly disagree on the preference for two flat lists vs. a tree. The tree could be improved, perhaps, by automatically expanding categories, but you’ll have a lot of work ahead of you if you wish to convince me to use a pair of flat lists
I’m not sure about putting the information in a tooltip. Maybe I will implement the following: make the information pane resizeable, and if it is resized all the way to nothing, then display the information in tooltips. Not sure if that will be sufficiently obvious though, but it would be very easy to add, so maybe I will add it for a while just to see if testers manage to figure it out.
Try to select a couple of components by navigating the tree only, and not with the filter.
Then search for the same components via the browser and tell me which one is faster and has a better overview.
With the tree one has to close a branch to make it vanish and not use up scroll space. As soon as you got a couple of them open you miss the library title for the components.
Next time you open it it’s all reset, one has to open branches again and hit that little [+] instead of being able to use the whole library name as a pointer target (= bad UI design (*)).
If you scroll you also can’t tell in which library you’re actually in, as it’s title is somewhere further up and not sufficiently distinguishable from the component entries (= hard to spot).
Then you find that the part is not in this particular library… then which one would you try next? Is that one above or below your current branch? Am I at ‘Cxyz’ or ‘Rxyz’ now?
Maybe I’m different, I don’t know. But the first thing I switch on in any file explorer is the folder pane to see were I am and to be able to navigate.
I definitely see the usability in filter based selections where the results might need a library reference. A tree will give this easily for not a lot of results… but searching manually is crippled due to this.
Ask yourself when and how often this information is needed. You won’t be able to show all that’s possible anyway (think of component definitions with more than 5 fields…).
But yeah, the tooltip was just a suggestion to save space. Anything that can be reduced to nothing and requested easily by the user when it is needed (even permanently) is gold
Might also pay of to reduce the pdf information to the filename only (or even just a pdf pictogram) to reduce width of that entry, as I bet it will be the longest most of the time.
[quote=“c4757p, post:16, topic:5384”]
Interesting, I haven’t encountered this bug. Can you give me an exact set of steps to reproduce it (including which components you click on)?[/quote]
select component A that got a footprint - I get a footprint.
select (**) component B that doesn’t have a footprint - I get a ‘Footprint not found’ on black ground over the footprint of A
select component C that doesn’t have a footprint - I get a ‘Footprint not found’ on black ground over black background
**) do not select anything else in-between, like another library entry or white space, go right for the component without a footprint defined
Then maybe think about tabs or something similar, as you won’t be able to press-fit another picker into that window IMHO.
Did any dev-group do some sort of use-case-analysis of what this needs to do (I don’t have the correct words for it, I’m not in that industry) or is this more a shot from the hips - excuse the expression.
Maybe one should start by defining what this dialog/window is supposed to deliver (now and in future) to be able to make informed decisions and not waste effort on stuff that might not fulfill those desires?
I’m really just trying to help - I don’t want to talk you down or anything. Far from it. But I definitely don’t want to see you do all the legwork and not living up to your potential. Lifetime is precious.
That being said - do you have a list/plan for this, so we others can understand where you want to go?
*) my 2 new DELL U2415 screens are wonderful as hell, only nuisance is the on/off button - its a touch sensor with a sensitive area of 5x5mm somewhere on a flat surface about 10mm above a white LED light… the former LG screens had a mechanical switch of 5x30mm - way easier to target and switch But one died 4 weeks ago and the other had a permanent blue column for the last couple of months… they were 8 years old and I repaired blown caps on one of them 5 years ago to keep it going.
