New Feature - Addon Manager for developers

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
looo
Posts: 2898
Joined: Mon Nov 11, 2013 5:29 pm

Re: New Feature - Addon Manager for developers

Postby looo » Wed Nov 06, 2019 9:34 pm

Joel_graff wrote:
Tue Nov 05, 2019 7:31 pm
Thus, the `__init__.py` file needs to be removed from the `freecad` directory in the FreeCAD/Starter-Workbench repo, does it not?
After trying this again it seems like we MUST remove the /freecad/__init__.py files of 3rd-party workbenches. Otherwise, the Ext/freecad/__init__.py file is hidden by 3rd-party modules and "from freecad import app" won't work.
please help with my conda-packaging efforts: https://liberapay.com/looooo/
User avatar
Joel_graff
Posts: 1537
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

Re: New Feature - Addon Manager for developers

Postby Joel_graff » Thu Nov 07, 2019 1:09 pm

vocx wrote:
Wed Nov 06, 2019 9:26 pm
So, I think we have the same idea.
Yup. ;) I've entirely ignored non-gui commands - but it should be addressed. The issue I have isn't what init.py and init_gui.py do. Rather, it's how to demonstrate the purpose of the files to new developers who only care about a GUI-driven WB (and will probably simply ignore using init.py, just like I have).

A clear, simple, short set of rules ('always do this', 'never do that') is more useful to new devs who don't know anything than a list of suggestions or examples of alternate implementations. Thus, if we can say, "Always use init.py for ..." or "Never use init_gui.py for ..." it becomes much easier to get new devs writing consistent code and ensure init.py gets regular exercise. ;)

vocx wrote:
Wed Nov 06, 2019 9:26 pm
Now, a characteristic in Draft is that there are several Commands that behave the same. They are divided essentially in Creators (rectangle, polygon, etc.) and Modifiers (move, copy, array, etc.). So, the commands are based on parent classes which define a couple of properties common to all of them.

The Task code is similar. In your case you use a base_task to set up some things, and then the example_task will provide the actual code for this particular command. I have the same idea.
Insofar as any given CAD workflow is concerned, I don't think it's particularly useful to preserve the Creator / Modifier distinction in what a tool does, but it's an existing paradigm in Draft and certainly needs to be preserved, of course.

Anyway, I had personally tried to preserve / incorporate that hierarchy when I started writing pivy_trackers and thought about it for my starter kit Task class, but the Modifier / Creator / DraftTool classes are too specific to Draft and I couldn't think of a good reason to preserve the structure, if in name only.
FreeCAD Trails workbench for transportation engineering: https://www.github.com/joelgraff/freecad.trails

pivy_trackers 2D coin3D library: https://www.github.com/joelgraff/pivy_trackers
vocx
Posts: 1590
Joined: Thu Oct 18, 2018 9:18 pm

Re: New Feature - Addon Manager for developers

Postby vocx » Thu Nov 07, 2019 11:20 pm

Joel_graff wrote:
Thu Nov 07, 2019 1:09 pm
...Rather, it's how to demonstrate the purpose of the files to new developers who only care about a GUI-driven WB (and will probably simply ignore using init.py, just like I have).
I think we shouldn't ignore this. We should strongly guide developers in creating the GUI-less functions first, and then the graphical commands. This will make it easier for other people to hack around the workbenches and improve things.
A clear, simple, short set of rules ('always do this', 'never do that') is more useful to new devs who don't know anything than a list of suggestions or examples of alternate implementations. Thus, if we can say, "Always use init.py for ..." or "Never use init_gui.py for ..." it becomes much easier to get new devs writing consistent code and ensure init.py gets regular exercise. ;)
I agree. I think this can be done with help from the src/Mod/TemplatePyMod workbench that is in the source tree. It has quite a few examples, although they would need to be checked, because that code seems to have been written a long time ago, and it could use some changes in style and content. It seems the last changes were done so that it ran with Python 3 but that's about it.
Insofar as any given CAD workflow is concerned, I don't think it's particularly useful to preserve the Creator / Modifier distinction in what a tool does, but it's an existing paradigm in Draft and certainly needs to be preserved, of course.
...
Yes, I'm not saying you should use these classes in general, just that there seems to be a need for a base class from which to derive many commands. Just like you have a "base task", it also makes sense to have a "base command" in order to maintain consistency among tools. This is what I'm doing in my branches, I want to define Draft PolarArray and Draft CircularArray tools, and they will be derived from a generic GuiCommandBase, which essentially replaces the Creator and Modifier classes.

Code: Select all

DraftTool -> Creator -> Polygon
         |
          -> Modifier -> Move

GuiCommandBase -> PolarArray
              |
               -> CircularArray
I'm looking into having GuiCommandBase behave like DraftTool. Currently, it's basically a stripped version of it just to test my code. But in time it could be essentially the same.
User avatar
Joel_graff
Posts: 1537
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

Re: New Feature - Addon Manager for developers

Postby Joel_graff » Fri Nov 08, 2019 12:00 am

vocx wrote:
Thu Nov 07, 2019 11:20 pm
I agree. I think this can be done with help from the src/Mod/TemplatePyMod workbench that is in the source tree. It has quite a few examples, although they would need to be checked, because that code seems to have been written a long time ago, and it could use some changes in style and content. It seems the last changes were done so that it ran with Python 3 but that's about it.
I've ignored it, admittedly... Partly because the examples I looked at directly manipulated the coin scenegraph or was otehrwise overly complex. Still, I do want to incorporate it somehow.
vocx wrote:
Thu Nov 07, 2019 11:20 pm
Just like you have a "base task", it also makes sense to have a "base command" in order to maintain consistency among tools. This is what I'm doing in my branches, I want to define Draft PolarArray and Draft CircularArray tools, and they will be derived from a generic GuiCommandBase, which essentially replaces the Creator and Modifier classes.
I was going to suggest this previously, but didn't bother. Maybe you could just preserve the Modifier / Creator / DraftTool heirarchy and still implement your won base class as follows:

Code: Select all

class DraftBase(Modifier, Creator):

    def __init__(self, is_modifier):
        
        if is_modifier:
            Modifier.__init__(self)
        else:
            Creator.__init__(self)
            
        #initialization code here...
        
class MyCreatorTool(DraftBase):

    def __init__(self):
    
        super().__init__(False)
        
        ...

That said, I don't know if there's any real value to preserving the classes in new tools, but it would allow you to add extra abstraction to existing tools.
FreeCAD Trails workbench for transportation engineering: https://www.github.com/joelgraff/freecad.trails

pivy_trackers 2D coin3D library: https://www.github.com/joelgraff/pivy_trackers
vocx
Posts: 1590
Joined: Thu Oct 18, 2018 9:18 pm

Re: New Feature - Addon Manager for developers

Postby vocx » Fri Nov 08, 2019 4:46 pm

Joel_graff wrote:
Fri Nov 08, 2019 12:00 am
...

That said, I don't know if there's any real value to preserving the classes in new tools, but it would allow you to add extra abstraction to existing tools.
That's what I thought as well. These classes don't really do much. Most of it is done by the underlying DraftTool class, so Creator and Modifier are probably not needed.

As I mentioned in Discussion: renaming the graphical commands, I think the graphical commands are not meant to be scripted (they are meant to be buttons), so their implementation can essentially be refactored without breaking past versions.