Feature request: Please Add Part Tree and Make the Pool Manager UI More Intuitive

[SonoQuium]

Horizon Eda is a very nice piece of software, so please take my feature request as inspiration, not as critique. (my background: started designing PCBs in the mid 80' and have used tons of different software packages over the years...)

Was playing with the pool manager and I must say that I like the concept, but the user interface and some names of items are strange:

1. In the documentation there are Parts like XY74HC00ASDF, AB74HC00ASDF, Quad NAND DIP 14. Logically they cannot be all Parts. Please name them differently: If the Quad NAND DIP 14 is a Part then name XY74HC00ASDF and AB74HC00ASDF something else, like Component. Having base Parts and inherited Parts is very confusing. A PCB designer/engineer can adapt to user interfaces (and either love it or hate it) but how a PCB designer/engineer has to work with the library (Pool) makes or breaks if the EDA software is used or not. (if he doesn't have to use corporate mandated EDA software)

2. Can the part functionality (button) be on the far left as it is the the TOP of a part tree? (according to the documentation a Part is the TOP level item so it should be seen instantly and not buried between a lot of text/buttons...)

3. Move the other buttons like Units, Symbols, Entities, Padstack, etc. according to their weight in the tree.

4. Can the Part tree be made visible and accessible? It would be nice to see all the items of a part at once in one tree (even the padstack). When I go to a part like the 2N7002 mosfet I see the symbol and the SOT-523 package on the right, there is also the name of the entity (N-channel MOSFET) and if I click on entity the entity functionality is available, but if I click on the Symbols button, the symbol for 2N7002 is not automatically chosen. I need to add another step and type "mos" into the symbols search field. With a visible Part Tree (that is always visible) I could just click on an Item: Symbol, Package, Padstack, etc. and I could check everything very quickly.

Thank you.

[atoav]

Hi, just a fellow horizon-eda user (in fact I was the one who created the illustration in the documentation)

In the documentation there are Parts like XY74HC00ASDF, AB74HC00ASDF, Quad NAND DIP 14. Logically they cannot be all Parts. Please name them differently: If the Quad NAND DIP 14 is a Part then name XY74HC00ASDF and AB74HC00ASDF something else, like Component. Having base Parts and inherited Parts is very confusing.

I will try to explain the thinking behind this. The base Quad NAND DIP 14 can act as the base for any quad NAND IC that uses the DIP package, provided it has the same pinout. You don't need to create base parts, but you can create them so you don't have to change things in a hundred places if you want to change them. So if we take Dual Opamps as an example you could totally do both of these things:

1. Create a base Dual Opamp DIP-8 part where you define the relationship between the pins of the DIP-8 package and the units in a Dual Opamp entity, the tags any typical dual opamp should have (e.g. opamp, dual, etc.) so people can search for it.
2. Create a TL072 (DIP-8) part where manufacturer, orderable MPNs, additional tags (like "fet") are defined
3. Create a NE5532 (DIP-8) part where you do the same, but maybe with a different manufacturer

Or you could totally ignore the base part and create two parts:

1. Create a TL072 (DIP-8) part where you define the relationship between the pins of the DIP-8 package and the units in a Dual Opamp entity, add all the tags that need to be added (and make sure you are not forgetting the ones any other similar opamp has), add manufacturer, orderable MPNs
2. Create a NE5532 (DIP-8) part where you define the relationship between the pins of the DIP-8 package and the units in a Dual Opamp entity, add all the tags that need to be added (and make sure you are not forgetting the ones any other similar opamp has), add manufacturer, orderable MPNs

The issue with the latter approach is that you might:

• get the pinout wrong on accident for each new part you are adding, while relying on a tested base part will always give you the correct pinout, provided you used the correct base part)
• forget to add the tags any dual opamp is expected to have for each new part you are adding (this is important for searching)
• should there ever be a desire to change anything in all opamps (e.g. add/remove a tag), you have to do so for each and every one

So there are parts who might just be parts (because there is no other part in the world that shares the same package and pinout), but there is also parts where many share the same pinout and entity, and this can be used to the advantage those designing circuits and maintaining parts libraries. So some sort of one-off-DSP-IC will never have a base Part (or Component). This is why in my eyes it doesn't really make a lot of sense to introduce components as a seperate concept.

As someone who is a programmer as well, maybe the concepts used have been somewhat more familiar to me than they are to users like you, so maybe the documentation needs some clarification. Any idea on a better wording?

Move the other buttons like Units, Symbols, Entities, Padstack, etc. according to their weight in the tree.

I think a little bit of order could make sense with these tabs. Maybe even a visual divider of some sorts? Good proposal.

Can the Part tree be made visible and accessible? It would be nice to see all the items of a part at once in one tree (even the padstack).

I think I mentioned this somewhere some place. As a very visual person myself I think having a node-like visualization (maybe even clickable!) would be a great addition and maybe even clear some things up.

[SonoQuium]

Hi, thank you for your answer. I understand the concept, and have no problem with it, still it is not logical to me naming different things the same.

A "NAND DIP 14" is not a orderable part but XY74HC00ASDF and AB74HC00ASDF are orderable parts. Therefore they need to have different names (descriptions) as (from a logical point of view) they cannot be all parts.

That's all I'm saying.

[atoav]

Gotcha. I think the reasoning behind that was that all parts (with the exception of base parts) have to either be concrete existing parts that one can find under that MPN or they have to have concrete purchasable MPNs listed in their "orderable MPNs" field.

Base parts for that matter are just a way to group parts together under one "virtual" parent part, which one naturally cannot buy. The thing is: other than the Flag "base" and a "base" in the name of the part nothing would differenciate it from another legit part. That flag has been introduced only recently, so a lot of the parts in the pool does not have that flag set yet. If it is however set, these base parts will not show up in the search. So they are a mere convenience tool for those creating parts, not something any user has to use if they don't like to.

[carrotIndustries]

I think I mentioned this somewhere some place. As a very visual person myself I think having a node-like visualization (maybe even clickable!) would be a great addition and maybe even clear some things up.

Technically, that's just one recursive SQL query away. However, I don't see a good place where to put this. Replacing the parts tab of the pool manager would make it too crowded.

Apart from that, a tree is only half the truth as one entity or package could be referenced by two parts and would then show up twice in the tree.

The parts tab in the pool manager provides links to all items that make up the part. The entity is linked in the top row of the part preview. Package, units and symbols have their individual "go to button".

I think a little bit of order could make sense with these tabs. Maybe even a visual divider of some sorts? Good proposal.

I've had other people also mention that the part tab should be the first one. However, I don't want to break existing user's muscle memory either.