Today I ticked a few boxes and implemented another critical feature - tools.
One of the criteria for LA2 was for a single application, like Maya, to provide multiple access points, like whether to call maya or mayapy.
This feature leverages Rez's "Tools" feature, and as such the way you define what tools are made available is like this.
name = "maya"
tools = [
"mayapy",
"maya",
]Whereby maya and mayapy are executables within the maya context. In this case, both maya and mayapy exists on PATH as maya.bat and mayapy.bat, with .sh for Linux.
A minor cosmetic feature to strengthen the model/view architecture and ability to save/restore data from disk.
As I implemented tools for the various apps, such that a single application could provide multiple ways of being run such as maya and mayapy for the Autodesk Maya app, it struck me that some applications require their own terminal, whilst others do not. Notepad is a good example of one that doesn't need a terminal. And Maya has its own terminal. But mayapy on the other hand does need a terminal. Without detached, mayapy would end up running in the same process as launchapp2 which can get a little confusing.
An alternative to this is making your executables responsible for making this distinction, which after thinking about this is likely the better approach. Each executable will either require or not require this, and isn't likely to change over time. It doesn't need to be up to the end-user, and doesn't have to be.
On Windows, this means launching e.g. maya like this.
maya.bat
call "c:\program files\autodesk\maya2018\bin\maya.exe"And cmd which requires a terminal of its own like this.
cmd.bat
start "" cmdFixed a few bugs too.
- Fixed PySide(1) related bug for right-clicking in Packages tab, had to do with arguments differing between Qt 4 and 5.
- Fixed launching an app after having overridden an unrelated package, e.g. Notepad when overriding Python for the Maya app.
Got a few notes from testing out the GUI and Rez workflow overall.
- Help Link Small menu with a help link to Confluence and the launchapp version stored there.
- Sorting Ability to sort packages alphabetically
- Note you are also able to type letters on your keyboard to quickly find a match
- Local versus non-Local Visual differentiation between what packages are in your personal build area and those that are on the server. Like
rez contextdoes. - Project List Autofocus When no particular widget has focus, typing always means typing the name of your project, for quick access. This doesn't apply when focused in the Package tab though, as mentioned above.
- Visualise Rez Command The Commands tab illustrates what commands are running and their corresponding command. Make this more apparent, and enable copying of this command to replicate an environment in a terminal.
- Launch Command-line from any app Right-click on e.g. Maya and launch a console with that environment.
- Store current app with project Currently, the last-used application is automatically selected on startup of LA2. Store this default per-project, rather than globally.
- Hidden Apps Enable a secondary set of applications only that are hidden per default, and may be shown on-demand. Mostly for developers.
Currently, LA2 requires a path to where projects reside. It then takes the name of each project and matches it against available project Rez Packages. This works, but I thought of something more flexible and intuitive. To have a dedicated directory of Rez project packages.
Before
\\server\projects
\\server\packages\td
\\server\packages\int
\\server\packages\extAfter
\\server\packages\projects
\\server\packages\td
\\server\packages\int
\\server\packages\extThis way, not only is it made more clear what packages it's actually referring to, it also enables control over which projects are actually exposed in the GUI. Currently, every project - package available or not - is present; the ones without a package simply refuse to solve.
Address the above feedback.