New Feature - Addon Manager for developers

[Joel_graff]

So after posting an update to the trails wb, I was musing on the value of having a library of FreeCAD-specific Python routines that are useful across workbenches:

https://forum.freecadweb.org/viewtopic. ... &start=810


I know there's code like that scattered throughout the wiki and across countless forum posts, but it occurred to me there may be value in having a more organized approach to managing Python code that's reusable across workbenches. My first thought was a "developers workbench", but as I pondered it more, it occurred to me that a better idea would be to repurpose the addon manager.

Specifically, a new Addon Manager feature dubbed the "Developers Toolkit" could be added next to the Addon Manager in the Tools menu. It would otherwise be unchanged in it's function.

I think this might also require a generic Developers WB as a way to provide an interface for test commands that come in handy with each library. Thus, a repo in the developer's toolkit would have commands that could be added to the init_gui.py file of the developers WB - which would require some careful automation to manage well, but it seems reasonable to me.

The primary advantage I see for this sort of tool would be to provide easy access to FreeCAD-specific Python snippets and libraries which are stable, functional, and useful, but maybe not suited for inclusion in to the FreeCAD core. I suppose we could think of it as our out-of-tree Python codebase.

Having a developers WB would also provide a central mechanism to communicate with new devs. We could easily provide notices, wiki links, etc, directly via the WB rather than forcing devs to hunt through the wiki or forums for that information.

It seems like a really valuable way to provide additional support for the growing base of FreeCAD workbench developers, anyway.

[triplus]

Would creating a new Addon manager really be needed? Wouldn't it be possible to just add such module, named "Developers Toolkit" to the list of existing offerings?

P.S. There i guess is one such module available already. And there is another competing/complementary module too.

[Joel_graff]

Would creating a new Addon manager really be needed? Wouldn't it be possible to just add such module, named "Developers Toolkit" to the list of existing offerings?

P.S. There i guess is one such module available already. And there is another competing/complementary module too.

From the vantage point of the Addon Manager, whether it's a developer tool or a user addon, they're all "addons", of course. The reason I've proposed a new menu item is for the sake of the users and developers. By doing so, we can separate addons by "type" (user vs developer) and display them in the manager accordingly. I'd hate to have to mix the two in the same list without some way to filter between them.

