Create New Project

[mottosso]

Goal

Ability to create a project from scratch.

Motivation

This is the only thing keeping Mindbender from using this as a replacement to the command-line interface.

$ cd my/project
$ python -m avalon.inventory --init

[aardschok]

Suggestion

As we now have Project Manager we could make it available to the Avalon Launcher and add the possibility to create a project in there as well.

Motivation

Removes the need for a host application to run the Project Manager. Centers the creation of project / silo / asset / task

Minimal requirements

• io module
• database address

[mottosso]

Yes please!

My only request would be to make it such that it doesn't interact with the database directly, but rather produces a dictionary suitable for use with the command-line version of this. It could be automatically passed to the corresponding Python function via the GUI, but would then also be suitable for producing a file, editing an existing file and not require database access itself. As a GUI, I'd rather it didn't touch anything but graphics.

For example, on hitting "Save" it could pass the resulting dictionary to the function responsible for communicating with the database. That way, it could also be used to save a dictionary to disk, and also edit a dictionary on disk, without access to the database.

My motivation is that it should be difficult to accidentally add something to the database, because anything that goes in is there to stay. Forever. By finishing an editing session - like you currently would with the .toml files - before submitting to the database, you are able to sketch, think and refine before you submit.

[aardschok]

If we want to be able to launch an application from the Launcher we will have to build a context. That is currently how it is build. This structure is in the way of of launching a tool like a Project Manager with only the io module and database address.

I will look at this issue a bit later how we might resolve this.

[tokejepsen]

Here are two mock-ups of how I could see the approach to creating projects.

One State

Everything is presented to the user. The user progresses from left to right, by starting with adding a project, then adding silos and assets, and lastly tasks.

Two States

User gets presented with a UI for adding and loading projects. Once a project is loaded, the existing UI is presented for adding silos/assets/tasks.

[BigRoy]

Thanks @tokejepsen

Projects on the left might be a bit too much clutter (unless you imagine constantly switching between projects, like every two minutes or so)

Let me push in an example of how we had the project manager in our old pipeline.

Could offer good inspiration. :) It has what we called a "Project bar" at the top to manage the project itself.

[tokejepsen]

Nice! Thanks for that @BigRoy.

I see that @mottosso is weighing up whether we should continue to improve this tool, or go full CGWire for project management. Discussion is on cgwire slack. So we'll bounce some ideas here and see where that discussion goes.

One thing we would need to have eventually as well, would be the project data like framerate, resolution etc. Could specify this on creation, but might also be nice to display somewhere in the UI.

[mottosso]

Having a chat with Roy about this now, and two things have changed since 9th June 2018.

• CGWire didn't pan out for me. I wouldn't discount it as an alternative or in adding support for it, but at the time the API wasn't there and the parts that were there didn't appear stable enough to force Avalon users into. That was a while ago now, and it's very likely things have improved, but it's not on my radar personally.
• Rez is looking good. I'm looking at replacing our current launcher along with introducing software version control into Avalon via Rez, which would have a minor effect on how data resides in the database and would affect this effort.

However, regardless of CGWire or Rez, creating projects will always be necessary and the requirements are unlikely to change, which are:

1. Give it a name
2. Give it some metadata

The rest is implementation. Whether the information ends up in Mongo, CGWire or Rez is something we can fiddle with where relevant, and shouldn't affect our efforts in making a good project manager GUI.

But both of those are hypothetical at the moment and doesn't need to influence the current direction, what matters is that the data is collected and stored. From there it's easy enough to convert this data into one form or another should we need to.

One improvement I see to the current manager is, like I mentioned earlier as well, to avoid having it directly interface with the database on clicking and typing in the GUI. Instead, edit data internally, and then "flush" this data per-request. Then flushing could perform additional validation if necessary (e.g. "Are you sure?"), and would let the user experiment and set things up before actually committing to something. The current method makes it a little to easy to accidentally create new items IMO.