I cannot imagine trying to browse the library without filtering at all first, it’s huge! 
I’ll put some thought into how to make that particular use case easier, but man, I think you’re doing it wrong 
Very frequently, for me…
I’m not a layouter nor an electronics engineer by trade, mea culpa 
The libs I got contain what I’ve drawn and put in there only. I don’t run around with much dead-weight - yet.
If I look for something I know the lib it’s in, I don’t even have those problems really.
I also don’t (need) use the filters.
But if I were to guess - any noob that comes along for a ride that tries to find something… he’s got no real idea what KiCAD library creators/maintainers/contributors call the part he is looking for - he can try to find the part via 3 ways:
- guess a filter
- browse the libraries
- ask someone else
Which one will be the weapon of choice if it should happen now and involve a navigated approach (to not miss results)? 
Next after that will be - ok, I got a result here, how much else is there and what are my choices?
Can he do that safely with filters or does he need to browse?
To sum it up, I don’t even know if this tree vs flat-pane thing in the end might even be unsolvable to make all parties happy at the same time.
The pro/amateur with a big library will use filters mostly while the noob might need the browsing ability that gives him orientation at all times.
Maybe similar to the GUI vs command line deal.
1 Like
Most people who use KiCad are using it with a quite large collection of libraries, so first and foremost the search tools need to be usable like that. I’m all for making things easier for noobs, but I need to find a way to do that which is not to the detriment of the ability to work with large libraries.
Apologies, but I’m putting my foot down here - the tree view is not new, it’s even in KiCad 4.0, and nobody has complained about it yet. I just added things around it and fixed the font. It is perhaps not perfect, but so far, it’s the best thing anyone has suggested. I’m open to tweaking it to be more user-friendly, but I refuse to do anything that makes working with large library collections a pain in the ass.
I don’t think search is a difficult concept for beginners, and that’s all it is. People do manage to find websites via Google instead of some monstrous list of all websites
No worries, do as you please. I’m thankful for the program anyway and just replied to your request for opinions on the matter. That’s it from me on this. 
1 Like
Hey, I appreciate the feedback very much 
The best I can do is make things as usable as possible for as many users as possible, and that’ll always end up contrary to how some users expect things to be. I hope I don’t sound grumpy 
I will be taking your comments into consideration. I don’t think I can make this exactly how you suggest without sacrificing other important abilities, but I do think other things can be done to make your own workflow less of a pain. I’ll post more thoughts on the matter when I have time to flesh them out a bit; right now I’m trying to balance school and fixing some genuine bugs* in this, so it’s on the back burner a bit.
*Deepest apologies to OS X/macOS users, your build is currently completely broken and crashes the second time this dialog is called up. Hopefully I can get that fixed in time for the next nightly build 
I just tried the filter and it works, but one really needs to know beforehand what one wants and it’s a bit like stabbing in the dark.
Maybe I’m just retarded and should get used to it instead of getting old - the number of libs I have to trawl won’t get smaller, that’s for sure. 
PS: I sensed a bit of grumpiness from the ‘foot down’ thing and ‘misses threads’, that’s why I stepped on my brake. 
Oh, agreed. The initial browse through the libraries while you’re still getting acclimated to how they are organized could be nicer. I just don’t want to do anything to improve that that also makes the later searches through the library more difficult, since you only have to get acclimated once but are forever searching.
I’m not opposed to changing the tree somehow, I’m just opposed to the specific proposed replacement
lol, I’m sorry, I didn’t mean it to sound like that. I’m in a bit of a hurry at the moment so maybe a bit more curt than I should be, but I don’t mean to grump.
1 Like
previous foot-print-preview lingers if a symbol/part lacks a specified footprint.
Although I’ve more or less given up on expressing my opinion about KiCad and the direction it’s headed, I do agree with @Joan_Sparky. Trees are great for data structures that have an arbitrary number of branches (levels of depth), such as a file structure. But they just aren’t as useful when it comes to relatively flat (1 level of depth) data structures.
But if you insist, how about displaying the name of the selected library in the title bar for when it scrolls off the tree, and it will. Perhaps have a context menu so right-clicking on a component gives you other options, “Properties”, “View Footprint”, …
I’m imagining what you describe something like this?
(Apologies for rough sketch)
The library name appears as a heading between components, and when a heading would scroll off the top, it is instead “captured” at the top like a frozen row in a spreadsheet? I hope I’m describing what I’m picturing with sufficient clarity.
I think this is a visual improvement, but I don’t think it’s much of a change to the actual interface, so maybe I’m imagining it wrong.
@Joan_Sparky seems to also favor a non-flat structure though, just a different one from a tree. The problem I see is a conflict between two ways you could want to look at the data:
- Browsing through it. In this case, you want to be able to see and collapse libraries - if you’re looking for opamps, you should be able to quickly collapse and skip over libraries of transistors.
- Reading search results. In this case, you want to see all your results up front without sifting through libraries, since you’ve typed in a description of what you’re looking for.
I’m wondering how to best reconcile these.
Just for comparison (Eagle 7.5.0). All the panels have a splitter bar so quite easy to resize according to interest. I think it works quite well, of course there is still the problem of knowing what keywords to search for, not sure there is a way round that.
It’s a minor point, but I do think all the panels ought to have them, I just haven’t got around to adding them yet. The splitters are a bit of a pain in wx.
You’re not alone, some sort of context driven visualization I guess that is not too hard to implement - but my bed time is nigh, see y’all later. 
That would work and probably be preferable. What I was suggesting was to add the name of the currently expanded library to the dialog’s title bar. But keeping it from scrolling off the tree would probably be better.
I think the view should be the same regardless if browsing or searching. In the case of searching only those libraries and components that match the search should be in the list.
Yeah, it’s basically the same thing, but I think having it in the title bar would make it very easy to miss.
Agreed.
In any case, can we pull this back on track a bit? The component tree has been here since 4.0, it is not part of the changes I’ve made here that I’m soliciting feedback on. Maybe we could make a separate thread on that piece?
I would like to see the panes rearranged slightly, I would prefer the pane with the tree to be the full height of the window with the previews to the right above or below the description, similar to the Eagle layout.
Heh, I actually had it like that initially - originally this was heavily inspired by Eagle - and was told by someone else that it was better the way it is now
Well, I guess both of you will have to wait and see which I go with
1 Like
a nice improvement this part selector.
Only problem is the software moves insanely slowly now.
Picking parts, drawing traces, syrup.
Well this isn’t responsible for drawing traces being slow.
1 Like