kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 2/14/2014 11:14 AM, Henner Zeller wrote:
>> I committed your patch with 3 very minor changes:
> 
> Thanks for the review!
> 
>>
>> 1 - On wxWidgets 3.0.0, dialog_choose_component.cpp does not compile
>>     (tree.GetNext() function does not exist).
>>     fixedGetPrevVisible is compiled only if wxWidgets version is <
>> 3.0.0, and GetPrevVisible is used for version >= 3.0.0.
>>     Please, verify this point.
> 
> Looks good.
> In the meantime, I have changed this slightly: Turns out that choosing the
> next or previous _visible_ element sometimes is a problem if the item
> is partially
> obstructed; so sometimes the cursor stops scrolling through if at the edge.
> 
> See patch below. I think this should compile on all versions.
> 
>>
>> 2 - The dialog is now derived from DIALOG_SHIM, like all our dialogs.
>>     The advantage (among some others) is the position and size are
>> stored during the session.
> 
> Ah, cool. I was wondering how to do that :)
> 
>>
>> 3 - Comments in .h files are now tagged to be taken in account by
>> doxygen. (previously, They were fine for doxygen, but not tagged)
>>
>>
>>
>> I need a refinement:
>> When a component exists in more than one library, currently Eeschema
>> (like some other EDA tools) loads the first found (The order of
>> libraries is therefore important).
>>
>> There are both advantage and inconvenient to do that.
>>
>> Therefore, because the dialog allows the user to select a given lib,the
>> actual loaded component is (in rare cases) not the selected component
>> (if it comes from an other lib)
> 
> I think we can fix that, but actually returning the LIB_COMPONENT* or some
> fully qualified name (like lib:part). Internally, I already work with
> the LIB_COMPONENT,
> but then when returning, I just return the name to fit into the
> existing infrastructure.
> 
> If we do the LIB_COMPONENT thing, then the history would need to store
> these instead
> of strings (but not sure if the pointers to LIB_COMPONENTS can change
> over the life-time of
> the application ?); so maybe better with fully qualified names.
> I also noticed that the '-cache' libraries do have the same component
> names, but the
> entries are different; will have to take that into account.
> 
> 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.  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.
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.
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.

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.  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
>