kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 06/10/2014 02:23 PM, Wayne Stambaugh wrote:
> On 6/10/2014 12:41 PM, Maciej Sumiński wrote:
>> On 06/10/2014 06:02 PM, Dick Hollenbeck wrote:
>>>>> The attached patch will give you an idea of proposed changes.
>>>>>
>>>>> Regards,
>>>>> Orson
>>>>
>>>> We can kill two birds with one stone here.
>>>>
>>>> I like your changes, but they are insufficient to preserve the
>>>> current behaviour.  With a
>>>> little bit of work we can accomplish a couple of useful things.
>>>>
>>>> I think we need to save that footprint in the PROJECT.  Maybe put it
>>>> there upon wxFrame
>>>> destruction, and go get it upon wxFrame creation.  That makes it
>>>> project specific.
>>>>
>>>> I plan on renaming the PROJECT::RPath() infrastructure to RString(). 
>>>> That is it will hold
>>>> wxStrings instead of the goofy RETAINED_PATH.  What is now
>>>> RETAINED_PATH can also go into
>>>> the RString() holder.  enum RETPATH_T becomes RETSTRING_T.
>>>
>>> :
>>>
>>>> I can do the RString() change in the next half day, and it's
>>>> something I intended to do
>>>> anyways.
>>>>
>>>> Orson, this set of changes had to happen anyways as we moved to
>>>> multiple open projects, so
>>>> I  welcome your help and cooperation.
>>>
>>> I committed class PROJECT::GetRString() and SetRString() in rev. 4934,
>>> paving the way for
>>> saving the MODULE in a session and project specific location and
>>> retaining the current UI
>>> behaviour, while clearing some of the clutter in the path of multiple
>>> open projects.
>>
>> Hi Dick,
>>
>> I agree with Lorenzo and Tom - I prefer the module editor to start
>> either empty or with a footprint loaded from library or board, without
>> storing anything inside. How often does it happen to you to make use of
>> the feature? I guess the module editor is primarily invoked to either
>> modify a specific footprint from a board/library or to create a new one.
>> However, I strongly believe we need to cooperate. Sometimes it leads to
>> a compromise, but the final decision is particularly crucial if other
>> main developers agree on the subject. Wayne, Jean-Pierre - I am willing
>> to hear your opinion on the topic.
>> Given everyone shares the view, then having a choice between adding more
>> static fields to the module editor or the above solution, I pick your
>> proposal. Thank you for the advices and the groundwork that will
>> definitely ease the task.
>>
>> Regards,
>> Orson
>>
> 
> The current behavior is fine in the context of being launched from
> Pcbnew when editing a board and/or project libraries.  That being said,
> there are times when it would be useful to be able to edit footprint
> libraries outside the the context of a project.  In other words, have
> the option to use the footprint editor as a stand alone application.  I
> don't know if that is possible given the current design or not.  I have
> not had time to look at the Kiway changes in any detail.
> 
> Wayne


Generally, the Kiway() architecture is an enabling technology, not limiting relative to
prior architecture, I know of no exceptions to this.

The FOOTPRINT_MODULE_EDITOR class has always been tied to libraries in the current
project.  Kiway() did not change that.  It adds the notion of multiple concurrently open
projects, as the python project manager comes to fruition.  Or any other python program on
top.

Moreover, with python on the top, it would be possible to man-handle the FP_LIB_TABLE from
python, stuffing it into a dummy PROJECT, and thereby edit any library that you know
about.  However I have no need for this and won't be coding it.  This does not need to be
the python project manager, it could be a library editor whose top portion is written in
python.

For normal menubar footprint loading, that is tied to the FP_LIB_TABLE code stack.  An
FP_LIB_TABLE can be built on the fly from any source, including python.

Additionally or alternatively, once the pretty parser is in the module editor, a factored
portion being there in support of PASTE, you can use the KiwayExpress() and simply send a
footprint to this KIWAY_PLAYER to be edited directly by this C++ FOOTPRINT_MODULE_EDITOR,
sending from python, essentially bypassing the use of FP_LIB_TABLE altogether and the
toolbar.  However I have no need for this and won't be coding it.

In any case it illustrates that the python -> Kiway stack and the design will not limit
you, it will enable you to morph and leverage the existing code in new ways.


Milestone C) of the modular kicad blueprint calls for multiple concurrent projects to be
open.  I have done this kind of work before.  I need it.  I want to use it.  I thought it
might be something nice to share with the project.  It feels much less so today.

Orson, let me know if you are willing to preserve the current behaviour or if you have a
superior idea.  Obviously your patch, taken alone, is not superior, it is inferior.  The
part that is missing would have had to be done as part of milestone C), so this is
obviously something I anticipated.  That is why class PROJECT exists, that is why I
responded with half the work to the solution today.

If you don't want to do it, I will do it, since I planned on doing it as part of C).