kicad-developers team mailing list archive

[Henner Zeller <h.zeller@xxxxxxx>]

>> That is on the 'return side'.
>> On the 'display side', I could probably make sure that there are two
>> components that
>> look identical and show them next to each other so that the user can choose.
>>
>> In general, I want to make the scoring of 'local libraries' slightly
>> higher than 'global libraries',
>> so that the user first sees their own things (which I guess would be
>> more expected).
>>
>> Anyway, will have a look over the weekend and try to come up with a
>> good solution.
>
> Henner,
>
> There is already a specification for this solution so do not waste your
> time on it.  If you want to look at the work that has already been done,
> look in the new folder in the KiCad source.  It is the initial work done
> for the SWEET component library specification.

Ah, cool. Thanks, I'll have a look to see where things are heading.

> I don't know if this
> code builds any longer but you should read all of the documentation to
> get an idea of where we are headed.  This along with the s-expr
> schematic file format for which I have already written (not published
> yet as it still needs some tweaking) a specification will have to happen
> at the same time.  I do not want the SWEET file syntax embedded in the
> current file format.  The transition to s-expr will be an all or nothing
> deal and the current file format will be reduced to read only.

+1

> Unfortunately, some major refactoring has to happen in the Eeschema base
> code before the new file format happens and I would wait until Dick
> finishes his DLL work before doing too much in that area to prevent any
> conflicts.  I am currently working on a road map for developers so they
> can get an idea of where the project is heading and the order items need
> to be addressed.  I will be a few weeks until it is reviewed and
> committed to the KiCad sources.  If you have time and are interested, I
> have some smaller tasks in my todo list that I can hand off to you.

I am happy to help out. In fact, I do like refactoring works with all
the steps necessary
to get a source from one state to a new, better state. If there are
things on the TODO
list to detangle stuff or extract functionality into their own
classes, I am happy to
help out.

> None of them will get you any fame and glory, they are all under the
> hood stuff that no one will even know you did but they do need addressed.

Grungy under-the-hood stuff is actually fun (a beautiful codebase is
the start of all joy :) ).

>
> I admire your enthusiasm and the work you have done so far.  Before you
> spend time on any feature enhancements in KiCad, always announce your
> intentions on the mailing list and wait for a reply from on of the lead
> developers (JP, Dick, or myself) before doing anything.

Yep, will do. I'll do some smallish changes in the component chooser to make
it a bit more usable (most notable: be able to choose Units as well),
but will try
not to overly change things outside there.

And indeed, next to smallish feature polishing, there are other ideas
that will require bigger changes, but I'll dig into the source and
mailing lists more before that.

-h

>  Please remember
> that this is an all volunteer effort so be patient.  It may take days or
> even weeks for a response due to other commitments. Chances are your
> idea has already been discussed.  It's a good idea to do a search of the
> mailing list and/or look for bug reports related to what your thinking
> of working on and read all of the previous discussion.  Having to rehash
> a discussion for the tenth time is frustrating.
>
> Thanks,
>
> Wayne
>>
>>>
>>> I am thinking it could be good to warn the user if the loaded component
>>> comes from a different lib than the lib which is selected.
>>>
>>> (Note: this issue was already existing in the previous selection dialog)
>>>
>>> Thanks.
>>
>> I do have a little followup-patch with some more improvments wrt. the
>> styleguide and the
>> tree navigation change mentioned above:
>>
>> Commit message:
>>     o Better naming for private struct: public fields uppercase.
>>     o make some more fields 'const' that can.
>>     o Instead of previous/next _visible_ element, Go through
>>       previous and next element. Otherwise the cursor stops moving
>>       if the item is only partially visible.
>>
>> View:
>>   https://github.com/hzeller/kicad/compare/master...followup-patch-component-choose
>>
>> Download:
>>   https://github.com/hzeller/kicad/compare/master...followup-patch-component-choose.diff
>>
>> -h
>>
>>>
>>> --
>>> Jean-Pierre CHARRAS
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp