kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

On Tue, Jan 10, 2017 at 05:12:56PM +0100, Jean-Samuel Reynaud wrote:
> 
> 
> Ok I understand, but Is it mean that we have to disable python scripting
> in all build by default ?

I can't make that call and I don't think it will be made. I do think we
shouldn't be encouraging *more* use of it at this point, though.

> 
> On daily build I manage, its activated by default...
> 
> On my side I will modify all plugin I use if the API change. They are
> based on a dev branch so I accept that.

You are much more capable of this than most people, I think. My concerns
are not specifically about you. I'm sure you find this feature useful;
that doesn't mean it's for full inclusion in KiCad proper.

> 
> An other point is that master branch is a *dev* branch ? So modification
> on file format, API... can happen.

...what?

> 
> Regards,
> Le 10/01/2017 à 16:54, Chris Pavlina a écrit :
> > 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
>