kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 10/04/2013 03:30 PM, Dick Hollenbeck wrote:
> On 10/04/2013 03:15 PM, Wayne Stambaugh wrote:
>> On 10/4/2013 3:22 PM, Dick Hollenbeck wrote:
>>>
>>>>
>>>> Thank you for your amazing effort on the GitHub plugin.  I am looking
>>>> forward to taking it for a test drive.  I hope to finish up the
>>>> FP_LIB_TABLE code and documentation by the end of the weekend.  With all
>>>> of the pieces in place, KiCad should have a really good footprint
>>>> library management system.
>>>>
>>>> Wayne
>>>
>>>
>>> Thank you Wayne!
>>>
>>> I gave you bug https://bugs.launchpad.net/bugs/1235317   :)
>>
>> I noticed that :)  I took a quick look at the module editor and saving a
>> library may not be the only place where this will be a problem.  The
>> current code attempts to determine the correct plugin by the library
>> path using IO_MGR::GuessPluginTypeFromLibPath().

Probably no environment substitution on lib path, if you want a quick hack.

The GITHUB plugin is not useable until the stuff below is complete however, and it will
get done in any case:  The library browser needs to be based on the nickname now, for
reasons I've mentioned in the last week.


  It appear that this is
>> where things are causing the problem.  I'll have to do a debug build on
>> Linux with the GIT_HUB_PLUGIN enabled in order to test this so it might
>> take me a day or so to get it all sorted out.
> 
> The stuff below should be used in place of that, I have it on my to do list already, as
> you can see.
> 
> If you don't want to do it, I will.
> 
> 
>>
>>>
>>> I also updated FP_LIB_TABLE class with the following API extensions, in *comment only*
>>> form, just as a means of suggesting the API that we should be using in the library manager
>>> when FP_LIB_TABLE is enabled.  These calls address all but the
>>>
>>> a) library creation,
>>> b) library deletion
>>>
>>> functions, which I think may need to be done with the help of the DIALOG_FP_LIB_TABLE.  So
>>> I defer those for now.
>>>
>>> If we park the PLUGIN::RELEASER into the FP_LIB_TABLE we can easily cache the PLUGINs and
>>> then these new API functions make sense.  PLUGIN::RELEASER is not currently up to the task
>>> of operator=(), ( needed in ROW::operator=() ), but could be made so I assume.
>>>
>>> Here are my suggested API function to bring into library management GUI, and remove
>>> references to ROW in there.  The idea is that we get two primary benefits:
>>>
>>> Uppercase letters to show significant benefits:
>>>
>>> A) retention of every plugin's cache.
>>> B) PROPERTIES can be passed to every PLUGIN::Footprint*() call.
>>>
>>>
>>> Here are the new functions in class FP_LIB_TABLE, which one of us should build into the
>>> library browser and editor UI IMO:
>>>
>>>
>>> #if 0       // PLUGIN API SUBSET, REBASED ON aNickname
>>>
>>>     /**
>>>      * Function FootprintEnumerate
>>>      * returns a list of footprint names contained within the library given by
>>>      * @a aNickname.
>>>      *
>>>      * @param aNickname is a locator for the "library", it is a "name"
>>>      *     in FP_LIB_TABLE::ROW
>>>      *
>>>      * @return wxArrayString - is the array of available footprint names inside
>>>      *   a library
>>>      *
>>>      * @throw IO_ERROR if the library cannot be found, or footprint cannot be loaded.
>>>      */
>>>     wxArrayString FootprintEnumerate( const wxString& aNickname ) const;
>>>
>>>     /**
>>>      * Function FootprintLoad
>>>      * loads a footprint having @a aFootprintName from the library given by @a aNickname.
>>>      *
>>>      * @param aNickname is a locator for the "library", it is a "name"
>>>      *     in FP_LIB_TABLE::ROW
>>>      *
>>>      * @param aFootprintName is the name of the footprint to load.
>>>      *
>>>      * @return  MODULE* - if found caller owns it, else NULL if not found.
>>>      *
>>>      * @throw   IO_ERROR if the library cannot be found or read.  No exception
>>>      *          is thrown in the case where aFootprintName cannot be found.
>>>      */
>>>     MODULE* FootprintLoad( const wxString& aNickname, const wxString& aFootprintName ) const;
>>>
>>>     /**
>>>      * Function FootprintSave
>>>      * will write @a aFootprint to an existing library given by @a aNickname.
>>>      * If a footprint by the same name already exists, it is replaced.
>>>      *
>>>      * @param aNickname is a locator for the "library", it is a "name"
>>>      *     in FP_LIB_TABLE::ROW
>>>      *
>>>      * @param aFootprint is what to store in the library. The caller continues
>>>      *    to own the footprint after this call.
>>>      *
>>>      * @throw IO_ERROR if there is a problem saving.
>>>      */
>>>     void FootprintSave( const wxString& aNickname, const MODULE* aFootprint );
>>>
>>>     /**
>>>      * Function FootprintDelete
>>>      * deletes the @a aFootprintName from the library given by @a aNickname.
>>>      *
>>>      * @param aNickname is a locator for the "library", it is a "name"
>>>      *     in FP_LIB_TABLE::ROW
>>>      *
>>>      * @param aFootprintName is the name of a footprint to delete from the specified library.
>>>      *
>>>      * @throw IO_ERROR if there is a problem finding the footprint or the library, or
>>> deleting it.
>>>      */
>>>     void FootprintDelete( const wxString& aNickname, const wxString& aFootprintName );
>>>
>>>     /**
>>>      * Function IsFootprintLibWritable
>>>      * returns true iff the library given by @a aNickname is writable.  (Often
>>>      * system libraries are read only because of where they are installed.)
>>>      *
>>>      * @throw IO_ERROR if no library at aLibraryPath exists.
>>>      */
>>>     bool IsFootprintLibWritable( const wxString& aNickname );
>>>
>>> #endif
>>>
>>>
>>> These are now in the repo, but commented out.
>>>
>>> They mirror the similarly named ones in the PLUGIN class, but omit the PROPERTIES* since
>>> they are in the ROW, and aNickname takes the place of aLibraryPath.  Good symmetry otherwise.
>>>
>>> GITHUB plugin will yield great benefits from these changes, but will still be too slow for
>>> the "List All" footprint select dialog.  I have a couple of ideas in mind for that issue.
>>>  Having the "options" in place will give us more options, including COW support, or
>>> launching multiple threads to do the "List All" function.
>>>
>>> Again, I am deferring library create and delete into the future, and want to think of
>>> those processes as being fully subject to change when USE_FP_LIB_TABLE is in play.
>>>
>>>
>>> Dick
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> 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
>>
>