True.
But I will have to rollback until fixed.
To slow to work with.
So will not be able to enjoy the component selector even if unrelated.
Guess it will be fixed soon enough.
Thanks for Kicad. I use it a lot.
Just fixed this. Blame wxWidgets. 
1 Like
Another idea: Since the component chooser is aware of the library from which the currently displayed component is loaded, why not display something like “Library: xyz” and a (thick) horizontal ruler above the actual part title and fields?
IMO this is more intuitive than fixing the library name at the top of the tree pane so it does not scroll out of view.
Two possible suggestions.
- In the an expanded tree, it might be nice to see which ones of these have a footprint assigned before clicking on them. I’m not sure what level of parsing this might take, but it’s nice to have that info up front if it’s available. (checkboxes or anything, it might also look better on to the left or right of the Part name)
- Is there any easy way to parse fields leading with http:// (or https) to enable arbitrary clickable links rather than just the datasheet exclusively? I can see a few cases where linking extra webpages/errata/appnotes/etc to parts might be useful as a generic function.
Unrelated, there was a big patch related to colors added. Should be fixed now. AIUI the bug affected anything rendering symbols that was not the schematic editor itself.
Yeah, maybe. I’ll think about ways to do this cleanly. Visually I’d like it to show up on the left, because on the right it either cuts off the Description column or requires the dialog to be quite large. Unfortunately wxWidgets does not make placing it there particularly easy.
Yup, this could be added, I’ll give this some thought too. There are probably some other areas this should be added throughout KiCad as well for consistency.
1 Like
Thank you for this great new addition @c4757p 
I think this is the right direction to go.
I only have one suggestion. Allow for navigation and collapse of the part tree using arrow keys on the keyboard. This means that when I am on a collapsed item and press arrow-right the item expands and when I am at the root of an expanded item and press arrow left the item collapses. Also when I am within an expanded list and press the left-arrow key the focus jumps to the root of that expanded list. This makes navigation in trees much easier.
1 Like
Yeah, good catch. The old one did that - I’m still fixing up some of the event bindings on the new list widget, wx is weird and broke most of them. The arrow keys will be fixed.
1 Like
Okay, for everyone who’s noticed that this is really, really slow to load - I’ve just fixed this on Windows and Linux (speedup from about 5 seconds on my system with the standard lib to about 0.2s), and am working on an optimization for macOS as that system has an additional reason for slowness. Should be out in tonight’s nightlies
2 Likes
Hi!
nice work on this one generally (I like it). I spotted a few minor things:
- It is no longer possible to select a footprint (in the editor at least) by double-clicking the entry in the table/tree-control
- The footprint is not zoomable
- The pin-numbers are not always shown … but these often help if there are variants of a device with different pinouts!
- Sometimes when switching to a footprint without a specific footprint, the old footprint stays visible, but is overlayn by text stating that there’s no footprint:
- Have a 3D representation would be nice (eye candy) … but it may not be necessary for most symbols
- Would it be possible to also show the Footrpint-Filters in the text-field?
Best,
JAN
Content warning: tedious programmerese. Viewer discretion is advised.
Welp… making this fast enough to be usable on macOS was a massive two-day refactoring effort resulting in a model-view-adapter class set and the destruction of a large plate of spaghetti code. Will probably be another couple days before the result of this hits the nighlies, but once it does it should be nice and snappy. This also fixes a couple quirks having to do with column size and dialog resizing, by switching from the buggy-as-hell wxTreeListCtrl to the much nicer wxDataViewCtrl.
After this is complete some modifications will be done to address user feedback, and then footprint selection and 3D preview will finally be implemented.
4 Likes
Aaaand… the yak-shaving stack is finally shrinking
In the process I’ve done some serious shoveling of code, and will be fixing two really annoying github footprint loading issues in the process:
- cvpcb freezes on startup while loading with no user feedback
- if the download hangs, all of KiCad hangs
The concurrent footprint loader should be slightly faster too, as the implementation of worker threads was…misguided 
2 Likes
Had they been working all on the same ‘problem’?
Thanks for keeping us posted though, love your updates! 
Heh, not quite that bad. They were each given an equal number of libraries to process at the beginning. The libraries differ widely in complexity, which meant that by about halfway through, the worker threads that got mostly simple libs had already finished and were just twiddling their thumbs waiting for the unlucky threads to get through their big libraries…
Replaced with a more traditional worker pool + queue implementation… it’s way simpler too…
2 Likes
Sweet baby Jesus I got myself into a lot of work when I offered to do this.
Just submitted a 3.3k-line patch to the mailing list for discussion - all just to allow selecting footprints from within the component selector. Think I cleaned off all the yak hair. Should be merged in a day or two
6 Likes
You will have yourself a fine yak hair coat by the end of this. Very much appreciated piece of work.
2 Likes