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