New Feature - Addon Manager for developers

[looo]

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.

[Joel_graff]

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.

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.

[vocx]

...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.

[Joel_graff]

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.

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.

[vocx]

...

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.

[triplus]

@looo is rather bad at documenting, therefore @Joel_graff, as you are good at that, just go ahead and create a PR against FreeCAD/Workbench-Starterkit, when you finish your work in the fork and update the FreeCAD Wiki after. "Developers section", containing the whole scope about creating a FreeCAD module. I would still recommend to include a short and simple tutorial like:

https://docs.djangoproject.com/en/2.2/intro/tutorial01/

Familiarizing new developers with the procedure and the structure of a FreeCAD module, creating a first command and usage of Tasks panel. Emphasizing the importance of separation of GUI and underlying functionality. That makes sense too. Basically much of that is mentioned here:

The separation of your workbench between an App part (that can run in console mode, without any GUI element), and a Gui part, which will only be loaded when FreeCAD runs with its full GUI environment.

https://www.freecadweb.org/wiki/Workbench_creation

If Python 2 would need any additional effort, don't do that. Python 2 has reached EOL. Developers creating new modules, or porting exiting ones, should not care about Python 2 anymore, not supported.

@vocx is one of the developers modernizing Draft workbench structure, therefore as such ideal source of opinion sharing. I feel that currently much more emphasize is put on Python side of things, C++ still needs to be taken into consideration.

P.S. In addition one of you could create something like FEP 1 -- FreeCAD module structure

https://github.com/FreeCAD/FreeCAD-Enha ... -Proposals

I would still recommend for discussion to be conducted on the forum.