kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

You're right,  it will be hard to provide compatibility at that point without doing an extensive/intensive work.

I think, at that change point we must provide as much back-compatibility as we can for the scripting, and that's all.

And we must let use the scripting now, with a little warning about this for users. So they can know that the current interface 
isn't frozen yet.



Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 14/03/2013, at 17:44, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:

> On 3/14/2013 11:45 AM, Miguel Angel Ajo Pelayo wrote:
>> First and important: Encapsultion must go first, I'm not against it but the opposite. Read what follows for clarification:
>> 
>> 
>> My concern is about the scripts that build functionality on kicad objects, scripts that people will build and
>> should be maintained separately to KiCad. Now it's not important at all because the scripting base is tiny-0,
>> when it grows, and we make changes to scriptable object interfaces, we will have to take care about this.
>> 
>> So the earlier we encapsulate, the better.
> 
> This is a work in progress.  I think we are getting to the point where
> there is not too much encapsulation work left.  However, this is only
> the first step in the process.  One of the proposed changes is to create
> a standard geometric model for all base objects in Pcbnew and Eeschema
> which means there will likely be some substantial changes to the base
> objects.  Once the encapsulation work is complete, there should be an
> effort made to clean up the some of the low object interfaces to make
> them more coherent.
> 
>> 
>> And in the future, if we change method names, we should (in the script side) provide some fallback/translation 
>> methods with deprecation warning.
>> 
>> * Automated testing:
>> 
>> , I think the scripting to-do should contain the making of a good bunch of test cases that cover all possible
>> object operations that we are willing to support. I talked with Adam Wolf about that, it could be great
>> to get them automatically checked on every commit, we can also extend this to check internal KiCad behaviors 
>> in an automated way :)
>> 
>> 
>> * About build dependencies & swig:
>> 
>> 
>> 
>> Compilation must always work, at this moment, cmake isn't able to fetch dependencies from .i files to .h files, 
>> or at least, I wasn't able to set it up.
>> 
>> In my case I just remove the pcbnew_wrapper.cpp and scripting/pcbnew_wrapper.cxx and called
>> make again, so it compiled gracefully.  
>> 
>> Getting dependencies for that automatically would be highly desired, and must be in my todo list at any point.
>> 
>> 
>> 
>> 
>> 
>> 
>> Miguel Angel Ajo
>> http://www.nbee.es
>> +34911407752
>> skype: ajoajoajo
>> 
>> On 14/03/2013, at 16:37, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:
>> 
>>> On 3/14/2013 11:07 AM, Miguel Angel Ajo Pelayo wrote:
>>>> http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/revision/4001
>>>> 
>>>> Hehe, nice cleanup, it's something that must be done.
>>>> 
>>>> Anyway, interface changes to core objects, should be tracked carefully
>>>> once we have scripting published, 
>>>> a change like this could break scripts working on the field:
>>>> 
>>>> 151
>>>> 
>>>>   void SetPos( const wxPoint& aPoint ) { m_Pos = aPoint; }
>>>> 152
>>>> 
>>>>   const wxPoint GetPos() const { return m_Pos; }
>>>> 
>>>> 174
>>>>   void SetPosition( const wxPoint& aPoint ) { m_Pos = aPoint; }
>>>> 
>>>> 175
>>>>   const wxPoint GetPosition() const { return m_Pos; }
>>>> 
>>>> 
>>>> My opinion is, these changes need to be done, the cleaner, the better,
>>>> but once scripting is widely deployed,
>>>> we must provide some (scripting side wrappers) for compatibility, for
>>>> example redirecting SetPos to SetPosition on scripting,
>>>> and sending an "deprecated" warning for some set of releases.
>>> 
>>> Sorry about that.  I forgot rebuild the Python scripting support to see
>>> if I broke anything.  I'm still getting used to the idea that it is now
>>> part of KiCad.
>>> 
>>> Doesn't this kind of code automatically get updated the next time the
>>> scripting code is reSWIGged or is this something that has to be hand
>>> tweaked every time?  I am familiar with SWIG so if need be, I will fix
>>> the SWIG stuff from now on.  I'm thinking the python scripting is going
>>> to have to closely track the compiled KiCad code for the foreseeable
>>> future.  The will be a great of upheaval with the forthcoming footprint
>>> library table stuff.  The last thing I want to do is stop the
>>> encapsulation work just to support Python scripting.
>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Miguel Angel Ajo
>>>> http://www.nbee.es
>>>> +34911407752
>>>> skype: ajoajoajo
>>>> 
>>> 
>> 
>> 
>