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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
