kicad-developers team mailing list archive

[Simon Richter <Simon.Richter@xxxxxxxxxx>]

Hi Rene,

On 12.03.19 09:51, Rene Pöschl wrote:

> Hi again, I thought about it a bit more. I am less and less convinced
> this will make it easier for users to understand the library setup overall.

That's why I'm asking here. :)

> This also brings up the question how would you integrate merged parts
> into the treeview. I think this will be one of the hardest things to
> decide with your suggestion. (But maybe i am completely blind here.)

Probably just show items from project/user dirs in bold in the full view
so they stand out, and move everything below new top level items
(project only, project/user, project/user/organization, everything).

That introduces some repetition, but should be usable:

-+ used in this project
 | + R_0402
 | \ C_0402
 + your components
 | + resistors
 | | + *R_0402*
 | + capacitors
 | | + *C_0402*
 | \ regulators
 |   + 7805
 + components used in your organization
 |   ...
 + all components

The decision whether to show library names in each category would
probably be based on number.

> Right now kicad kind of favors a centralized library setup (the global
> library) filled with generic footprints (and arguably generic symbols as
> well.) I might be biased but this is a good thing in my opinion. (and i
> would guess larger organizations would also like a tool that favors a
> centralized library setup. Small organizations that do not have the
> manpower to properly manage a centralized lib might in fact favor a
> project central setup "managed" by every engineer.)

Ideally, we'd support all of these workflows equally. The centralized
repository is there for those people who have it configured, while
people who prefer their own parts would just leave it out. Organizations
sharing between engineers would have a writable network share, and
everyone gets a default storage that will always be available.

Since we know what library a part came from, we could also easily add
"publish to organization" and "submit to KiCad library" buttons for
local-only components.

> I think your suggestion in general would move kicad more towards project
> specific libraries. (It will highly depend on the interface and the
> exact implementation details.)

Every project needs copies of all parts used anyway, that would just
become integrated into the library management code and made explicit,
rather than just copying components into the local files. As an added
bonus, it would make comparing parts in the project and in the library
easier.

> I would suggest that it is ensured that a centralized setup is as easy
> or maybe even easier to handle than a distributed project local one.

I'd expect part definitions to start out in local libraries until the
engineers are happy with them, and then we should make it easy to submit
them.

> This means it should always be possible to update assets in the central
> lib and have these changes be pushed (with user interaction like it is
> now on the pcb side of things) into old projects. It also means that it
> should be easy to import assets into existing libs and it should also be
> easy to edit the central library. (Unless it is write protected.)

Write-protected is kind of the default, unless you do a per-user
installation on Windows and install KiCad entirely into your home directory.

Writing back the changes to the global library means breaking library
updates currently, which is why I'd like to treat system libraries as
readonly and explicitly track changes through an overlay.

> The
> later one is kind of ensured if a single library asset is a single file.
> For this to be fulfilled there must be an easy way to open the central
> asset even if there is a conflict with a local one.

Yes, definitely (maybe if the local and central asset disagree, show a
special icon and offer a workflow to upgrade).

> The idea about copying the global assets into the project as a separate
> local library is another thing that sounds good on the surface but again
> comes with consequences. The problem with that is that you will most
> likely end up with users being confused as the same asset now exists in
> multiple libs. (The interface must be very well defined here. And very
> well documented.)

Yes, that's why I want to show users a merged view so it appears as if
we had a single library, with some components having special states
(local only, different from central library, submitted, ...).

   Simon

Attachment: signature.asc
Description: OpenPGP digital signature