kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #27122
Re: Current state of ActionPlugin
Here's my two cents. I share JP and Chris' concerns about developing
python scripts. As project leader, I can see where a lot of things can
go seriously wrong. Maybe we should make it clear that there should be
no expectation from python developers that the api will remain stable
during development or between stable releases so I'm comfortable
addressing anyone who makes fuss about api changes. I'm also
comfortable telling python devs if you break it you get to keep both
pieces. We are also under no obligation to include python scripts that
are called by this interface.
That being said, I understand the usefulness of the python scripting. I
don't want to cut off python developers at the knees because of
potential issues. I'm OK with this patch as long as we do not include
any python scripts that get called by this patch. In other words, the
user bears all responsibility for the performance of their python
scripts not the kicad project.
On 1/10/2017 10:54 AM, Chris Pavlina wrote:
> What do you do when the internal APIs change and the plugins stop
> working?
>
> I think encouraging people to use this is very dangerous. It is tied so
> much into our internal APIs at the moment. The more people who use it,
> the more everybody is going to scream every single time we change
> anything. We have so much poorly structured code that needs to be
> rewritten - I'm sure a lot of it *will* be when it comes time to remove
> the legacy canvas. If we end up with this many users of the scripting
> API, we will never be able to touch anything again without breaking
> everything.
>
> Wayne, JP: I'm making an appeal to you now to be conservative with
> what you accept for use with the scripting API. This would be a very bad
> point to lock ourselves into having to stabilize it as is. I do not
> think we should be doing this until an interposing layer with a
> formalized, stable API can be created.
>
> On Tue, Jan 10, 2017 at 04:25:10PM +0100, Jean-Samuel Reynaud wrote:
>> Hi,
>>
>> Just from my point of view:
>> We use some python plugin currently and it's not really easy to open
>> each time python console (and remember plugins name, call mode...).
>>
>> I'm agree with you: During devs of scripts it's crashing and my devs
>> have to find the rigth way to process.
>>
>> But this kind of feature can increase number of users/devs of this kind
>> of scripts and raise crash case easily.
>>
>> Regards,
>> Le 10/01/2017 à 16:00, Chris Pavlina a écrit :
>>> Frankly I don't think we should be encouraging users to use the Python
>>> API until it is significantly improved. The issues JP raises make the
>>> API completely unsuitable for plugin use. It's opaque and no users have
>>> any idea how to write robust Python plugins given the current state of
>>> the API.
>>>
>>> On Jan 10, 2017 09:55, "jp charras" <jp.charras@xxxxxxxxxx
>>> <mailto:jp.charras@xxxxxxxxxx>> wrote:
>>>
>>> Le 10/01/2017 à 15:18, Maciej Sumiński a écrit :
>>> > Hi Jean-Samuel,
>>> >
>>> > I think your patch will facilitate use of 3rd party python plugins, as
>>> > the current way of executing commands from the Python shell is not
>>> quite
>>> > user friendly. I vote for merging the patch, but we need to fix some
>>> > code formatting issues first.
>>> >
>>> > Also, I wonder if it would be the right thing to group menu entries by
>>> > their categories to create submenus. It could be a simple way to
>>> > organize the actions provided by python plugins. Just an idea.
>>> >
>>> > Another question is about the following lines:
>>> > + if( IsGalCanvasActive() )
>>> > + {
>>> > + UseGalCanvas( GetGalCanvas() );
>>> > + }
>>> >
>>> > What is exactly the goal here? If it is only about refreshing the
>>> > canvas, then a simple Refresh() call should fix the problem.
>>> >
>>> > Regards,
>>> > Orson
>>> >
>>>
>>> This is a good work.
>>> Thanks Jean-Samuel.
>>>
>>> However, before merging we have to take care of issues which can
>>> easily crash Pcbnew:
>>> Because a python script can modify the board outside the control of
>>> pcbnew edit functions, I am
>>> thinking problems will arise with undo/redo lists (invalid
>>> pointers), ratsnest data and certainly a
>>> few other things.
>>>
>>> Especially for scripts which add or delete items, or change
>>> connectivity.
>>>
>>> Of course, undo/redo lists are alway incorrect after running such
>>> scripts.
>>> This is already a known issue for scripts that are run from the
>>> Pcbnew python console.
>>>
>>> --
>>> Jean-Pierre CHARRAS
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> <https://launchpad.net/~kicad-developers>
>>> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> <https://launchpad.net/~kicad-developers>
>>> More help : https://help.launchpad.net/ListHelp
>>> <https://help.launchpad.net/ListHelp>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help : https://help.launchpad.net/ListHelp
>>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
Follow ups
References