Whether we modify the existing Addon Manager feature or add a new one (a "Dev Toolkit" menu item under the "Tools" menu doesn't really matter. Nevertheless, I'd prefer adding a new menu item for two reasons:

1. Repurposing the addon manager means we'd have to modify the UI to filer "user" addons vs "developer" addons. A new menu item would permit that filtering to take place before the manager loads

2. The Addon Manager name isn't quite appropriate for devs, I think. The purpose here isn't to provide developers with "addons", per se, as it is to provide them access to templates and reusable code that can be incorporated into their existing project or installed as a "local" library of sorts for their project to use.

As for the Starter Workbench and TemplatePyMod, those were exactly the things I had thought of including as well.

Personally, I'd like to improve TemplatePyMod and make it a "Starter Task" or "Task Framework", since it sort of does for tasks what the starter WB does for workbenches.

[triplus]

If you feel strongly about having one menu entry named Developers, located somewhere in the FreeCAD global menu, hard to argue with that. Go for it and it can be empty for a while, as far as i am concerned!

P.S. And in the future therefore hopefully to provide useful developer oriented documentation/functionality.

[Joel_graff]

P.S. And in the future therefore hopefully to provide useful developer oriented documentation/functionality.

That's another reason why I think we kinda need this. Having a single developer's workbench / tool would make it easier to collect the documentation that's distributed on the wiki / forums. I guess I mean it's important not only to have a single place to go for documentation, but rather, one that *everyone* uses. A lot of new devs won't bother to go through the wiki. Or will just ignore the pinned post at the top of the Python scripting forum (which has a lot of great links in it).

So I'm imagining pointing a new dev to a developer's addon (for lack of a better term) that gives them a first place to look for documentation, setting up a new workbench, adding a new task / command / menuitem, etc. It would also make it much easier to provide standardized ways to manage workbench development, resource management, and so on - enforce best practices for Python WB development. Actually, that seems really critical to me for Python WB devs, since I expect the typical Python dev is going to be less experienced at coding than someone who comes here with a C++ background.

I really don't know, though. The idea's kinda half-baked. I hate to put time into it only to realize there's issues with the approach that make it useless or to find it doesn't really make anything easier. Definitely am going to let the idea stew here in a thread for a bit.

[yorik]

The addon manager's aim is not primarily to be friendly to developers, but to be friendly to users. That is, to make it easy for them to install addons without the hassle of going to github and unzipping stuff.

That said, I also think we could use it to be a kind of entry point for easy stuff for potential new workbench developers. However, it seems to me the number one feature that potential new workbench developers would need is better and more documentation and code examples. This doesn't need any tool.

The TemplatePyMod is indeed a great resource. Maybe we should work more on it, add more recent features, more examples, make it into something people can clone and start modifying...

[Joel_graff]

I think what I'm really trying to wrap my head around is, what does a complete Python workbench framework look like? What are best practices for developing the various parts?

As I've worked through it thus far, I've developed four key views on a good Python workbench design:

1. File structure - The Starter WB gives a great structure. I migrated trails to it and I'm really happy with it.
2. init_gui.py - Use for adding commands *only* (or things close to that). It's called 'init_gui' for a reason.
3. Command class - used to start a task (and handle conditions immediately preceding / following). Keep it bare-bones.
4. A "task" class - sets up the task UI and 'sandbox' (global state) for the task itself, delegating actual work to task-specific classes.

Standardizing the code base for the last three points is what I'm most interested in, I think. That, alone, does a lot to document how Python workbenches function.

Incidentally, I developed a structure for init_gui.py that I really like (which makes sense... I developed it ) But it really simplifies adding commands for me and makes it quick and easy to see what commands are added and where they appear in the UI. It still needs work, but an example of what I mean can be had here:

https://github.com/joelgraff/freecad.tr ... nit_gui.py

Anyway, I realize my view of this isn't necessarily everyone's, and that's perfectly fine. My key motivator here is to create an overall, general Python workbench development framework that is clear and doesn't leave new devs confused as to how things work together. With a clear, standardized approach to the parts (and greatly limiting customization at the higher levels of the WB code), it becomes much easier to create much-needed developer documentation.

EDIT: Which reminds me... it seems as though TemplatePyMod ought to be rolled into the Starter WB... maybe in a modified form?

[vocx]

... However, it seems to me the number one feature that potential new workbench developers would need is better and more documentation and code examples. This doesn't need any tool.

I agree. We need better documentation in general.

2. init_gui.py - Use for adding commands *only* (or things close to that). It's called 'init_gui' for a reason.
3. Command class - used to start a task (and handle conditions immediately preceding / following). Keep it bare-bones.
4. A "task" class - sets up the task UI and 'sandbox' (global state) for the task itself, delegating actual work to task-specific classes.

Standardizing the code base for the last three points is what I'm most interested in, I think. That, alone, does a lot to document how Python workbenches function.

Oh, I see what you mean. Yes, this totally makes sense. I think defining some sort of standard would be very beneficial. However, at the same time, FreeCAD thrives on freedom, people are free to implement their tools however they want. If somebody doesn't comply to that, how can we force them? I think such "standard" will only work if it presents a real advantage for organizing the code, then it would be accepted naturally by new programmers. Having a clear path to follow would speed development, as opposed to now that people frequently copy what somebody else has done without really knowing how things work.

Also, your init_gui.py is pretty good. I like that way of automatically loading the commands that are described in the dictionaries.

[Joel_graff]

Oh, I see what you mean. Yes, this totally makes sense. I think defining some sort of standard would be very beneficial. However, at the same time, FreeCAD thrives on freedom, people are free to implement their tools however they want. If somebody doesn't comply to that, how can we force them? I think such "standard" will only work if it presents a real advantage for organizing the code, then it would be accepted naturally by new programmers. Having a clear path to follow would speed development, as opposed to now that people frequently copy what somebody else has done without really knowing how things work.

I couldn't agree more

Also, your init_gui.py is pretty good. I like that way of automatically loading the commands that are described in the dictionaries.

.

Thanks!

[triplus]

EDIT: Which reminds me... it seems as though TemplatePyMod ought to be rolled into the Starter WB... maybe in a modified form?

Or maybe Starter WB in TemplatePyMod.

P.S. Keeping an eye on what Qt (6) devs understand under, "lets make Qt for Python API more pythonic". That could play a role in the future. When it comes to such discussions, regarding Python based FreeCAD modules.