Ability to add a custom project root through the interface

[BrundleThwaite]

In order to add a custom project location you have to manually change either files (Mac) or modify the registry (Windows). I do not think that it is a good idea for people to be changing the registry.

I would probably be better to be able to do this directly through the interface, probably as a setting in preferences,

[Rayek]

Agreed, this would simplify life a lot in classroom situations, for example.

[ghost]

I agree. I am a teacher and have multiple classes and not every class should save to the same location. I added the ability to save to the desktop earlier as a workaround, but that only works for levels and scenes.

[blurymind]

Autodesk maya uses this approach where it can creaye a new project tree, or set current prpject root to a custom directory. Blender uses a single file to store everything- but internally its just the same thing- a project folder

[ghost]

664 takes care of most of this. (Not multiple locations at the same time, but customizable locations)

[BrundleThwaite]

I did a video in which I did explain how to make multiple project locations.

https://youtu.be/THY3C2jj-_M

Allowing people to set custom locations from the Interface is a good start though.

[ghost]

I added a second choice in the PR with checkboxes for each location. I think I prefer it better:

However, I still want to resolve having an individual sandbox for each user in a multi-user environment.

[BrundleThwaite]

If you do not want sandbox to not be the default consider the following.

a) The user is going to have to specify the default folder when the application is first launched. But every new install (Especially on windows) is going to require them to set any custom project locations manually.

b) The default is going to have to be set as is standard per application so for example in windows (mac and linux would be different) you would have data stored in. C:\Users\NAME\AppData\Roaming\Opentoonz 1.0 stuff and documents would be stored in C:\Users\NAME\Documents\Opentoonz 1.0

In both cases these are problems. but the biggest problem in changing the default locations is that a lot of users will have work saved in the Opentoonz 1.0 stuff/Sandbox and Opentoonz 1.0 stuff/Projects folders (Which is not currently included in your checkbox options) and if you cannot add any number of arbitrary projects through the interface you should not change them. It is unfair for a person to lose their work because they lack the technical expertise required to convert the projects to custom locations.

[ghost]

This actually gave me an idea. What if users have an "individual" sandbox that is by default in their documents or somewhere, and still keep the stuff folder sandbox and in the checkboxes call it a Shared Sandbox or something like that.

In both cases these are problems. but the biggest problem in changing the default locations is that a lot of users will have work saved in the Opentoonz 1.0 stuff/Sandbox and Opentoonz 1.0 stuff/Projects folders (Which is not currently included in your checkbox options) and if you cannot add any number of arbitrary projects through the interface you should not change them. It is unfair for a person to lose their work because they lack the technical expertise required to convert the projects to custom locations.

I totally agree- That was an oversight on my part. I will add the current sandbox to the checklist and set it to checked by default.

[shun-iwasawa]

@turtletooth The TOONZPROJECT folder is not actually the place where working data to be stored. It is for storing the project settings. And the current project is saved in .env file of each user. Based on the above condition, is it not enough for you that students create their own projects which stores their data in their local folder? For instance, user "Shun" creates a project "shun_prj" with settings like "+drawings=C:/users/Shun/Desktop/drawings" and user "Turtletooth" creates another project "turtletooth_prj" with "+drawings=C:/users/Turtletooth/Desktop/drawings" and so on.

[BrundleThwaite]

I'm fine with changing default locations but that does not really affect me because I use custom project locations in all my applications. The true questions here are "will it be compatible with older projects?" and "does it add unnecessary complexity?"

and remember that sandbox is the default project but the default place where the project definitions are saved is not sandbox it is /Opentoonz 1.0 stuff/Projects

My real intention in this the ability to specify custom locations for project definitions through the interface not to change the defaults.

For example to add a custom project root this type of interface would be more straightforward. It would also keep project information in the project interface instead of moving everything into the preferences.

[ghost]

I think my most recent modification addresses the concerns mentioned here: The sandbox and default project folder remain exactly the same as they have always been. My new version only allows you to add MORE locations to those two.

