kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

Hi

I personally don't think we really need hide it in the master branch,
but if we plan to branch a new release from the master branch I guess
it is ok to ifdef the new functionality to keep status quo for the
scripting part in the release. But I would like to enable it in the
nightlies.

But really, since the functionality is related to scripting I would
like to keep the style for the define, so I propose
KICAD_SCRIPTING_ACTION_MENUS or whatever, just that the
KICAD_SCRIPTING_ prefix is present, to clearly indicate that those are
related. Remember to document the use for it in the devdocs.

Regarding Chris' comment about leaving it out. I see it sort of as a
chicken and egg problem.

People always want more. I have an understanding that some people who
would like to extend kicad with python scripts would also like to be
able spawn dialogs (this statement is not documented). But really, I
think stuff like having a supported and "stable" python API is indeed
a first priority before pulling stuff into master, I also think it
could help motivate some people to actually contribute to the API
definitions if it is callable in a more usable way. I think this could
easily build upon the initial workin in kicad-python. But this really
needs someone, hopefully some of the "python guys or gals" to
cooperate on that. The people working on it initially seems to have
shelved it because there was a lack of feedback.

I think the python API could benefit from some specific use cases, for
example the python based footprint wizards, the python based action
menus, and some more use cases, possibly also including some for use
with eeschema, even though eeschema does not support scripting, sadly.
This could help setting some goals. The most wanted one for me is
being able to plot the schematics like we can with pcbnew right now,
with external scripts.

Nick

2017-01-11 15:19 GMT+01:00 jp charras <jp.charras@xxxxxxxxxx>:
> 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.
>
> 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.
>
>
> 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
>>
>
>
> --
> Jean-Pierre CHARRAS
>
> _______________________________________________
> 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