Merge Context Manager + Workfiles tool into single UI.

[BigRoy]

Issue

Currently the context (current asset + task) is managed with the Context Manager and the Work Files can be saved/opened through the Work Files app.

I'd argue that when combining these tools into a single unified interface that it would become much faster to switch tasks and load the right work file.

Here's a quick mockup of what I envision it would look like when merged:

---

Feel free to start a discussion about pros/cons and potential other redesigns.

[mkolar]

this would certainly make it quicker, but we should make sure it still allows to do both individually. So in your mockup I'm only missing a button, that sets the context but does nothing else. We quite often change context, do some small tweaks to the file from previous shots and save as new.

Other than that I think it great idea

[mottosso]

Having a look at this tomorrow.

[BigRoy]

this would certainly make it quicker, but we should make sure it still allows to do both individually. So in your mockup I'm only missing a button, that sets the context but does nothing else. We quite often change context, do some small tweaks to the file from previous shots and save as new.

@mkolar would you be able to explain more about that specific Use Case? As I understand you are just switching context but not actually opening or saving scenes. I'm not sure I quite understand why you are only switching briefly.

I might be available to look into merging these tools tomorrow.

[BigRoy]

I'm struggling with the UX and figuring out how to have the interface behave most logically to the end-user. Especially as potentially you could be browsing into another asset+task and to list/save the files there you'd need to have set the current api.Session to those assets and task. As such, just browsing left-hand side invalidates the right-hand side.

Implemented

• I have currently implemented the actual context switch (setting asset + task) on double clicking on the task. That's when the files right hand side update.

To-do

• I'm thinking of "disabling" the right-hand side whenever the left-hand side browses to a different context than the currently set context. This is not in the current preview.
• The breadcrumbs at the top highlight the currently active context, not the one that you are browsing to. What I'd like to allow is when you've browsed elsewhere is to be able to click the Breadcrumbs to reset the asset+task views back to the currently active context that the breadcrumbs display. Plus, I'd like to have them display green or red dependening on whether the breadcrumb is the currently active one or not, so it's extra clear that where you are browsing now still needs to be activated by double clicking.
• The breadcrumbs would become much prettier once projects + assets + tasks get their own icons. I'll now start adding in their font-awesome icon equivalents for the time being.

Here's a quick preview:

Note that most of the tasks don't show files in this preview as it didn't have any files saved there.

Any remarks/thoughts @mkolar @davidlatwe? I think there's still lots of room to improve.

---

For completeness, I'm working in this BigRoy/core/fix412 branch.

[davidlatwe]

Especially as potentially you could be browsing into another asset+task and to list/save the files there you'd need to have set the current api.Session to those assets and task. As such, just browsing left-hand side invalidates the right-hand side.

Hmm, sorry, I could not understand, how left-hand side invalidates right-hand side ? You mean when the user changed the asset or task, the workfile list became outdated ?

[BigRoy]

You mean when the user changed the asset or task, the workfile list became outdated ?

Well, say:

1. Your current session (api.Session) is active on asset hero with task model
2. You click on left hand side to asset snake

What you're seeing in the UI now is not your currently active session, as you haven't switched yet to update the current task to that asset plus a potential task of it. As such, it would be confusing if files listed on the right still belong to the original session. Your session is still on hero > model until it's explicitly switched. No files in the work root can be accurately displayed on the right-hand side until the session is set.

So I would clear it + deactivate it and only activate it whenever the current api.Session matches what is selected as asset+task in the Work Files UI on the left. To update the current asset+task in api.Session one has to double click on a task in the task list (in my current prototype).

Does that make more sense?

[iLLiCiTiT]

I would switch also workfiles list on Asset change (with selection change in Task widget). In this order:

• select last selected task if exist for selected asset and is in task list
• select current session task if is set and exist in task list
• select first task in list if list contain at least one task

[davidlatwe]

Ah, thanks for elaborating :P

I not sure about the double clicking, a bit implicit I think.

Could we make the GUI to work on a copy of api.Session ? So the change may instantly reflect only to workfile list, or on file saving. And current api.Session (the global one) gets updated only when the user press Accept Context or Open File button.

[iLLiCiTiT]

Could we make the GUI to work on a copy of api.Session

We made this in our fork with creating copy of io and converting to class so it is possible to make object of "io" but with own Session but since this should be dialog (does not allow change to another widget of app) it is not necessary. Just store Session on open and override on close if Open or Save as was not clicked.

I would maybe change layout of buttons (sorry for quality):

[mottosso]

We made this in our fork with creating copy of io and converting to class so it is possible to make object of "io" but with own Session but since this should be dialog

Off-topic, but that's a good idea. I've wanted to get around to doing that; the Session class (now removed) was meant to accomplish that (less global state). Would be good with an issue/PR about that, with some examples of how yours works at the moment.

