kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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
>