Re: [Kicad-developers] Scripting hooks
While I like the idea of hooks I think there are a couple of things that should be implemented before and they should enable part of the workflow that you envision. To be specific, implementing action plugin interface in Project manager. Once this is in place a lot of hook actions could be implemented semi-automatic as an action plugins. On Tuesday, 30 June 2020, 19:17:28 CEST, Eeli Kaikkonen wrote: This post is partly inspired by "Auto-generated backup files: are they useful?" but I have been thinking about this for a longer time. KiCad could benefit from a scripting hook system. There could be pre-hooks and post-hooks for certain actions. Let's take this backup file discussion as an example. One system of backups or file history may not make everyone happy. What if KiCad had hooks for Save etc.? It would call, let's say pcbnew_save_pre() and pcbnew_save_post() python functions which could do anything they want to do with the project. In this case it could create backup files. The script writer would decide how it would be done. It could even use a third-party git or svn python library or external program and make a commit every time the user Saves the document. Let's take another example which was problematic in the past. I don't remember the details, but I think an attempt to enhance the window titles was abandoned because it was somehow problematic. What if there was pcbnew_mainwindow_printwindowtitle_pre(arg1, arg2...) hook which would return a string from the python function? It would take possible parts of the window title as arguments. The python function could form the title as it likes. Third example: pcbnew_plot_gerber_post() could rename and zip the plotted gerber files. See https://gitlab.com/kicad/code/kicad/-/issues/2076. Fourth example: https://gitlab.com/kicad/code/kicad/-/issues/2339. This is obviously something which is impossible to make to satisfy all use cases, but create_new_project_post() hook could create any folders the user wants. It's easy to see that only imagination is the limit, and this would take some needless responsibilities and decisions from the developers and would give freedom to the users. There could and often should be some reasonable default behavior, but the user could decide if it's enough. If the proper infrastructure (asset installer and repository) will be made, the users could share what they have. 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
Re: [Kicad-developers] Scripting hooks
On Wed, Jul 1, 2020 at 10:12 AM mitjan696-ubu...@yahoo.co.uk wrote: > > While I like the idea of hooks I think there are a couple of things that > should be implemented before and they should enable part of the workflow that > you envision. > > To be specific, implementing action plugin interface in Project manager. Once > this is in place a lot of hook actions could be implemented semi-automatic as > an action plugins. I have many times wondered why plugins can't be run from the project manager. There's even no need to add any API; it would be enough if an action plugin could be defined as "generic", not pcbnew specific, and would be visible in the Tools menu of the project manager. There are many tasks which don't need to use KiCad python API. Anyways, I don't think that a better API is a prerequisite for the hook system. There are do difference between the current plugins and the envisioned hooks: 1) Hooks don't need to use KiCad API. Many tasks could be done with the standard python libraries, for example string manipulation and file system manipulation. The hook call could give the necessary data as arguments and the function could return a string or a string list or numerical value. A hook could of course be also more generic without arguments, for example when it manipulates the project folders. And the full KiCad python API would of course be available if needed. 2) Calling hooks is "event based", while calling an action script is done explicitly by the user. Some hook use cases could be replaced by a better action script system (namely implementing free hotkey assignment to call action scripts so that e.g. Save could be replaced by an action script which then calls Save), but not all (like the window title example mentioned in a previous post). 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
Re: [Kicad-developers] Scripting hooks
Regarding the plugin manager: it would be awesome if it could pull updates from the plugin author’s GitHub. Not sure exactly how to handle plugin version checking, KiCAD version compatibility and all the related issues (like security, forks, etc). But it’d be nice if there were a central registry or a simple text box where something as simple as “HiGregSmith/KiCommand” could be entered and the rest happens fairly automatically based either on the structure of the source repo, or a config file supplied in the repo by the plugin author. Simple date check or SHA hash could be used for a “quick” check of config file updates. I’d be happy to collaborate on this and discuss ideas, but I also understand the productivity of getting something up and running with your own ideas first. Greg S. > On Jun 30, 2020, at 6:08 PM, Andrew Lutsenko wrote: > > Plugin manager is in the works: > https://gitlab.com/kicad/code/kicad/-/issues/2242 > There will be some progress over the long weekend. > >> On Tue, Jun 30, 2020 at 3:06 PM Nick Østergaard wrote: >> 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 >> wrote: >> > >> > On Tue, Jun 30, 2020 at 9:17 PM Mark Roszko 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 > ___ > Mailing list:
Re: [Kicad-developers] Scripting hooks
Plugin manager is in the works: https://gitlab.com/kicad/code/kicad/-/issues/2242 There will be some progress over the long weekend. On Tue, Jun 30, 2020 at 3:06 PM Nick Østergaard wrote: > 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 > wrote: > > > > On Tue, Jun 30, 2020 at 9:17 PM Mark Roszko > 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 > ___ 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
Re: [Kicad-developers] Scripting hooks
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 wrote: > > On Tue, Jun 30, 2020 at 9:17 PM Mark Roszko 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
Re: [Kicad-developers] Scripting hooks
On Tue, Jun 30, 2020 at 9:17 PM Mark Roszko 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
Re: [Kicad-developers] Scripting hooks
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. Not everyone is a programmer or wants to be to draw a schematic. A lot of functionality that's not overly specific should be considered integrated in KiCad itself rather than turning KiCad into a strange python IDE. On Tue, Jun 30, 2020 at 1:17 PM Eeli Kaikkonen wrote: > This post is partly inspired by "Auto-generated backup files: are they > useful?" but I have been thinking about this for a longer time. > > KiCad could benefit from a scripting hook system. There could be > pre-hooks and post-hooks for certain actions. Let's take this backup > file discussion as an example. One system of backups or file history > may not make everyone happy. What if KiCad had hooks for Save etc.? It > would call, let's say pcbnew_save_pre() and pcbnew_save_post() python > functions which could do anything they want to do with the project. In > this case it could create backup files. The script writer would decide > how it would be done. > > It could even use a third-party git or svn python library or external > program and make a commit every time the user Saves the document. > > Let's take another example which was problematic in the past. I don't > remember the details, but I think an attempt to enhance the window > titles was abandoned because it was somehow problematic. What if there > was pcbnew_mainwindow_printwindowtitle_pre(arg1, arg2...) hook which > would return a string from the python function? It would take possible > parts of the window title as arguments. The python function could > form the title as it likes. > > Third example: pcbnew_plot_gerber_post() could rename and zip the > plotted gerber files. See > https://gitlab.com/kicad/code/kicad/-/issues/2076. > > Fourth example: https://gitlab.com/kicad/code/kicad/-/issues/2339. > This is obviously something which is impossible to make to satisfy all > use cases, but create_new_project_post() hook could create any folders > the user wants. > > It's easy to see that only imagination is the limit, and this would > take some needless responsibilities and decisions from the developers > and would give freedom to the users. There could and often should be > some reasonable default behavior, but the user could decide if it's > enough. If the proper infrastructure (asset installer and repository) > will be made, the users could share what they have. > > 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 > -- Mark ___ 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
