kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 1/11/2017 9:19 AM, jp charras wrote:
> Le 11/01/2017 à 14:37, Jean-Samuel Reynaud a écrit :
>> Hi all,
>>
>> So concerning this feature. You prefer to keep it on hold or I create a
>> patch without the python example (and code formatting fixes ;)
> 
> Hi, Jean-Samuel,
> 
> Here is my opinion:
> 
> I see 2 different things:
> 1_) the new Action Plugin feature and the ability to load a python script in pcbnew outside the
> Python console.
> 2-) the ability to run a plugin from a menu in the board editor by any user.
> 
> I am thinking the 1-) is good.
> However it needs to be fixed (especially because plugins can be now reloaded (updated) from
> currently the footprint wizard selector dialog
> for me, ACTION_PLUGINS::register_action is buggy.
> 
> Pay a particular attention to the fact plugins can be *now* updated (when the source file has
> changed), and therefore menus can also be updated.
> the "PCB_EDIT_FRAME::createActionPluginMenus()" method calls Connect, but Disconnect is never called
> by destructors.
> It can create issues when updating scripts, because it could be called more than once.

If you need to update the menus when a script file changes, you would
have to connect a wxFileWatcherEvent to the appropriate wxMainFrame
object to monitor the loaded script file and update the menus
accordingly.  It can be done but I would proceed with caution here.

> 
> Have a look into FOOTPRINT_WIZARDS::register_wizard( FOOTPRINT_WIZARD* aWizard ), and into the
> commit 4f46f79cf0d601ec18fe685a414e8a778a9c143b
> 
> 2-) From my point of view it should be (at least for now) only available if a specific option (for
> instance "KICAD_ENABLE_ACTION_MENUS" is enabled (and of course not enabled by default).
> It must be reserved to developers who know what they are doing, and not yet accessible to users.

The way I see it is there are two types of scripts.  Scripts that change
the internal state of the board objects and scripts that don't.  Scripts
that change the internal state of the board objects are where the
potential issues arise.  There is far less risk for scripts that don't
change the internal state of the board.  For example, the footprint
generator wizard doesn't change the anything on the current board so
there is no risk of it causing issues other than incorrect footprints or
throwing python exceptions is very low.  The problem is if we disable
this feature to prevent users from shooting themselves in the foot by
screwing up the board object states, we also prevent users who aren't
interested in messing with the internal board state from writing
potentially useful scripts.  There is no ideal solution here at the
moment.  We have to decide whether we error on the side of caution or
not.  I generally am comfortable with giving users enough rope to hang
themselves but I may be in the minority here.

> 
> 
> My last remark:
> To load python scripts (wizards and other python script) KICAD_SCRIPTING_WXPYTHON is not mandatory.
> KICAD_SCRIPTING is enough.
> 
> 
> Courage, Jean-Samuel.
> 
>>
>> Regards,
>> Le 10/01/2017 à 18:23, Wayne Stambaugh a écrit :
>>> 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
>>>>
>>>
>>> _______________________________________________
>>> 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
>>
> 
>