If more locations were added through regedit or other means, they will still be recognized.

The change I added for teachers and multi-user environments was to make Documents available by default. The sandbox is still the default project, however.

The new version should not affect any access to current user work- simply add more location options.

@shun-iwasawa I think that having students change all the folder locations for new projects (although it sounds easy) is not always easy for many students. I think this might be a good compromise of not affecting any current functionality, but making it easier for students to set up a project in their own documents folder. This also helps those who have wanted to add other project roots without regedit. This is much easier than setting the individual folder locations for each project. What are your thoughts?

[ghost]

@BrundleThwaite The reason for not including it in the new project settings, is that this change requires a restart,, which is not what you would expect if you could hit + in the new project window.

[konero]

Edit: Disregard.

[blurymind]

I am running out of space on C drive. So this feature is very much welcome

On 21 Jul 2016 23:13, "konero" notifications@github.com wrote:

This doesn't address the issue though, since folders not belonging to a certain user should be hidden, if you have ten or more Project Root directories it will just over populate the list and Browser. This should really be done in Windows Registry IMO. The way it's done here is confusing and doesn't allow batch.

This is how Clip Studio Paint works. It creates a CELSYS_EN folder like OpenToonz Stuff folder in Documents by default per Windows User Account.

So I would move...

OpenToonz Stuff\plugins ===> C:\Program Files\OpenToonz 1.0\plugins OpenToonz Stuff\fxs ===> C:\Program Files\OpenToonz 1.0\fxs OpenToonz Stuff\doc ===> C:\Program Files\OpenToonz 1.0\doc

Leave everything else, but move...

C:\OpenToonz Stuff ===> C:\Users\Shun\Documents\OpenToonz Stuff

Anytime a new Windows User Account starts OpenToonz, it should prompt to create a OpenToonz Stuff folder unique to that Windows User Account and store the location in Windows User Registry. Otherwise all users can access other users work which should be forbidden.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/opentoonz/opentoonz/issues/373#issuecomment-234400342, or mute the thread https://github.com/notifications/unsubscribe-auth/AGMbVWlbF01e9fxL48b88ge2ewmFiwPvks5qX-8CgaJpZM4IneCQ .

[ghost]

@konero There are conflicting issues here. I personally would love all project folders to be personal and not in the stuff folder but I'm sure there are environments - perhaps in a studio where they might need to share - where this may not be desired. There is also the issue of work that has already been created being inaccessible if the current way it works is lost. I realize that it is not too much work to move the project folders to a new location, but it is open to debate if the current sandbox and project root locations should be lost.

My solution leaves those two folders where they are and as the only two that will have shared items. The desktop and documents folders are individual to the user, and any items added via the custom section are also individual to that user. They won't show up in other users' workspaces.

I feel this is a compromise between allowing users to have private work, but still keeping the current setup so current users don't have to move a bunch of their work.

I think that moving personal related settings and rooms to a more personal location is a good idea, but it is beyond the scope of this PR.

I definitely always want to take feedback into consideration, so please let me know if there is something I am missing. Please know- the current solution as proposed will keep non sandbox and non default project root items restricted to the current user.

[shun-iwasawa]

@shun-iwasawa I think that having students change all the folder locations for new projects (although it sounds easy) is not always easy for many students. I think this might be a good compromise of not affecting any current functionality, but making it easier for students to set up a project in their own documents folder.

@turtletooth Your suggestion is partially understandable, it may be sometimes troublesome to set folder locations especially if user would like to put all of them under a certain folder. But IMO there can be more appropriate resolution for such issue. In your resolution, you make it easy to add a project root. It seems that users are intended to create a new project root for each project. Such usage is not following a original intent of Toonz's project management. I still do not understand why you would like to create such a many project root folders... Again, the project root is not for storing any working data such as drawing or scenes. The project root is for storing only the project settings which is just a single XML file for each project. You can create more than one project with different paths under one project root. I agree that making some PROJECT private is somewhat good for multi-users environment, but I can't find any advantage to make the PROJECT ROOT personal. So, my suggestion is as follows, instead of your modification:

• How about modifying the "New Project" popup so that user can easily set paths for each alias?
• How about adding a "private" option to the project, which can be set in the "New Project" popup? With this option, other users cannot see its contents from file browser.

This also helps those who have wanted to add other project roots without regedit.

This is more understandable. But again I think that the project root is not needed to be edited so often and should be shared among users. Maybe it can be stored somewhere in TOONZCONFIG.

[shun-iwasawa]

Here is an image showing what I would like to point. The project root is designed to gather all the links of projects' working folders in different paths under one folder tree in order to make it accessible.

[ghost]

the project root is not for storing any working data such as drawing or scenes. The project root is for storing only the project settings which is only a single XML file. You can create more than one project with different paths under one project root.

@shun-iwasawa I apologize for not being clear in my description of the problem and solution. I really hope we can find a mutual understanding here. I fully understand that the project root doesn't have to be the main location for project folders and it was never my intention for there to be a project root for each project. (Looking back, I can see how that was miscommunicated by my screenshots with numerous project roots.) Personally I would be content with things the way they are now with the addition of it being easy to set project data folders to the documents folder.

This solution was intended to help both teachers and those who needed an additional project root such as what @blurymind mentioned above. @BrundleThwaite's screenshot also shows a valid use of multiple project roots- as an organizational tool. Making an additional project root by default in the my documents folder seemed to be an easy way to create private projects without having to set each folder by hand... Again, I don't intend for anyone to make a new project root for each project- I fully understand that the root can hold multiple projects.

But again I think that the project root is not needed to be edited so often and should be shared among users.

A potential downside to keeping only one global project root of that even if the data folders are not in that folder, anyone can delete the XML file associated with someone else's project. This is hopefully not an issue at Studio Ghibli, but in a middle school where I teach, it's totally possible. Students don't always make the best or kindest choices, and safeguarding all project data that doesn't need to be shared is a good idea at least in the classroom setting. I realize that the target audience for OT is much broader than just teachers and I don't want to do anything that makes the workflow for anyone else more difficult.

You mentioned creating a setting in the new project window to automatically set the folder locations to a private location. If that is the only way to get a feature like this included, I don't mind building it. My hope here was to help not just teachers, but also those who, for various reasons, need the option to have a different project root in another location.

Here is a much more accurate idea of how I would use it in my class for example:

If there is anyway that this would be permitted by the OT team, it would help teachers a lot. I think that it might be good to move the options from the first page of the preferences to keep people from thinking that it is an essential part of the workflow.

[shun-iwasawa]

@turtletooth thank you very much for sharing your opinion in detail.

This solution was intended to help both teachers and those who needed an additional project root such as what @blurymind mentioned above. @BrundleThwaite's screenshot also shows a valid use of multiple project roots- as an organizational tool.

@blurymind and @BrundleThwaite I would like to ask both of you true intentions for creating multiple project roots.

A potential downside to keeping only one global project root of that even if the data folders are not in that folder, anyone can delete the XML file associated with someone else's project.

I think that OpenToonz can do nothing against malicious and intentional act such as deleting the setting files by hand. Even if you protect them by escaping them into my document folder, there are still many other personal settings in TOONZPROFILES. And the project settings is just a setting itself and I think it is not so precious as drawing data.

Looking into your plan, it seems that you would like to make private project for each student with a little effort, i.e. with less cumbersome operations like typing paths. Is it correct? I understand it is important to make the initial settings easily, but I'm afraid that this solution may scatter OpenToonz's setting files in many locations and makes it difficult for users to find them.

Here is my revised suggestion of implementing "private" project:

1. Adding a combo box in the "New Project" popup which can select your project to be public or private.
2. If you choose "Private" then the fields are filled with default values.
3. "Project Name" field is selected to prompt user's input and
4. Once you type project name, they are automatically inserted into the paths for every aliases, which are input location of my document by default.
5. If you create a private project, it can only be browsed by owner of such project in the file browser.

With this implementation, all students have to do additionally will be just selecting "Private" from the combo box.

I think making the TOONZPROJECT to be more accessible is an another issue.

Please let me know your thought. Thanks!

[ghost]

@shun-iwasawa This method will work fine. Can you think of a way to make private projects only visible to the user who created them? Without that, the project root in the browser view would get very cluttered.

BTW- I have considered that all the other preferences and settings can still be deleted by malicious actions, but in most cases OT will simple recreate the file and start from scratch. If the project file is deleted, you get this error when you try and open a scene:

Thank you for taking the time you have given to this whole discussion and taking the time to create the screen shots to explain your thoughts.

[blurymind]

@shun-iwasawa Here is my example:

I think @turtletooth is aware of it too. Basically when you are a student, you tend to use onsite university computers and also your own computer at home. As a result, your project needs to be opened on both computers. You would need to work on it from home, then bring it to lab sessions and be able to open it and show it to your teacher and your peers. Very often by the end of a module- you would use the university computers as a renderfarm.

So students especially - but also freelancers and even professionals tend to carry their projects on a usb thumb. They tend to make copies of it to different computers. They tend to NEED to be able to open the projects from anywhere. Even when on a PC - you would run out of space - especially if you have raster levels that use huge tiff files for frames.

It would then be advantageous to put some projects you have on another drive.

If you look at a good example of other software doing this - I would suggest looking into Autodesk maya. It allows the user to set the project folder path before creating a project. It also allows the user to open a project path before opening a scene in it. https://www.youtube.com/watch?v=DId2zNbLMUk

https://knowledge.autodesk.com/support/maya/learn-explore/caas/CloudHelp/cloudhelp/2016/ENU/Maya/files/GUID-D5CA162A-0956-49C6-9FAC-2F73DCF03409-htm.html

Maya stores it's settings (env) files in a separate folder - under the user's home folder. https://knowledge.autodesk.com/support/maya/learn-explore/caas/CloudHelp/cloudhelp/2016/ENU/Maya/files/GUID-8EFB1AC1-ED7D-4099-9EEE-624097872C04-htm.html

I think that is a very good approach - because it keeps your projects isolated from you application's settings and resources. It's just madness that OT has these two things locked to a folder atm.

If you would like more examples of this - please look into toonboom studio and toonboom harmony. They use the same approach as Maya almost

[shun-iwasawa]

@blurymind thank you for the detailed example. However, please read my previous comments carefully - OpenToonz already has functionality to realize your demanding scenario just like Maya does. You just need to type an absolute path to the usb thumb for each alias in the project settings instead of the default value. If you create a project with default value (like "drawings" for +drawings), OpenToonz will create such folder at relative position under the project root folder. I think this behavior may misleads many users to the wrong impression that the all resources must be saved in the project root.

[shun-iwasawa]

Furthermore, actually you do not need to put your resources under the project working folders (+drawings, +inputs, etc.) EXCEPT SCENE FILES. All resources except scene file can be loaded from anywhere in the file system with absolute path. For the scene files you have to save them under the project working folder ( to be precise, under the folder where the "scenes.xml" exists ). By doing this, OpenToonz can find a belonging project to the scene and can decode the alias (e.g. "+drawings") used in the path of the resources to the actual path by using the project settings.

[Rayek]

This thread is extremely elucidating: I was under the impression as well that the best practice is to save all your files/assets physically in the project folder. That is how it works in (web)development.

I now understand a project XML file is generated which keeps track of all the settings.

But this is going to be quite confusing to students, because the scene files MUST be saved in the project root where OT saves its stuff folder, and that is going to become a truly problematic situation in a class situation. Students would have to remember to backup/work with at least two separate locations. And the projects settings cannot be moved or defined on a USB drive, for example.

I work as an instructor at a technical university where each computer is completely reset and cleaned every single time a machine is rebooted. If the project root cannot be moved, and the scene files must reside in that project root which is located in the stuff folder, when the student machine is rebooted ALL the scene files will be gone. So it is quite a hassle to ensure that a student backs up his/her files now.

