Visualising context


#1

Originally posted on Gitter by @mkolar

Context information

The idea is that artist should be provided a visual way to see the context in which he is publishing. A simple bar where we could print a long string would be the most basic version. somwhere in the UI it says e.g. " ProjectX / Episode 113 / Sequence 5 / sh002 / Comp", or another studio might want to show “ProjectX / SH003 - due date 02/05/2016”. Or as you said just print out interesting data from context object.

This is a good idea, and I had a suggestion about how we could make this happen.

First and foremost is the matter of lack of convention.

We’ll need to find a general enough method of storing this information such that the GUI can access and visualise it. Some studios may not work in terms of shots/sequences, such a game studio, and vice versa, and yet some studios may not work in any formal context, such as small commercial shops.

How about this for an interface?

context.set_data("context", "ProjectX / Episode 113 / Sequence 5 / sh002 / Comp")

At that point, it’d be up to you for format this string, with whatever data you have available, including studio-bound Python modules.

To avoid confusion with this type of data (i.e. related to a users current environment a.ka. context) and the Context object, we would probably need to find a better name.

Any suggestions?


#2

How about “work_area”?

There is also the route of having a nice name for the context, similar to instances and plugins.


#3

work_area could work, or work_space?

Keeping with the data naming convention, that would be workArea and workSpace.

There is also the route of having a nice name for the context, similar to instances and plugins.

You mean something related to this?


#4

You mean something related to this?

Yes, then all you would need to do is to display this name.


#5

Ah, but I think the idea with this is to not have anything to do with the Context object, but more about displaying “the context” in which a user is working. The confusion starts with the name clash. :smile:

It’s about displaying shot/task etc. somewhere in the GUI, such as in the title of the application, and about where to get this data from. We can store it in the Context object, but we’ll need to refer to it as something other than context to avoid confusion, such as workArea.

Maybe this was what you meant?


#6

Maybe this was what you meant?

It was actually two different suggestions, either workSpace (like it more than workArea) or using the name of the context.


#7

Could do.

# E.g.
title = "Pyblish " + context.data("name") or context.data("workSpace")

#8

Although I suppose common names for the Context would be things like currentFile, scene or even workSpace, whereas the value for workSpace would be like the above ProjectX / Episode 113.


#9

Isn’t something like niceName or description a better name since it’s purpose is to be only descriptive or nicely readable information.

Also, for me workSpace conflicts with Maya’s terminology of the project’s definition so I might be a bit prejudiced to see it in the wrong light. :wink:


#10

Possibly, description seems intuitive.

# E.g.
context.set_data("description", "Project X / Asset Y")

The title could then use description if it exists, name otherwise, and simply Pyblish if neither exists.


#11

Now that we have the context in the UI, could we not make a selector that sets the label of the context?

context.set_data('label', 'Project X / Shot Y')

#12

We sure could, should be fairly straightforward at this point.

Tell you what, since there are quite a few things on the todo list, I think it’s a good time to try out a new tactic.

So how about we try this: either create or go to the issue or post that matters most to you, post in it, I’ll get pinged, and I’ll implement which ever issue is the most pressing first, given it’s not too giant of a task.

Otherwise I might be implementing something that matter very little to you, leaving the important things out.

Thoughts?


#13

Thought we used this forums to discuss before we create issues?


#14

You’re right, let’s post here for anything that isn’t an issue. The important thing is that you show me what you’re waiting for so I know what to implement next.


#15

And don’t be afraid to have a go at implementing something yourself.

It’s been dangerous in the past, because of the rapidly changing development, but the codebase is relatively stable by now and it would be a good time to dive in. The more outsite contributions it gets, the easier it will get for new contributors too, as inconsistencies will get smoked out. That’s how any good open source project builds up.

I’d be happy to hold your hand during your first contributions, just let me know and we’ll get started.

This issue is particularly low hanging fruit and a good place to start.


#16

I’ve gone ahead and marked issues with various levels of difficulty to solve, any of the easy ones is good to get started with, working your way up to more difficult issues as you gain experience with the codebase.


#17

Did we ever got around to implementing this?

We’re juggling a lot of file open at the same time now and it would help a lot if we could put some nice name of ‘context’ somewhere. Ideally of course in the pyblish windows title, but it has been mentioned and discussed, that it can’t be changed once it’s launches at this point.


#18

It can be modified before being shown. For example, you could replace the “Publish” menu item and prepend some parsing of sorts to get the title you are looking for, set the title, and then show the GUI.