feat: Backlog/generic publisher

[lluisCM]

Resolves :

• FT-c14183ab-35c5-4877-bafe-d837ab38ac4c

• I have added automatic tests where applicable.
• The PR contains a description of what has been changed.
• The description contains manual test instructions.
• The PR contains update to the release notes.
• The PR contains update to the documentation. (No, but it needs one before releasing, will be provided in another PR: https://dev.ftrackapp.com/#slideEntityId=e9587550-a7c5-4164-93d6-6dd3c01dbe6f&slideEntityType=task&view=tasks&itemId=projects&entityId=dc34b754-79e8-11e3-b4d0-040102b7e101&entityType=show&objectType=show&slideView=)

This PR has been tested on :

• Windows.
• MacOs.
• Linux.

Overview

Please see the following video presenting the Generic publisher to you and Benn ( https://backlightco.slack.com/archives/C05FELF84R2/p1720519945090819
)
Purpose: Core implementation of the generic publisher.
Scope:

• constants
• framework-core: client, host, event manager, registry, dialogBase
• utils
• qt: accordion widget, implementation of new widgets.
• qt-style
• common-extensions: new dialog and new tool-config

Implementation Details

Approach:

• Tool-config new tag recognised by the new generic dialog to interpret that taged component group as a duplicable component.
• By default a tool config can have as many pre-defined generic groups as they like; just as example, in the default one, we have one named generic and one named generic-static. This is for the reviewer of this PR to easily see the difference of the editable_component and removable options of the group.
  • button-label option is the default label provided for every time a new generic component group is created.
  • editable_component option: In the current implementation that means that when a new file is selected in the browser the component will automatically be renamed to the extension of that file, Also the user when double clicking in the name should be able to edit it if this option is set to true.
  • removable option: means that the group component can be removed.
• When there are multiple predefined generic groups in the tool config, the + button in the dialog will show a menu for the user to decide which generic group want s to add. If just one single predefined generic group, then the menu doesn't appear and the group is automatically added.
• When a generic dialog starts instead of just reading the tool config it duplicates the tool config(and creates new references) in order to modify it in memory, adding and removing components and options as desired by the user.
• In order to pass that information to the host and not alter the current tool-config and plugin options workflow between client and host, every time the duplicated tool config gets a modification, it syncs with the tool config between the client and the host using a new implemented event in the event manager named host_sync_tool_config.
• Once the user has been finished customizing the dialog, there is a button to save the current preset as a new tool config in the user defined location. (There is no implementation to automatically read that tool-config back yet, but will be a future implementation)

Reasoning:

• Duplicating and Syncing the entire duplicated tool-config between client and host is the only way I found to give freedom to the user without compromising or making to difficult the client/host tool-config sync workflow.
• Editable names automatic syncronization with the file extension was decided by the team.
• No yet implemented a functionality to read the user saved tool config because its something that we can focus on later, and user can still make this manually doing:
  • add the new tool config in the extensions folder
  • change the dcc config to tell the publisher to read the new one

Changes:
Trade-offs:
Current default tool config workflow:

• The tool-config lives in the host, that sends the tool-config to the host-conection when I client call the discover host event, and the host-connection, provides the tool-config to the client.
• The client never modifies the tool config, instead using the tool-config reference and the plugin reference, the client creates a dictionary with the options that has to be overriden in a specific tool-config/plugin, then when Client sends the event to the host to execute a specific tool config, client sends the tool-config reference alongside with the dictionary with the overrides of that tool-config reference(or plugin reference)

With the new implementation, the above workflow is still valid for typical tool configs, but for the generic ones it does the following:

• The tool-config lives in the host, that sends the tool-config to the host-conection when I client call the discover host event, and the host-connection, provides the tool-config to the client.
• The client duplicates the tool-confg with new references, and everytime it does a modification in memeory (adding a new enirely component group) that is synced from the client to the host.
• Then when runing the tool config, the same previous workflow is applied because the host also has the duplicated tool-config with the correct references. So this is applied: The client creates a dictionary with the options that has to be overriden in a specific tool-config/plugin, then when Client sends the event to the host to execute a specific tool config, client sends the tool-config reference alongside with the dictionary with the overrides of that tool-config reference(or plugin reference)

Testing

Tests Added:
Manual Testing: Just execute the standalone generic publisher on you local environment to try it.
This guide might be useful if you currently don't have a standalone setup done: https://developer.ftrack.com/pr/48/integrations/recipes/framework-standalone/

Also, not 100% sure if it works but using the tests/framework/manual/standalone_ui_test.py and setting the generic publisher should work for testing. (I'll add a task to make sure this works in the future)

Testing Environment:

Notes for Reviewers

Focus Areas:

• Generic tool-config tags and options.
• Duplicated tool-config sync between Client and Host.

Dependencies:
Known Issues:

[github-actions]

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
libs/constants/source/ftrack_constants/framework/event
__init__.py
libs/framework-core/source/ftrack_framework_core/registry
__init__.py					135, 162-164, 214-215, 220, 223-224, 229, 237-244
Project Total

This report was generated by python-coverage-comment-action