I think the portable version is the ideal solution for now: install on USB and work. Or copy to the desktop, and copy it back to the USB drive.

[konero]

@Rayek Is it not possible to setup a directory junction to the USB drive letter?

If the USB drive letter is D then you could do...

mklink /J "C:\OpenToonz 1.0 stuff\projects" "D:\"

Inform students to store their projects in separate folders. Insert USB drive...

example1
example2
example3
Funny Cat Pics

And your workstations should pick them up automatically without doing anything. At home, students just need to drag and drop the \projects\example1 folder to the USB drive. OpenToonz at the Uni WS will look for D:\example1. Won't work with absolute paths though.

[ghost]

There are some strong opinions about this on both sides. I am back to thinking that allowing additional project roots is necessary.
@shun-iwasawa

You just need to type an absolute path to the usb thumb for each alias in the project settings instead of the default value.

This doesn't take care of the project xml file that resides in the current project root. To move their work to a different computer, someone would have to make sure to not just have the folders that are defined in project settings, but also the project xml file. You can't open a scene unless it has a project file also.

The file locations in these also become hard coded if the default location is not selected. This makes it extremely problematic to move the project to another computer- you would have to make sure that all files are in the exact same location on both computers. If all files are in a project folder, it is simply a matter of copying that folder or zipping it up.

Furthermore, actually you do not need to put your resources under the project working folders (+drawings, +inputs, etc.) EXCEPT SCENE FILES.

Even though it is not required, I bet it is what most people will do and it makes file organization easier too. I would much rather have all project related info in the same location rather than multiple locations. I realize in a studio setting, it is probably different - with having to share assets with each other.

Additional project roots are not totally out of the original idea of the Toonz developers- how to add them is in the manual. It's not easy, but it's there (pg 18). The idea of selecting a different project root is no more complicated than the idea of a dropdown to choose private or shared, and I think choosing between private and shared might be confusing for some users.

It's one click.

I don't think adding the ability to do this hurts anyone. It doesn't break any current functionality and all current work will work the way it always has. I'm not sure I fully understand the resistance to a feature that will help many and doesn't break anything for anyone else.

If anyone wants to see me ramble and show what's going on in the xml files and how having a separate root is easier than hard-coding the different folder locations, I made a video:

https://youtu.be/LsifADgY8uE

I realize that I talked a lot about students potentially deleting or messing with the files. My kids are actually really good and that hasn't happened (yet), but I would prefer to keep that from being an option. Even if a kid deletes everything else in the stuff folder, if all of a students project info is in a private location, none of their work is lost. You may have to restore the stuff folder, but their work is secure- including the xml file that defines the project.

For those who have read this far, thank you for your time. I am not trying to be argumentative, but the longer I have thought about it, the more I think that the option should be available- even if it isn't enabled by default and the settings are hidden far far away.

@shun-iwasawa Please know I value your opinion a great deal and am not trying to be frustrating.

BTW- if anyone is wondering why my windows are pink- they are in honor of my daughter who was born in December.

[ghost]

@konero

Funny Cat Pics

Nice touch.

[konero]

Ok, I think I understand why multiple Project Root directories can be useful now and why you might want to change the default location from time to time. Good explanation.

[blurymind]

I have filed a feature request in the past that is in some way related to the issue at hand: https://github.com/opentoonz/opentoonz/issues/269 It is supposed to solve the problem of having a project be scattered around the hard drive and difficult to move to other places and share with others.

Since then another user filed a duplicate of my feature request here: https://github.com/opentoonz/opentoonz/issues/669

If the entire project can be easily contained into a singular folder - as @turtletooth noted - it will be much simpler and straightforward to share with others and move around - with no need of opening command line and typing commands to create symbolic links as @konero suggested. Remember most students came to be animators - not programmers.

It should be as easy as -

file>open project folder file>open scene

and a command to: file>create new project folder

Look to how Autodesk Maya does it carefully. Projects there can really be contained within a single folder. You can reference files from other projects if you want, but its easy to sustain a project in a single folder that can be moved to other locations without breaking things.

Maya stores the project path as a variable that the user can specify by navigating to said project folder. All the resource paths are then relative to that path - when their specified paths are not full paths. @shun-iwasawa As a result you dont have to specify the correct path to each individual resource folder when you want to open a project on another computer - you only need to tell maya where the project root folder is. Its as simple as that - the software then figures out where the files are in the subfolders automatically.

This is the HUGE difference between what Maya does and what Opentoonz is gravely missing. Resource paths that are relative to the project root path. A project root path that is the only thing the user needs to specify in order to open an entire project that has been moved.

[blurymind]

here is a screenshot for reference.

Please note the second row - 'LOCATION:' That is the path that I am referring to. When you tell maya where the location is - it just knows where to find the resources in it - if their paths are not full paths - they are relative to the root and are seen as subfolders.

But the root is a dynamic variable specified by the animator when they want to open a project. Its not something that is stuck to opentoonzstuffs folder on Dan's computer

[Rayek]

I agree with Turtletooth and Blurymind - adding these features will not change the current workflow, and it will make it far simpler in a classroom situation, but also when sharing / archiving things.

I would also think most indie and amateur animators would prefer to save their work self-contained in the same project folder. And the manual already gives an option, which must be done by hand, to change the project root. Makes sense to simplify this part.

[konero]

I like @blurymind's Maya Location example.

You would select the overall location to store the project files.

I think OpenToonz will need the ability to index where all otprj.xml files are located. If for example we think of the Project Root \OpenToonz 1.0 stuff\projects directory as nothing more than an index rather than a storage location, which is actually how @shun-iwasawa seems to have explained it, then a Load Project Directory menu item can be implemented in OpenToonz that when used, you select your Project Directory and the otprj.xml file will be aggregated to a new xml file located in \OpenToonz 1.0 stuff\projects\otprj_index.xml which will store the locations of every project.

If the location is left blank then Toonz will store the project in C:\OpenToonz 1.0 stuff\projects like default.

If we use a custom location Location: D:\projects then Toonz saves the project in that location, creating a new folder with the project name and aggregating its otprj.xml location to C:\OpenToonz 1.0 stuff\projects\otprj_index.xml but it does not add that custom location as an absolute path in the individual otprj.xml file, it is only a save/load location for otprj_index.xml.

<D:\projects\project-name\project-name_otprj.xml>

If the project-name_otprj.xml file uses relative paths, and that is the intention of all this, then OpenToonz can grab the path to the project-name_otprj.xml file.

path to otprj.xml + relative paths = D:\projects\project-name\+inputs.

That means, if we were to Load Project Directory later, perhaps at a different computer, OpenToonz will aggregate the new location to wherever the project directory is stored. At home it can be stored in D:\projects but at school it could be on a USB drive of E:\projects.

path to otprj.xml + relative paths = E:\projects\project-name\+inputs or D:\projects\project-name\+inputs.

If makes no difference to the actual project, because we simply aggregated the location of otprj.xml to otprj_index.xml, since otprj_index.xml is the file that is actually read for project locations. No need to worry about absolute paths used when creating a project, since advanced users know what they're doing, just leave that override there like normal.

[konero]

In summary of the above. OpenToonz would read for project directories in two locations.

\OpenToonz 1.0 stuff\projects Which is the default Project root.

\OpenToonz 1.0 stuff\projects\otprj_index.xml Which is an index of custom locations saved to the default Project root directory. Basically it works like symbolic links.

1. Create new Project
2. Set custom location
3. Leave resource folders as relative
4. Save

The projects otprj.xml file path location will be aggregated to otprj_index.xml.

OpenToonz should have a Load Project menu item. If you move the project directory to a different location breaking the link to the index file you would simply need to Load Project again to fix the link, like any self-contained archive file.

Since the project directory otprj.xml file may only contain relative paths OpenToonz will need to grab the file path from otprj_index.xml first and then append the relative file paths in otprj.xml.