[iLLiCiTiT]

Would be good with an issue/PR about that, with some examples of how yours works at the moment.

We do not use that globally. We've created that because of Library loader which is almost same tool as loader but can load from different projects. The biggest difference is that has Projects combobox and do not use singleton io but that "io object" which is passed with args to all needed gui parts (tool has own assets, subsets and version widget with all models and delegates that use db data).

[BigRoy]

Could we make the GUI to work on a copy of api.Session ? So the change may instantly reflect only to workfile list, or on file saving. And current api.Session (the global one) gets updated only when the user press Accept Context or Open File button

Currently no. Until the change that @iLLiCiTiT mentioned they made to io is implemented. Are we able to get that feature in @iLLiCiTiT?

I would maybe change layout of buttons (sorry for quality):

@iLLiCiTiT unfortunately that makes a bit less sense to have Cancel/Accept there. The Work Files tool is also used to solely open a file but you can also save with it. Additionally as @mkolar pointed out it could still also be good to solely allow switching context (temporarily) - not sure about that use case, but that's what he stated. Anyway, as such at that position it's unclear what you'd be accepting or cancelling. It should be clear that you're opening or saving. Does that make sense or am I misinterpreting your design?

We do not use that globally. We've created that because of Library loader which is almost same tool as loader but can load from different projects. The biggest difference is that has Projects combobox and do not use singleton io but that "io object" which is passed with args to all needed gui parts (tool has own assets, subsets and version widget with all models and delegates that use db data).

Actually, I've had some other "use cases" that I can't recall now out of the top of my head where allowing a temporary session to be passed to things to be helpful. However, in this case it means we should somehow be able to even pass on that temporary session to the Work Files API. I definitely wonder how we can implement this and KISS (Keep it simple Stupid) at the same time. Would love to see an Issue/PR.

I would switch also workfiles list on Asset change (with selection change in Task widget).

The problem is that you would be very quickly initializing tons of environments that one might not have worked on, as you'd be triggering the taskChanged callback on every switch. Unless we could start working with a temporary local Session in the UI that does not need to trigger the global api.Session to switch to just until a scene is about to be opened or saved or whenever someone wants to explicitly switch (however for the latter, as stated, I'm not sure what @mkolar's use case was for that.)

[iLLiCiTiT]

Are we able to get that feature in @iLLiCiTiT?

Like I said it's actually io module converted to class. The disadvantage is that created object must be sent across all gui parts that use (at this moment) io -> you must get that object into AssetModel, few lib methods and many more. Inspiration can be found in our avalon-core fork ~/avalon/tools/libraryloader/. Class can be found in ~/avalon/tools/libraryloader/io_nonsingleton.py.

But I think you really do not need that. Like I said it is dialog so user can't do anything in app until you close the Context manager -> changes in Session won't affect any other pipeline tools if you just store copy of Session on open and override Session with the stored on close if "confirm" ("Open") was not clicked. Or am I wrong? UPDATED: You can actually store only AVALON_ASSET and AVALON_TASK on open in this case.

Does that make sense or am I misinterpreting your design?

Layout I've sent is just an idea. I just do not like that "confirm" ("Open") button is not at the bottom but in middle of buttons :) . Similar is that there is missing button to close window of course except [ x ] (cancel/close button is just my opinion/idea can be scratched).

The problem is that you would be very quickly initializing tons of environments that one might not have worked on

I see what's the issue then I would clear workfiles and deselect selected task (it's strange that task stays selected but nothing is shown in workfiles) on asset change.

Additionally as @mkolar pointed out it could still also be good to solely allow switching context (temporarily)

I forgot about this part. Then workfiles list may be deselectable and if nothing is selected in workfiles widget on "confim" ("Open") button then context will be changed but opened file won't change? (fast thinking)

[mkolar]

Sorry for my delayed reaction, I was busy on other things.

Our use case for only switching context is as follows.

1. artist finishes layout for sh010, saves, publishes... done
2. he wants to start working on sh030 that uses uses exactly the same setup and only need small camera tweak.
3. While his sh010 scene is still opened he, switches context to sh030, makes a few changes. 4 he opens workfiles, and saves the scene as new one under his current sh030 context.

I suppose he could resave the scene into the new context right away after browsing to it, however I'm worried that it's not clear enough that pressing save as does so under currently selected context on the left hand side.

[mkolar]

In regards to mechanism, I agree that double clicking is too obscured for people to figure it out by themselves. Indeed once you know how to work the tool, it is fast, so I'd actually keep it, but a dedicated button that switches the context is also needed to make it clear, that you first have to switch, to refresh the right side and then you can work with the files.

I'd say there is plent of space underneath the tasks (we rarely need to list 20-30 of them to need that space) and it might fit the quite nicelly.