-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose tools to API #420
Comments
An alternative is making each tool package into an API in itself. from avalon.tools import loader
loader.show() At the cost of having that many more APIs to maintain. |
How about _registered_gui = {
"loader": avalon.tools.loader,
"creator": avalon.tools.creator,
...
}
def show(gui_name, on=None):
_registered_gui[gui_name].show(parent=on)
# And maybe one could even register his/her own gui for any purpose
# as long as the method `show` is presented.
def register_gui(gui_name, gui_module):
# Validate
assert hasattr(gui_module, "show"), "GUI module should have method 'show' be exposed."
assert callable(gui_module.show), "GUI method 'show' should be callable."
# Register
_registered_gui[gui_name] = gui_module Or maybe use |
That's another option, yeah. We don't really have that level of indirection anywhere else though, so it might not be expected, but it's worth considering. |
I lean towards one API and David's suggestion of But then we are also excluding any non-UI interaction with the tools and their libraries. For example just exposing the |
To achieve that, I think adding them to |
That is true, but I think we've already got a non-UI API, which is the current
So for a function like opening the latest workfile, that's better suited at level 3. Cut out the middleman.
That might be a good idea; like the
I thought more about this and realised it would cause ambiguity. from avalon import api
from avalon.tools import loader
class MyLoader(api.Loader):
... Or is it
I gave this some thought as well, and thought of two issues.
Granted, this isn't the most elegant or nice to look at solution, but I think it helps encourage a clear separation between what is meant for API access and what is meant for visual user interaction.
Preferably, the from avalon import api
loader = api.show_loader()
loader.close() Thoughts? |
Saw you mentioned this here some time ago @tokejepsen, good call. |
I managed to fix this, and re-implement backwards compatibility, so 418 should no longer cause any issues (if it does, it's a bug). |
Goal
Enable customisation of tools display from external configurations.
Motivation
There are references to internal modules from within colorbleed-config that makes sense, but shouldn't be calling on members outside of Avalon's API (as it is now broken, since #418)
Implementation
Avalon's tools are fixed and can be relied upon, but not their implementation details. What can be relied upon is..
tool.show()
..but that's pretty much it. So how about..
avalon.api.show_creator(parent=None)
avalon.api.show_loader(parent=None)
avalon.api.show_sceneinventory(parent=None)
avalon.api.show_publisher(parent=None)
avalon.api.show_contextmanager(parent=None)
avalon.api.show_workfiles(parent=None)
Anything else a config requires?
The text was updated successfully, but these errors were encountered: