Next release

[mnesarco]

Next release will incorporate a lot of things:

• New general event system, supporting observers and user defined events
• Workbenches API
• Command API
• Resources API
• Preferences + Preferences Page Gui
• fcui enhancements
• devtools
  • build
  • internationalization
  • pyproject.toml support
  • package.xml generation

Starter kit with templates

The new Svg Workbench is 100% based on fcapi so it is itself a demo of the fcapi usage, but it does not use all the available functionality.

[galou]

Is there any documentation of the new API?

I tried the devel branch but hit an obstacle with on_attach. In my ObserverProxy I used to use self.ViewObject.Position because self.position was not yet initialized.
Now, I can neither use self.position nor self.ViewObject.Position:
self.ViewObject.Position:

self.ViewObject.Position,
<class 'AttributeError'>: 'Gui.ViewProviderDocumentObject' object has no attribute 'Position'

and self.position is None.

[mnesarco]

Hello @galou , You should use on_start instead of on_attach, on_start ensures everything is already initialized.

About the new release, I have been working on a lot of new apis, you can take a look in SvgWorkbench it is my test bed for the new version. I will integrate some changes this weekend and i hope i can create a video introduction.

I am interested in recording a video podcast to talk about the SvgWorkbench and fcapi, i think that format is less boring than a plain video. Are you interested?

[galou]

Thanks! Using on_start instead of on_attach was not working because I need to initialize a member early otherwise, it's missing in an observer. I solved it by leaving the on_attach where I initialize all required members and use a default or dummy value for self.position and adding a on_start with a call to the observer callback inside otherwise, the view object would not be updated on document load.

It's up to you for the documentation. I personally prefer text because I don't mind boring documentation as long as I can get the information quickly (i.e. I prefer searchable content than videos).

By the way, I'd suggest the following patch

diff --git a/fpo.py b/fpo.py
index 0598789..5678ea3 100644
--- a/fpo.py
+++ b/fpo.py
@@ -1030,7 +1030,7 @@ class TypeMeta:
             for dm in self.display_modes.values():
                 dm_obj = None
                 if builder := dm._builder_func:  # noqa: SLF001
-                    dm_obj = builder(proxy, obj)
+                    dm_obj = builder(proxy)
                 if not dm_obj:
                     dm_obj = coin.SoGroup()
                 obj.addDisplayMode(dm_obj, dm.name)

Is it in line with the rest of fpo?

[galou]

I switched to the event-based fpo and like it (apart from the builder function still taking obj as argument, cf. above). Good work! Thanks a lot for it!

[mnesarco]

@galou Thank you for reporting. I will review the display mode builders API, that is not strictly an event handler but a build callback so I don´t know if I want to pass an event argument. The main reason to pass DocumentObject and ViewProviderDocumentObject instances to handlers via event or directly is to support externally defined handlers/callbacks that do not belong to the proxy class itself, it allows using composition over inheritance where it makes more sense, although it is not the average use case.

[mnesarco]

I plan to extract the Preferences API from fpo.py into its own preferences.py module. It is a fairly independent api, it was initially included in fpo.py because in the beginning there were only fpo, but fcapi is growing to more apis and a good separation of concerns is better.

[galou]

Passing obj to builder is not a big issue. At first, I though I'd modify fpo but decided that it's not worth it. Your arguments are probably stronger.