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
