uselessvevo / pie-audio Goto Github PK

To simplify usage paths in config.py they must be Path typed. For example, we have this line:

System.user_root / System.config.USER_CONFIG_FOLDER / "assets.json"

We can simplify it:

# system/config.py
USER_CONFIG_FOLDER: Path = USER_FOLDER / "configs"

# example.py
System.config.USER_CONFIG_FOLDER / "assets.json"

For example, we have a plugin and we want to extend application/system configuration.

Add _load_config method in ObjectManager.

First, this manager loads configs from user directory. That means we need an another manager to manage configs from other directories, which is stupid.

Just refacor this manager into ConfigsManager that will accept path as mount's method argument

Link to the manager: UserConfigsManager

Here is the problem: we're mounting plugin via Plugin Manager but this manager call init method which is mounting managers and rendering plugin at the same time which is bad.

https://github.com/uselessvevo/cloudyff/blob/main/src/cloudykit/plugins/base.py#L80

It means, that we need to remove render logic from the mount method and use init method to do that instead.

For example:

    def get(
        self, 
        *sections: typing.Union[str, SharedSection],
        key: typing.Any = None, 
        default: typing.Any = None
    ) -> typing.Any:
        ...

Add section(-s) class attribute in the objects (f.e. BasePlugin) to get access.

Add configuration in pieapp/config.py for ContentTable. For example, to set column count or headers labels

We can add the plugins/containers configuration files in user root to store user specific configurations.

Why? For example, I want to extend some built-in structure without overriding it.

# piekit/system/config.py

@etype
class Struct:
    SomeAttribute: EList = [1, 2, 3]


# pieapp/config.py

@etype
class Struct:
    SomeAttribute: EList = [4, 5, 6]
    AdditionalAttribute: str = "string value"

Here is a problem that we can reload only one plguin/component at the time.

Here:
https://github.com/uselessvevo/cloudyff/blob/january-refactoring/src/cloudykit/managers/plugins/manager.py#L50

And here:
https://github.com/uselessvevo/cloudyff/blob/january-refactoring/src/cloudykit/managers/components/manager.py#L39

This is just a propouse, but we can add new or spawn method that will create new manager instance with new given name. For example:

# This will create new class that will inherit from `ConfigManager` and read and listen user folder only
>>> System.registry.new(name="config", new_name="userconfig", path=os.path.expanduser("~"))
>>> System.registry.userconfig.get("config.json")
>>> {"key: "value"}

At this moment, there are two methdos to get needed plugin or container - via Managers or PluginAccessor mixin which makes me sad.

We can add get_plugin/getPlugin alias-method to make us happy and cut unnecessary code.

For example - the old method:

Managers(SysManagers.Plugins)(Plugins.About)  # <- sad

self.getPlugin(Plugins.About)  # <- less

getPlugin(Plugins.About)  # <- no more mixins

For example, we can load assets like in ConfigManager in mount method

https://github.com/uselessvevo/pie-audio/blob/main/src/piekit/plugins/base.py#L42

• Mount managers - mount method
• Prepare shortcuts, actions etc. - prepareShortcuts method
• Render on mainwindow components (if available) - placeOn method
• Render on activation (click, for example) - init method

First, this method load root localization files only

https://github.com/uselessvevo/cloudyff/blob/1b56a7e96d216c591a85a8130dc238129298ffd0/src/cloudykit/managers/locales/manager.py#L19

Second, add path argument to load files from other directories too. Use path as section key. You can do the same thing with ConfigsManager too.

Something like this:

class Plugins:
    Preferences = "preferences"
    Shortcuts = "shortcuts"
    ...

I mean, managers are just registries. Mixins will call createToolBar/ToolButon methods, managers will contain toolbars. And it means, we need to create custom PieToolBar and PieToolButton classes.

At this moment, there is no code or method which is register plugin. Also, plugins are not mentioned in ComponentsManager at all.

For example, we can use it to customize themes in run time, but not now.

We need to add it because now we have plugins only with no plugin/component separation

Add list of required managers in plugin's manifest.json file to check if manager is required for plugin.

https://github.com/uselessvevo/cloudyff/blob/23b32251a5278abc3802b0206bcfb2b818239c7e/src/cloudykit/components/base.py#L123

At this moment, managers like ConfigManager and LocalesManager accepts root and section arguments, but we want to load files from multiple directories with information about section.

For example, we can create interface/dataclass to achieve this:

@dt.dataclass
class PathConfig:
    root: Path
    section: str = "shared"

https://github.com/uselessvevo/cloudyff/blob/4e1e9c99ef5196f2518ef12c42ff4b685b4c7e00/src/cloudykit/managers/plugins/manager.py#L21

Same as this issue - #54

There is no real reason to keep this manager

We can add ApiAccessor/ApiExtension to provide API calls for plugins/containers.

For example, we can add api method for plugins/containers:

result = getPlugin(Containers.ContentTable).api("<method>", <args>, <kwargs>)

First, this name is much clear and easy to understand what this program do.
Second, under a different angle it signals that this project written in python

At this moment, we have a really bad way to populate/create files in user folder. Create template files for config, locales and etc..

To pretend configuration overriding we can add override <bool> parameter in EType class.

For example, spyder-ide has configuration page module which is good. We can implement something simillar.

At this moment, we just iterate via pathlib.Path, but we can use pkg_resources.iter_entry_points to get them all. But there is a thing, I think that we will not be able to read manifest file.

There is no reason to keep this manager in the project.
Will be removed in system-remove branch.

Add an option to pass arguments from config for managers. For example:

MANAGERS = [{..., "options": {"path": os.path.expanduser("~")} }]

If you're using methods unmount/reload manually you need to pass list of managers names, which is bad, because we don't know what dependencies order is.

It will be easy to store PathConfig in dictionary with the next signature: <section><file name>: <path>

Plugins observer must signal about available and non-available (disposed) plugins. This observer will be used in PluginsManager.

At this moment, you need to make a lot of things to just start a project with cloudykit/cloudyui. That means, we need to create CLI to startup/create project.

At this moment, it just shows static image and nothing more

#52

At this moment, all built-in managers are hardcoded in PluginsManager's mount method which is bad. We can add this logic in BasePlugin's mount method.

Separate handle_<etype> methods and ConfigLoader. Also, replace _HANDLERS_MAPPING.
URL: https://github.com/uselessvevo/pie-audio/blob/main/src/piekit/system/loader.py

At this moment, all access to the managers is really unclear.

For example:

# This will return an instance of `ConfigManager` which is unclear
System.registry.configs

# To make it clear, we can use enum with the system managers
# Yes, it's a little bit longer to type, but it will be MUCH clear
Managers.get(SystemManagers.Configs)

At this moment, a we have plugins and containers. Both of them are uses the same BasePlugin class which is bad, because a container doesn't use all plugin's methods.

We can make a PieObject and PluginMixin to extend it.

For example:

MANAGERS: EList = [
    ManagerConfig(import_string="...", mount=True, args=(...), kwargs={...}),
    ...
]