Skip to content
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

Well defined public interface for tk_framework_adobe module #10

Open
manneohrstrom opened this issue Mar 17, 2019 · 1 comment
Open
Milestone

Comments

@manneohrstrom
Copy link
Contributor

manneohrstrom commented Mar 17, 2019

Using the adobe fw results in non-standard imports:

image

Note now our other frameworks are imported like this:

shotgun_settings = sgtk.platform.import_framework("tk-framework-shotgunutils", "settings")

Whereas the adobe fw is imported like this:

adobe_bridge = sgtk.platform.import_framework(
    "tk-framework-adobe",
    "tk_framework_adobe.adobe_bridge"
)

    win_32_api = sgtk.platform.import_framework(
        "tk-framework-adobe",
        "tk_framework_adobe_utils.win_32_api"
    )

We need to get parity with other frameworks and define a strict interface for the adobe framework modules inside __init__.py - for alignment with other patterns in tk, but more importantly to ensure there is a clear public interface which will allow for refactoring in the future.

Framework interfaces should only expose the minimum public interface that we commit to officially support.

Documentation

Note how the docs for the shotgun utils are generated to look like this:

image

Currently, the docs for the adobe fw look like this:

image

As part of this work, we want them to align in structure with how the shotgun utils ones above look, e.g it should just say adobe_bridge.AdobeBridge.

@manneohrstrom manneohrstrom added this to the v0.2 milestone Mar 17, 2019
@manneohrstrom
Copy link
Contributor Author

We should also make sure to review this file:

https://github.com/shotgunsoftware/tk-framework-adobe/blob/master/python/__init__.py#L6

  • why do have have a try/catch?
  • we should separate out the win32 stuff into a separate module so we can properly wrap it..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant