[Kicad-developers] Static variables in module editor
Hi,
I have found a few static variables in the module editor code that I
would like to remove, but I need to know your opinion. The variables are
used to keep the last edited module between editor invocations.
If we want to preserve such behaviour, I will need to add a few more
static variables (for sure VIEW, maybe VIEW_CONTROLS and some stuff
related to the Tool Framework). I would rather avoid such solution.
Furthermore, the footprint stored in the editor is completely
independent - it is not bound to anything on board or library. Do we
need to keep it? If there is a modification done, the user is asked if
he wants to save his work or update a footprint, so there is a little
chance of losing data.
The attached patch will give you an idea of proposed changes.
Regards,
Orson
>From b34bac092cbb63fef2182400a43dd34c2a43fcf6 Mon Sep 17 00:00:00 2001
From: Maciej Suminski
Date: Tue, 10 Jun 2014 09:41:42 +0200
Subject: [PATCH] Removed static BOARD & PCB_SCREEN from module editor.
---
pcbnew/module_editor_frame.h | 1 -
pcbnew/moduleframe.cpp | 28 +---
2 files changed, 5 insertions(+), 24 deletions(-)
diff --git a/pcbnew/module_editor_frame.h b/pcbnew/module_editor_frame.h
index 0bc942f..8f54bae 100644
--- a/pcbnew/module_editor_frame.h
+++ b/pcbnew/module_editor_frame.h
@@ -408,7 +408,6 @@ protected:
/// protected so only friend PCB::IFACE::CreateWindow() can act as sole factory.
FOOTPRINT_EDIT_FRAME( KIWAY* aKiway, wxWindow* aParent );
-static BOARD* s_Pcb; ///< retain board across invocations of module editor
/**
* Function GetComponentFromUndoList
diff --git a/pcbnew/moduleframe.cpp b/pcbnew/moduleframe.cpp
index 913ee70..7fd0273 100644
--- a/pcbnew/moduleframe.cpp
+++ b/pcbnew/moduleframe.cpp
@@ -62,10 +62,6 @@
#include "tools/common_actions.h"
-static PCB_SCREEN* s_screenModule; // the PCB_SCREEN used by the footprint editor
-
-BOARD* FOOTPRINT_EDIT_FRAME::s_Pcb;
-
BEGIN_EVENT_TABLE( FOOTPRINT_EDIT_FRAME, PCB_BASE_FRAME )
EVT_MENU_RANGE( ID_POPUP_PCB_ITEM_SELECTION_START, ID_POPUP_PCB_ITEM_SELECTION_END,
PCB_BASE_FRAME::ProcessItemSelection )
@@ -186,20 +182,15 @@ FOOTPRINT_EDIT_FRAME::FOOTPRINT_EDIT_FRAME( KIWAY* aKiway, wxWindow* aParent ) :
drawFrame->GetGalCanvas()->GetBackend() );
SetGalCanvas( drawPanel );
-if( !s_Pcb )
-{
-s_Pcb = new BOARD();
+m_Pcb = new BOARD();
-// Ensure all layers and items are visible:
-s_Pcb->SetVisibleAlls();
-}
+// Ensure all layers and items are visible:
+m_Pcb->SetVisibleAlls();
-SetBoard( s_Pcb );
+SetBoard( m_Pcb );
-if( !s_screenModule )
-s_screenModule = new PCB_SCREEN( GetPageSettings().GetSizeIU() );
-SetScreen( s_screenModule );
+SetScreen( new PCB_SCREEN( GetPageSettings().GetSizeIU() ) );
GetScreen()->SetCurItem( NULL );
LoadSettings( config() );
@@ -286,15 +277,6 @@ FOOTPRINT_EDIT_FRAME::FOOTPRINT_EDIT_FRAME( KIWAY* aKiway, wxWindow* aParent ) :
FOOTPRINT_EDIT_FRAME::~FOOTPRINT_EDIT_FRAME()
{
-// When user reopens the Footprint editor, user would like to find the last edited item.
-// Do not delete PCB_SCREEN (by the destructor of EDA_DRAW_FRAME)
-SetScreen( NULL );
-
-// Do not allow PCB_BASE_FRAME::~PCB_BASE_FRAME()
-// to delete our precious BOARD, which is also in static FOOTPRINT_EDIT_FRAME::s_Pcb.
-// That function, PCB_BASE_FRAME::~PCB_BASE_FRAME(), runs immediately next
-// as we return from here.
-m_Pcb = 0;
}
--
1.9.1
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
On Tue, Jun 10, 2014 at 10:18:57AM +0200, Maciej Sumiński wrote: > Hi, > > I have found a few static variables in the module editor code that I would > like to remove, but I need to know your opinion. The variables are used to > keep the last edited module between editor invocations. Ah these. I stumbled in them, too... the 'default' thing in pcbnew often works only the first time, until you confirm something; after that, it becomes the new default. Example, text size: default text size is saved in the ini file from the settings and it's used the first time you add text. However when you edit the text side of an object, *that* becomes the new default until you restart pcbnew or edit another object. So it's "default until I have another value picked as default". Curious but it actually works well. > If we want to preserve such behaviour, I will need to add a few more static > variables (for sure VIEW, maybe VIEW_CONTROLS and some stuff related to the > Tool Framework). I would rather avoid such solution. For the OO purists statics are Evil. YMMV. For the current behaviour I think they are the best solution. > Furthermore, the footprint stored in the editor is completely independent - > it is not bound to anything on board or library. Do we need to keep it? If > there is a modification done, the user is asked if he wants to save his work > or update a footprint, so there is a little chance of losing data. Yes, ATM the footprint is untied from the board and everything (correctly, since it lives in the library). Layers are always the 'stock' ones. Still an undecided point in the 'more layer proposal' if libraries will have their own layer set or whatever. -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
On 06/10/2014 10:26 AM, Lorenzo Marcantonio wrote: On Tue, Jun 10, 2014 at 10:18:57AM +0200, Maciej Sumiński wrote: Hi, I have found a few static variables in the module editor code that I would like to remove, but I need to know your opinion. The variables are used to keep the last edited module between editor invocations. Ah these. I stumbled in them, too... the 'default' thing in pcbnew often works only the first time, until you confirm something; after that, it becomes the new default. Example, text size: default text size is saved in the ini file from the settings and it's used the first time you add text. However when you edit the text side of an object, *that* becomes the new default until you restart pcbnew or edit another object. So it's "default until I have another value picked as default". Curious but it actually works well. I see the point of keeping last settings, but should the footprint become a new default too? It is much more than e.g. text size, which is common for many instances. If we want to preserve such behaviour, I will need to add a few more static variables (for sure VIEW, maybe VIEW_CONTROLS and some stuff related to the Tool Framework). I would rather avoid such solution. For the OO purists statics are Evil. YMMV. For the current behaviour I think they are the best solution. Given that we want to preserve the behaviour - I do not see any other sensible solution at the moment. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
On Tue, Jun 10, 2014 at 11:59:12AM +0200, Maciej Sumiński wrote: > I see the point of keeping last settings, but should the footprint become a > new default too? It is much more than e.g. text size, which is common for > many instances. I agree that the whole footprint is a little extreme... IMHO you could happily junk it during the close and start afresh when reopening. As you said there is plenty of confirmation before losing work. -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
On 06/10/2014 03:18 AM, Maciej Sumiński wrote: > Hi, > > I have found a few static variables in the module editor code that I > would like to remove, but I need to know your opinion. The variables are > used to keep the last edited module between editor invocations. > > If we want to preserve such behaviour, I will need to add a few more > static variables (for sure VIEW, maybe VIEW_CONTROLS and some stuff > related to the Tool Framework). I would rather avoid such solution. > > Furthermore, the footprint stored in the editor is completely > independent - it is not bound to anything on board or library. Do we > need to keep it? If there is a modification done, the user is asked if > he wants to save his work or update a footprint, so there is a little > chance of losing data. > > 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. This opens it up for generally any string you need within the lifetime of the project's session, these are not retained on disk. In the road map you should see "paste" in the module editor. This would be the pasting of a pretty string from clipboard into the module editor and replacing any existing footprint. Let's save the footprint in the PROJECT::RString() as a pretty string, and then use a portion of the needed "paste" functionality to restore it when that project has the module editor revisited. This means under the python project manager you have multiple projects open, and each module editor can retain its own module. If the "paste" operation is split into a couple of steps, the "source" of the pretty string can be abstracted. You could find help in the current load footprint from disk code, where that pretty source is from disk. But the idea is general, the pretty string could come from the clipboard, from disk, and now from a RString() as soon as we allocate another RETPATH_T enum value. 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. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
On Tue, Jun 10, 2014 at 08:15:44AM -0500, Dick Hollenbeck wrote: > 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. Wouldn't be better if the footprint were standalone? Footprints at the end 'starts' in the libraries and 'ends' on a board (project). I'd say the footprint in edit is logically in the footprint editor frame (so theorically you could open more than one editor, a useful feature). If the footprint is simply picked from a lib for edit is there a project associated? Maybe the default 'noname' project? It doesn't feel right to me having it tied to the project :P -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
On 06/10/2014 08:22 AM, Lorenzo Marcantonio wrote: > On Tue, Jun 10, 2014 at 08:15:44AM -0500, Dick Hollenbeck wrote: >> 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. > > Wouldn't be better if the footprint were standalone? Footprints at the > end 'starts' in the libraries and 'ends' on a board (project). I'd say > the footprint in edit is logically in the footprint editor frame (so > theorically you could open more than one editor, a useful feature). > > If the footprint is simply picked from a lib for edit is there a project > associated? Maybe the default 'noname' project? > > It doesn't feel right to me having it tied to the project :P The set of libraries in use dictate how the footprint editor operates, its scope, its reach. So it seems we disagree. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
On 10.06.2014 15:22, Lorenzo Marcantonio wrote: On Tue, Jun 10, 2014 at 08:15:44AM -0500, Dick Hollenbeck wrote: 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. Wouldn't be better if the footprint were standalone? Footprints at the end 'starts' in the libraries and 'ends' on a board (project). I'd say the footprint in edit is logically in the footprint editor frame (so theorically you could open more than one editor, a useful feature). If the footprint is simply picked from a lib for edit is there a project associated? Maybe the default 'noname' project? It doesn't feel right to me having it tied to the project :P Hi Lorenzo, To me it also looks simpler (and cleaner) to decouple the footprint/symbol editor. Just open a library file (not an entry from the lib table), edit a footprint/symbol, save the library and use it. That's how it works in most proprietary software. Tom ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
On 06/10/2014 08:47 AM, Tomasz Wlostowski wrote: > On 10.06.2014 15:22, Lorenzo Marcantonio wrote: >> On Tue, Jun 10, 2014 at 08:15:44AM -0500, Dick Hollenbeck wrote: >>> 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. >> >> Wouldn't be better if the footprint were standalone? Footprints at the >> end 'starts' in the libraries and 'ends' on a board (project). I'd say >> the footprint in edit is logically in the footprint editor frame (so >> theorically you could open more than one editor, a useful feature). >> >> If the footprint is simply picked from a lib for edit is there a project >> associated? Maybe the default 'noname' project? >> >> It doesn't feel right to me having it tied to the project :P >> > Hi Lorenzo, > > To me it also looks simpler (and cleaner) to decouple the > footprint/symbol editor. Just open a library file (not an entry from the > lib table), edit a footprint/symbol, save the library and use it. That's > how it works in most proprietary software. > > Tom This hypothetical patch could have been submitted at any time in KiCad's history. What I am doing now is preserving the existing UI, while at the same time picking up paste and support for multiple open projects. Tom, BTW, the fact that you addressed this email singly to Lorenzo, who is not actually involved in the coding effort, I find very offensive. I don't have any problem defending the current UI behaviour, right up to the point where somebody offers an improvement in the form of a patch. Even if that means disagreeing with both Tom and Lorenzo. And frankly, if I was going to write a pure library editor, free of project roots, then I'd do it in python so I could manhandle the library tables. Nothing happens without taking those into consideration without losing the storage file format abstraction that we have in place. Dick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
On 10.06.2014 16:06, Dick Hollenbeck wrote: On 06/10/2014 08:47 AM, Tomasz Wlostowski wrote: On 10.06.2014 15:22, Lorenzo Marcantonio wrote: On Tue, Jun 10, 2014 at 08:15:44AM -0500, Dick Hollenbeck wrote: 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. Wouldn't be better if the footprint were standalone? Footprints at the end 'starts' in the libraries and 'ends' on a board (project). I'd say the footprint in edit is logically in the footprint editor frame (so theorically you could open more than one editor, a useful feature). If the footprint is simply picked from a lib for edit is there a project associated? Maybe the default 'noname' project? It doesn't feel right to me having it tied to the project :P Hi Lorenzo, To me it also looks simpler (and cleaner) to decouple the footprint/symbol editor. Just open a library file (not an entry from the lib table), edit a footprint/symbol, save the library and use it. That's how it works in most proprietary software. Tom This hypothetical patch could have been submitted at any time in KiCad's history. What I am doing now is preserving the existing UI, while at the same time picking up paste and support for multiple open projects. Tom, BTW, the fact that you addressed this email singly to Lorenzo, who is not actually involved in the coding effort, I find very offensive. Hi Dick, I clicked send, replying to Lorenzo's comment right when your next e-mail came. Sorry for that, I didn't intend to offend anybody. Regards, Tom ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
> > I clicked send, replying to Lorenzo's comment right when your next > e-mail came. Sorry for that, Thanks Tom, apology accepted. Another thing we get by supporting multiple open projects and paste, is we are only one step away (i.e. COPY) from having copy and paste across projects, and therefore libraries. This is leaner than the current methodology of having to switch "current libraries" to move a footprint from one to another. And while yes code improvements could also have brought this, what we're seeing with this multiple project approach is the footprint movement support *without changing existing code* to any great extent. That sounds like free to me. Just have to add paste, and copy. I wanted paste so I can grab text from a page like this https://raw.githubusercontent.com/KiCad/Transistors_SMD.pretty/master/sc70-6.kicad_mod or this https://github.com/liftoff-sr/pretty_footprints/blob/master/100-LQFP.kicad_mod from my browser using the browser's page COPY support, and then simply paste it into the module editor. BTW, notice: 1) the http links from this page to each footprint's raw format: https://github.com/liftoff-sr/pretty_footprints 2) The fp_lib_table fragment which facilitates rapid installation of this library into the library table dialog editor. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
> > I wanted paste so I can grab text from a page like this > > > https://raw.githubusercontent.com/KiCad/Transistors_SMD.pretty/master/sc70-6.kicad_mod > > or this > > > https://github.com/liftoff-sr/pretty_footprints/blob/master/100-LQFP.kicad_mod > > from my browser using the browser's page COPY support, and then simply paste > it into the > module editor. > > BTW, notice: > > 1) the http links from this page to each footprint's raw format: > > https://github.com/liftoff-sr/pretty_footprints Well sorry, the links don't go to the *RAW* format, but could and should. > > 2) The fp_lib_table fragment which facilitates rapid installation of this > library into the > library table dialog editor. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
>> 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. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
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 ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
On Tue, Jun 10, 2014 at 09:06:30AM -0500, Dick Hollenbeck wrote: > And frankly, if I was going to write a pure library editor, free of project > roots, then > I'd do it in python so I could manhandle the library tables. Nothing happens > without That's why I said it doesn't feel right to tie the library editor to the current project, the module can live alone (as an .emp or whatever) without ties to other objects. Unless of course we decide that it depends on the project for something (no idea of what lives in a project) but then libraries would probably depend on project too... -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
On 06/10/2014 11:41 AM, 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, We are debating "the current UI behaviour" vs. "some new undefined UI behaviour". Here is the current behaviour, which I'm arguing should be preserved: CURRENT BEHAVIOUR: == On the *second or subsequent* time you enter the module editor within a given process session, show the MODULE you were working on from the previous life of FOOTPRINT_EDIT_FRAME. If its the first time that FOOTPRINT_EDIT_FRAME is shown within a given process session, then show an empty screen (no module). Note that it is not uncommon to close the FOOTPRINT_EDIT_FRAME if you only have a single monitor. When you re-enter the module editor, Jean-Pierre and I thought that it made sense to go back to the MODULE that you had been working on. Note that the MODULE "you had been working on" *must* have come from either the BOARD, or one of the libraries associated with what: the current project. I think this dovetails precisely into the last part of your last sentence above. The Kiway() window DNA gives each instantiation of the FOOTPRINT_EDIT_FRAME its own PROJECT. This is not going to change anytime soon. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
<> >>> 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, > > > We are debating "the current UI behaviour" vs. "some new undefined UI > behaviour". > > Here is the current behaviour, which I'm arguing should be preserved: > > CURRENT BEHAVIOUR: > == > On the *second or subsequent* time you enter the module editor within a given > process > session, show the MODULE you were working on from the previous life of > FOOTPRINT_EDIT_FRAME. > > If its the first time that FOOTPRINT_EDIT_FRAME is shown within a given > process session, > then show an empty screen (no module). > > Note that it is not uncommon to close the FOOTPRINT_EDIT_FRAME if you only > have a single > monitor. When you re-enter the module editor, Jean-Pierre and I thought that > it made > sense to go back to the MODULE that you had been working on. > > Note that the MODULE "you had been working on" *must* have come from either > the BOARD, or > one of the libraries associated with what: the current project. I think this > dovetails > precisely into the last part of your last sentence above. > > The Kiway() window DNA gives each instantiation of the FOOTPRINT_EDIT_FRAME > its own > PROJECT. This is not going to change anytime soon. I agree with Dick: when reopening an editor, reopen the latest document(s) previously opened makes sense, and moreover is a common feature in many editors. My text editor does that, and this feature save a lot of time for me. And Kicad too, which reopens the latest project. By the way, Altium also does that. I fully understand the fact static variables should be removed. Obviously, I did do yet used PROJECT::GetRString(), but I am thinking this is a powerful feature to save some info during a session (in this case the S expression description of the footprint). So I am thinking it is worth to save/retrieve the currently edited footprint to an "RString", for at least 2 reasons: - the current behavior is not so bad. - The work to save/retrieve will also be very useful, because I am thinking it is 99% of the code needed to copy/paste footprints and boards (or selected items in a board) to/from the clipboard. So, I am thinking it is worth to keep the current behavior, now the PROJECT::SetRString() and PROJECT::GetRString() exists, especially if we are thinking also to the copy/paste feature (between instances of Pcbnew or ModEdit). -- Jean-Pierre CHARRAS ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
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 ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
On 06/10/2014 10:29 PM, Dick Hollenbeck wrote: 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
Re: [Kicad-developers] Static variables in module editor
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
Re: [Kicad-developers] Static variables in module editor
On Tue, Jun 10, 2014 at 08:58:04PM +0200, jp charras wrote: > when reopening an editor, reopen the latest document(s) previously > opened makes sense, and moreover is a common feature in many editors. > My text editor does that, and this feature save a lot of time for me. > And Kicad too, which reopens the latest project. > By the way, Altium also does that. I think that to 'solve' this we should decide if there could be more than one open editor. What if I open a new one, then close both, and then open another? There are two 'last' objects in this case... If the 'reopen last' feature is desired then the project object could be a good place to store it. When used standalone (for library edit only) some kind of noname/dummy project could be provided for it. Or maybe only keep the last for edits done in the context of a project (no project->no place to store the last one). -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
On 06/10/2014 04:14 PM, Lorenzo Marcantonio wrote: > On Tue, Jun 10, 2014 at 08:58:04PM +0200, jp charras wrote: >> when reopening an editor, reopen the latest document(s) previously >> opened makes sense, and moreover is a common feature in many editors. >> My text editor does that, and this feature save a lot of time for me. >> And Kicad too, which reopens the latest project. >> By the way, Altium also does that. > > I think that to 'solve' this we should decide if there could be more > than one open editor. What if I open a new one, then close both, and > then open another? There are two 'last' objects in this case... Stuff it. No one cares. Its already been solved. > If the 'reopen last' feature is desired then the project object could be > a good place to store it. When used standalone (for library edit only) > some kind of noname/dummy project could be provided for it. Or maybe > only keep the last for edits done in the context of a project (no > project->no place to store the last one). > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
On 10.06.2014 16:40, Dick Hollenbeck wrote: I clicked send, replying to Lorenzo's comment right when your next e-mail came. Sorry for that, Thanks Tom, apology accepted. Another thing we get by supporting multiple open projects and paste, is we are only one step away (i.e. COPY) from having copy and paste across projects, and therefore libraries. This is leaner than the current methodology of having to switch "current libraries" to move a footprint from one to another. And while yes code improvements could also have brought this, what we're seeing with this multiple project approach is the footprint movement support *without changing existing code* to any great extent. That sounds like free to me. Dick, I don't see any issue with adding copy/paste and using s-exprs is the right way of doing so. But this discussion was about getting rid of a bunch of static variables. My proposal would be to: 1. Remove the statics, temporarily removing the retain-last-edited-footprint feature. 2. Add copy/paste in both pcbnew main window and the module editor. 3. Once the copy/paste code is verified, use PROJECT::GetRString() to bring back the last footprint feature. This way we would have ultimately less coding to do at the cost of temporarily disabling a feature that is IMHO not absolutely necessary for Kicad to work. BTW. A little suggestion for Get/SetRString(): how about changing the enum index to a string? This way we'd have one less enum to manage and won't have to recompile everything whenever a new RString is added. Regards, Tom ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
On 06/10/2014 04:14 PM, Lorenzo Marcantonio wrote:
> On Tue, Jun 10, 2014 at 08:58:04PM +0200, jp charras wrote:
>> when reopening an editor, reopen the latest document(s) previously
>> opened makes sense, and moreover is a common feature in many editors.
>> My text editor does that, and this feature save a lot of time for me.
>> And Kicad too, which reopens the latest project.
>> By the way, Altium also does that.
>
> I think that to 'solve' this we should decide if there could be more
> than one open editor.
I don't know what you don't know. I know Orson seems to have a good
understanding of the
architecture and the need. And since he and I are coding this, that is
probably good
enough. In his absence, I code it.
I don't know what you don't know.
Lorenzo, please read the modular kicad blueprint. It clearly states that the
python
project manager opens more than one project, whereas single top and the C++
project
manager have one KIWAY. Each KIWAY has its own PROJECT. All the windows in a
project are
tied to the same PROJECT in a KIWAY. The C++ project manager and the
single_top KIWAY,
are both single instance. The python project manager will have multiple
KIWAYs, from
KIWAY_MGR class.
All the windows associated with a single PROJECT are given access to it, the
PROJECT,
through window DNA. The actual DNA is the contents of KIWAY_HOLDER.
The purpose of milestone B) is to get PROJECT renaming, opening, and creating,
solid.
These are not solid yet, we are only 50% through milestone B).
The KIWAY window DNA is the KIWAY_HOLDER object, present now in all the
wxWindows we use
(except those in the C++ project manager which are ABOVE the KIWAY.)
The source to the KIWAY_HOLDER::Prj() is here.
PROJECT& KIWAY_HOLDER::Prj() const
{
return Kiway().Prj();
}
Yes, there can be more than one open FOOTPRINT_EDITOR_FRAME under the python
project
manager only. But each will have its own PROJECT, and therefore its own last
module.
> What if I open a new one, then close both, and
> then open another?
Go to bed, this is minus one open.
> There are two 'last' objects in this case...
Each editor has its own window DNA, and therefore its own last MODULE because
Prj()
returns something different for each. One might have access to different
libraries,
particularly the Project Specific libraries are unique for each project. The
global ones
are shared and common, and therefore accessible from both editors.
> If the 'reopen last' feature is desired then the project object could be
> a good place to store it. When used standalone (for library edit only)
> some kind of noname/dummy project could be provided for it. Or maybe
> only keep the last for edits done in the context of a project (no
> project->no place to store the last one).
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
On 06/10/2014 04:39 PM, Tomasz Wlostowski wrote: > On 10.06.2014 16:40, Dick Hollenbeck wrote: >>> >>> I clicked send, replying to Lorenzo's comment right when your next >>> e-mail came. Sorry for that, >> >> >> Thanks Tom, apology accepted. >> >> Another thing we get by supporting multiple open projects and paste, is we >> are only one >> step away (i.e. COPY) from having copy and paste across projects, and >> therefore libraries. >> >> This is leaner than the current methodology of having to switch "current >> libraries" to >> move a footprint from one to another. And while yes code improvements could >> also have >> brought this, what we're seeing with this multiple project approach is the >> footprint >> movement support *without changing existing code* to any great extent. >> That sounds like >> free to me. >> > Dick, > > I don't see any issue with adding copy/paste and using s-exprs is the > right way of doing so. But this discussion was about getting rid of a > bunch of static variables. > > My proposal would be to: > 1. Remove the statics, temporarily removing the > retain-last-edited-footprint feature. > 2. Add copy/paste in both pcbnew main window and the module editor. > 3. Once the copy/paste code is verified, use PROJECT::GetRString() to > bring back the last footprint feature. > > This way we would have ultimately less coding to do at the cost of > temporarily disabling a feature that is IMHO not absolutely necessary > for Kicad to work. It was not that much coding, less than 30 lines I think. I did not do the PASTE support yet, but the retention of the last footprint is in rev. 4937. It took me about 1/2 hour and that's longer than it would have taken had I consulted the places I've use this support elsewhere. I committed a modified version of Orson's patch first. But that was crashing my system, based on wxString static constructors in PAGE_INFO. So I removed those in favor of wxChar[] before making that commit. Also there was going to be a problem with setting m_Pcb in the footprint editor, then turning around and calling SetBoard(). This essentially deleted the m_Pcb that you were setting; check the source to SetBoard(). The original UI has been preserved, with a little testing, again rev. 4937. > BTW. A little suggestion for Get/SetRString(): how about changing the > enum index to a string? This way we'd have one less enum to manage and > won't have to recompile everything whenever a new RString is added. I initially liked this idea. But when you consider that the string keys need to be coordinated when used in different source modules, this would bring the declaration of those strings into a header file. Then you are right back from whence you came, having to recompile based on changes to *that* header file. So no, I'm not currently sold on this idea. If you want to go ahead and add some spares to RSTRING_T now, calling them general names, you can allocate them using the general name for awhile, and then recompile only at a later time when you give them purposeful names. SPARE1, SPARE2, etc. But I doubt this is worth it. > > Regards, > Tom > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
On Tue, Jun 10, 2014 at 04:55:10PM -0500, Dick Hollenbeck wrote: > Lorenzo, please read the modular kicad blueprint. It clearly states that the > python > project manager opens more than one project, whereas single top and the C++ > project > manager have one KIWAY. Each KIWAY has its own PROJECT. All the windows in > a project are > tied to the same PROJECT in a KIWAY. The C++ project manager and the > single_top KIWAY, > are both single instance. The python project manager will have multiple > KIWAYs, from > KIWAY_MGR class. > > All the windows associated with a single PROJECT are given access to it, the > PROJECT, > through window DNA. The actual DNA is the contents of KIWAY_HOLDER. > > The purpose of milestone B) is to get PROJECT renaming, opening, and > creating, solid. > These are not solid yet, we are only 50% through milestone B). > > The KIWAY window DNA is the KIWAY_HOLDER object, present now in all the > wxWindows we use > (except those in the C++ project manager which are ABOVE the KIWAY.) OK, got that. What if I want to do work without a project open, i.e. only to draw modules for a library? What kind of project will pcbnew have access to? Stuff the module in that project, as you said in the beginning. BTW it will still works without a project manager like today i.e. calling directly pcbnew/eeschema without passing from it? -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
On 11.06.2014 07:30, Dick Hollenbeck wrote: On 06/10/2014 04:39 PM, Tomasz Wlostowski wrote: On 10.06.2014 16:40, Dick Hollenbeck wrote: I clicked send, replying to Lorenzo's comment right when your next e-mail came. Sorry for that, Thanks Tom, apology accepted. Another thing we get by supporting multiple open projects and paste, is we are only one step away (i.e. COPY) from having copy and paste across projects, and therefore libraries. This is leaner than the current methodology of having to switch "current libraries" to move a footprint from one to another. And while yes code improvements could also have brought this, what we're seeing with this multiple project approach is the footprint movement support *without changing existing code* to any great extent. That sounds like free to me. Dick, I don't see any issue with adding copy/paste and using s-exprs is the right way of doing so. But this discussion was about getting rid of a bunch of static variables. My proposal would be to: 1. Remove the statics, temporarily removing the retain-last-edited-footprint feature. 2. Add copy/paste in both pcbnew main window and the module editor. 3. Once the copy/paste code is verified, use PROJECT::GetRString() to bring back the last footprint feature. This way we would have ultimately less coding to do at the cost of temporarily disabling a feature that is IMHO not absolutely necessary for Kicad to work. It was not that much coding, less than 30 lines I think. I did not do the PASTE support yet, but the retention of the last footprint is in rev. 4937. It took me about 1/2 hour and that's longer than it would have taken had I consulted the places I've use this support elsewhere. Dick, I agree it's very easy if you want to copy an entire footprint from one library to another. But things may get complicated for general-purpose copy paste with arbitrarily selected items. Imagine that you want to copy-paste a bunch of traces/vias from one PCB file to another. What happens with the nets? Should one ignore the nets of the copied objects and propagate the nets of the items in target design that are colliding with the pasted items? Or store the netcode<>netname mapping in the clipboard too and add new nets to the target design? Regards, Tom ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
Le 11/06/2014 09:36, Tomasz Wlostowski a écrit : > On 11.06.2014 07:30, Dick Hollenbeck wrote: >> On 06/10/2014 04:39 PM, Tomasz Wlostowski wrote: >>> On 10.06.2014 16:40, Dick Hollenbeck wrote: > > I clicked send, replying to Lorenzo's comment right when your next > e-mail came. Sorry for that, Thanks Tom, apology accepted. Another thing we get by supporting multiple open projects and paste, is we are only one step away (i.e. COPY) from having copy and paste across projects, and therefore libraries. This is leaner than the current methodology of having to switch "current libraries" to move a footprint from one to another. And while yes code improvements could also have brought this, what we're seeing with this multiple project approach is the footprint movement support *without changing existing code* to any great extent. That sounds like free to me. >>> Dick, >>> >>> I don't see any issue with adding copy/paste and using s-exprs is the >>> right way of doing so. But this discussion was about getting rid of a >>> bunch of static variables. >>> >>> My proposal would be to: >>> 1. Remove the statics, temporarily removing the >>> retain-last-edited-footprint feature. >>> 2. Add copy/paste in both pcbnew main window and the module editor. >>> 3. Once the copy/paste code is verified, use PROJECT::GetRString() to >>> bring back the last footprint feature. >>> >>> This way we would have ultimately less coding to do at the cost of >>> temporarily disabling a feature that is IMHO not absolutely necessary >>> for Kicad to work. >> >> It was not that much coding, less than 30 lines I think. I did not do >> the PASTE support >> yet, but the retention of the last footprint is in rev. 4937. It took >> me about 1/2 hour >> and that's longer than it would have taken had I consulted the places >> I've use this >> support elsewhere. > Dick, > > I agree it's very easy if you want to copy an entire footprint from one > library to another. But things may get complicated for general-purpose > copy paste with arbitrarily selected items. > > Imagine that you want to copy-paste a bunch of traces/vias from one PCB > file to another. What happens with the nets? Should one ignore the nets > of the copied objects and propagate the nets of the items in target > design that are colliding with the pasted items? Or store the > netcode<>netname mapping in the clipboard too and add new nets to the > target design? > > Regards, > Tom copying items from a board to an other board creates very tricky issues. copying items inside a board (i.e. duplicate items) is also not trivial. Obvious issues are related to: netcode and netname netclasses zones (merging or not) duplicate reference designators and time stamps Moreover, reference designators and time stamps coming from an other board could have no meaning for the current schematic. For me, reference designators and time stamps are the main issue. Having a good copy/paste tool is a good thing. How to efficiently use this tool is an other story. -- Jean-Pierre CHARRAS ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
On Wed, Jun 11, 2014 at 10:03:19AM +0200, jp charras wrote: > For me, reference designators and time stamps are the main issue. > > Having a good copy/paste tool is a good thing. For starters doing like eeschema (i.e. razing the data) would be sufficient. You'll "only" need to fix the designators and reload the netlist/rebuilding the board net. For repetitive things like I/O stages on a board with plenty of space would be useful and consistent with how eeschema works. -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
On 06/11/2014 02:36 AM, Tomasz Wlostowski wrote: > On 11.06.2014 07:30, Dick Hollenbeck wrote: >> On 06/10/2014 04:39 PM, Tomasz Wlostowski wrote: >>> On 10.06.2014 16:40, Dick Hollenbeck wrote: > > I clicked send, replying to Lorenzo's comment right when your next > e-mail came. Sorry for that, Thanks Tom, apology accepted. Another thing we get by supporting multiple open projects and paste, is we are only one step away (i.e. COPY) from having copy and paste across projects, and therefore libraries. This is leaner than the current methodology of having to switch "current libraries" to move a footprint from one to another. And while yes code improvements could also have brought this, what we're seeing with this multiple project approach is the footprint movement support *without changing existing code* to any great extent. That sounds like free to me. >>> Dick, >>> >>> I don't see any issue with adding copy/paste and using s-exprs is the >>> right way of doing so. But this discussion was about getting rid of a >>> bunch of static variables. >>> >>> My proposal would be to: >>> 1. Remove the statics, temporarily removing the >>> retain-last-edited-footprint feature. >>> 2. Add copy/paste in both pcbnew main window and the module editor. >>> 3. Once the copy/paste code is verified, use PROJECT::GetRString() to >>> bring back the last footprint feature. >>> >>> This way we would have ultimately less coding to do at the cost of >>> temporarily disabling a feature that is IMHO not absolutely necessary >>> for Kicad to work. >> >> It was not that much coding, less than 30 lines I think. I did not do the >> PASTE support >> yet, but the retention of the last footprint is in rev. 4937. It took me >> about 1/2 hour >> and that's longer than it would have taken had I consulted the places I've >> use this >> support elsewhere. > Dick, > > I agree it's very easy if you want to copy an entire footprint from one > library to another. As a user I just want to PASTE from my browser or text editor, into the module editor, short term. This is low hanging fruit with a high ROI. The design or coding of the rest requires more time than I want to spend. It has a different ROI. I would be fighting to be first in line to say thank you for it however. > But things may get complicated for general-purpose > copy paste with arbitrarily selected items. > > Imagine that you want to copy-paste a bunch of traces/vias from one PCB > file to another. What happens with the nets? Should one ignore the nets > of the copied objects and propagate the nets of the items in target > design that are colliding with the pasted items? Or store the > netcode<>netname mapping in the clipboard too and add new nets to the > target design? > > Regards, > Tom > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