[ghost]

@konero That's not a bad idea. The file browser already has the ability to see folders that aren't in the project root as projects with one removed line from filebrowsermodel.cpp:

This let's this happen (in my documents folder):

And you can set it as the active project.

[ghost]

@blurymind @konero I like the idea of being able to set a location for the project, but I still think it is nice to be able to set other project roots- I like the ability for OpenToonz to automatically add any project that ends up in a certain folder.

[blurymind]

@turtletooth One does not have to negate the other. =) https://img.buzzfeed.com/buzzfeed-static/static/2015-03/26/19/enhanced/webdr06/enhanced-25942-1427414324-7.jpg

On Sun, Jul 24, 2016 at 5:42 PM, turtletooth notifications@github.com wrote:

@blurymind https://github.com/blurymind @konero https://github.com/konero I like the idea of being able to set a location for the project, but I still think it is nice to be able to set other project roots- I like the ability for OpenToonz to automatically add any project that ends up in a certain folder.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/opentoonz/opentoonz/issues/373#issuecomment-234787538, or mute the thread https://github.com/notifications/unsubscribe-auth/AGMbVek35fIy_7VmJ0g_DLT0cKVQePLtks5qY5X3gaJpZM4IneCQ .

[ghost]

LOL. I agree.

[konero]

The pro about using multiple Project roots is you could link one to the USB drive letter or Documents folder, I imagine this would be used in specialized cases and should still be considered. The con of course is the actual projects themselves still are not "portable" and have to reside in a Project root directory if relative paths are used, that could get messy. I didn't initially think anything of this topic, but now I can see I would most likely extensively use the Maya location method, that I'm starting to become baffled as to why it's not already there.

For example in studio, we could put online one of the backup servers and simply index any projects temporarily to do a re-render instead of dragging 3TB of data to a working server.

The idea behind the index is so custom locations can be added to the default Project root directory to keep things tidy rather than have folder trees scattered across the browser window.

Think of it like this, the ones highlighted in yellow would belong to otprj_index.xml, the user wouldn't need to do anything other than use some kind of Load Project menu item or if a custom location was used when creating the project the first time it would automatically be added to the index.

(this isn't a mock up, I'm not suggesting showing the file paths, just so you get the idea)

Perhaps a built-in Project Manager Window could modify the index file so users could manage projects that way or have a scan and remove feature, where Toonz reads the index on bootup and if any otprj.xml files no longer 'exist' then automatically delete the entry from the index.

It could be combined with multiple Project roots too, since each could hold their own otprj_index.xml file and the destination for new projects can be determined like how @BrundleThwaite has shown in the top post by selecting which Project root to index to.

[ghost]

The con of course is the actual projects themselves still are not "portable" and have to reside in a Project root directory if relative paths are used

Actually, that is not necessarily true. You can tell OT to load a scene from any location, and if the project xml is located in the relative path where scenes.xml thinks it should be, it will ask of you want to switch to that project and load the scene. Any project created in a project root with the default folder locations doesn't seem to have any hardcoded path. You can then move the project anywhere you like it as long as all the files and folders come with it.

If the change I posted above were allowed to happen:

The browser in OT would recognize project files located anywhere in the system (or network? - there's a network button, but I've never used it.), and allow you to set the current project even if it wasn't in a project root. The only requirement here would be that all the paths are either relative, or hardcoded to the place where they currently are (which hinders portability I know, so relative is easier).

if it directly modifies the registry it wouldn't work in high security environments either

My solution in #664 doesn't touch the registry. It is all stored in the preferences file and could be set individually per user. I don't like messing with the registry unless I have to and think the preferences is nicer since it doesn't set the same values for every user.

The idea behind the index is so custom locations can be added to the default Project root directory to keep things tidy rather than have folder trees scattered across the browser window.

That would be a nice addition to the change I just mentioned- making it easier to get to projects instead of having to navigate to them.

[ghost]

Closed - feature added with #664