I like the sound of this idea, it could definitely help the workflow for a lot of people.
What may be related to this is some properly "plugin" manager such that it is easier to bundle some script and have some script installed external, similar to the freecad addon manager. I don't remember if anyone is seriously working on that, I sorta expect that to be on hold unstill eeschema gets scripting support. On Tue, 30 Jun 2020 at 21:43, Eeli Kaikkonen <eeli.kaikko...@gmail.com> wrote: > > On Tue, Jun 30, 2020 at 9:17 PM Mark Roszko <mark.ros...@gmail.com> wrote: >> >> While more extensibility is great. I can only say expecting the user to use >> python exclusively for adding the new behavior like for issue #2339 is very >> crude. > > > I'm not saying any possible feature which can be replaced with a script > should be replaced. It must be decided case by case. I don't even say that > these examples are something where an internal feature should be replaced > with a hook. They are just possible examples to show what could be possible. > Just think about it this way: > > 1. Which one is better, just let the users wait for the feature to be > implemented, or add a hook which makes it possible to implement it right away > in a simple way in a script and then let the users wait for it to be > implemented in KiCad proper later? > > 2. Each hook makes it possible to add any imaginable functionality, not just > one feature wish. > > 3. Adding a hook doesn't take anything away, it just adds possibilities. > > 4. Any developer is still free to implement anything in C++. Like now they > are free to implement a functionality which has existed only in an action > script before. > > 5. Adding a hook doesn't change the UI or the behavior in any way. They > wouldn't cause any bugs if the backend for the hook system is good. Hooks > could be added even for bugfix releases. It may be much better than waiting > for one or two years for the next feature release. > > >> >> Not everyone is a programmer > > > Sure. But big problems with scripting have been 1) the unstable API and 2) > the lack of asset infrastructure. Both are being worked on. When KiCad > scripting gets more traction and the scripts are easier to share and install, > not everyone needs to be a programmer and still can easily benefit from the > work from others. The potential number of python developers for simple > scripts like string handling and generic file manipulation is certainly > larger than the amount of potential C++ developers. > > And if we take that #2339 as an example, it would require a real GUI in KiCad > proper (because it would need a way to manipulate the list of folders). A > python script would be one a couple of python functions and a list of text > strings. If someone writes the script, anyone can change the list of > strings, there's no need to be a programmer to change the names of the > folders. So, which one would be the better option: 1) add a simple hook to > make it possible and implement the GUI later, or 2) not make it possible > until someone implements the GUI? > > Eeli Kaikkonen > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
