Allowed the example window to be ran with a path argument

[Sasbom]

I thought it'd be neat to provide handling for a path argument, just like usdview.

[BigRoy]

I like it - however it does now start to hint that the user should run it like that and I wonder if then we're not shooting our own feet by exposing that in this rudimentary manner.

The example window is intended to be the simplest way of showing how one could e.g. implement a window within their own code base. I wonder if this PR would take away from that by introducing more code.

What do you think?

---

Instead, we might want to instead expose an actual Editor UI within the package (note how the example window is currently outside of usd_qtpy) and maybe allow running that via __main__.py so that one could just do:

python -m usd_qtpy

To run the example editor that combines the widgets into one window in a meaningful way?

[Sasbom]

Allowing the package to run by itself in the way you suggested seems like the way to go, I think, that's the way usdview does it too, opens blank by default, but when passing in a filepath, it opens it on startup.

As of now, there is no file loading capability exposed in the interface. We don't have a menu bar yet with some "file / help / view / window" options available, so, as a temporary measure, passing in an argument should make things a lot easier instead of relying on a hardcoded file path. That's solely my motivation for this commit, it doesn't change too much while still opening up some temporary flexibility for people toying around with the project.

Maybe this menu bar should be an optional thing, since I can see usecases where you'd want to use this as a component vs a standalone app. We could mark standalone vs integrated features with an enum or something similar, or make some keyword arguments afftect what components should be active versus what ones shouldn't be.

(also, i had to figure out how to make a PR hahaha)

[BigRoy]

that's the way usdview does it too, opens blank by default, but when passing in a filepath, it opens it on startup.

Note that usdview can't actually open blank - it requires a usd file to open :)

As of now, there is no file loading capability exposed in the interface. We don't have a menu bar yet with some "file / help / view / window" options available, so, as a temporary measure, passing in an argument should make things a lot easier instead of relying on a hardcoded file path. That's solely my motivation for this commit, it doesn't change too much while still opening up some temporary flexibility for people toying around with the project.

Thanks, good to know that's the first thing you wanted to play with - might be a good first thing to implement for the main window.

Maybe this menu bar should be an optional thing, since I can see usecases where you'd want to use this as a component vs a standalone app. We could mark standalone vs integrated features with an enum or something similar, or make some keyword arguments afftect what components should be active versus what ones shouldn't be.

Maybe let's first add it - and see where it can go from there. Menu bars can always be hidden in Qt as well and since the individual widgets are still available it would still allow anyone to roll their own using just those components.

(also, i had to figure out how to make a PR hahaha)

Thanks for taking the time to do so; already greatly appreciated.

Your branch is currently sas-dev. Usually it's good practice to name your branches to what you're implementing as a feature. For example: enhancement/launch_example_with_file or alike. Aside of that, good start!

[Sasbom]

Thanks for taking the time to do so; already greatly appreciated.

No problem!

Your branch is currently sas-dev. Usually it's good practice to name your branches to what you're implementing as a feature. > For example: enhancement/launch_example_with_file or alike. Aside of that, good start!

Will take note for the future!