Unfortunately when Vetala is running on a network drive instead of a local drive, it can sometimes be slow when switching between the code and data tabs, especially if there are a lot of code or data items in the process. I am guessing that this is because Vetala checks the directory for new or modified files every time you click on the tab. It would be great if this could be speed up somehow.
Would it be possible to only refresh the code under certain circumstances? Maybe it should only refresh if the user specifically chooses the right click > refresh command, or if the user clicks on a different process in the view tab, or if a new code or data item is added/removed...? I realize this could possibly lead to confusion, but I think most users are aware of what they are doing in a process and the extra speed when switching tabs would be beneficial.
Also, to make manual refreshing easier, you could add a "refresh" button to the UI, so that the user wouldn't always need to right click.
What do you think?
-
louisVottero
- Site Admin
- Posts: 202
- Joined: Sat Aug 29, 2015 8:50 am
Re: Slowness when switching between data and code tabs
Great suggestion. I agree it needs to be faster.
Refreshing manually will lead to confusion. As the user will not get an accurate reflection of what's in the manifest. When people use vetala on the network it causes issues because more than one person edits the manifest at a time. When you hit process, it looks at the current manifest as is. I've actually had to add another refresh when pushing process to account for that, and avoid confusion.
Two solutions I'm thinking of are:
Each user has their own manifest. So that if you are building a character you can decide exactly what you want to run. This would remove some amount of needed auto refreshing. When a user goes to a code tab, a manifest is created for that user. The manifest defaults to everything on the first time a user uses the code in that process. This may cause confusion in cases were certain scripts are meant to be off, or are there only for testing. However it would mean that the user could better decide if they want to auto refresh or not. This setup still has an issue where a user creates new scripts and it gets added to the manifest. There needs to be an auto refresh in that case.
The code view needs to move to a hierarchy view. And this might even negate the need to have a manifest per user. If the code is nested I can refresh only code at a top level, and code that's nested could be refreshed only when expanding. This could give us 10 scripts at the main level, and 100s of scripts underneath that get revealed as needed. Also the hierarchy actually simplifies the what the code class works. Instead of checking a folder and a script underneath it with a data type file, I intend to make the data type the .py extension, and have files outside of a folder. Not sure why I didn't do this from the get go. I was thinking having each script in its own folder would better facilitate versioning, but I've found a good way around this.
Also, I think there are ways to improve my code so that it just runs faster. I need to look at it.
Refreshing manually will lead to confusion. As the user will not get an accurate reflection of what's in the manifest. When people use vetala on the network it causes issues because more than one person edits the manifest at a time. When you hit process, it looks at the current manifest as is. I've actually had to add another refresh when pushing process to account for that, and avoid confusion.
Two solutions I'm thinking of are:
Each user has their own manifest. So that if you are building a character you can decide exactly what you want to run. This would remove some amount of needed auto refreshing. When a user goes to a code tab, a manifest is created for that user. The manifest defaults to everything on the first time a user uses the code in that process. This may cause confusion in cases were certain scripts are meant to be off, or are there only for testing. However it would mean that the user could better decide if they want to auto refresh or not. This setup still has an issue where a user creates new scripts and it gets added to the manifest. There needs to be an auto refresh in that case.
The code view needs to move to a hierarchy view. And this might even negate the need to have a manifest per user. If the code is nested I can refresh only code at a top level, and code that's nested could be refreshed only when expanding. This could give us 10 scripts at the main level, and 100s of scripts underneath that get revealed as needed. Also the hierarchy actually simplifies the what the code class works. Instead of checking a folder and a script underneath it with a data type file, I intend to make the data type the .py extension, and have files outside of a folder. Not sure why I didn't do this from the get go. I was thinking having each script in its own folder would better facilitate versioning, but I've found a good way around this.
Also, I think there are ways to improve my code so that it just runs faster. I need to look at it.
Re: Slowness when switching between data and code tabs
Having a manifest per user is just going to cause confusion, especially when an asset changes hands. However, being able to version the manifest might be useful.
Changing the code tab to a hierarchy view is a great idea. I think that's definitely the way to go.
Changing the code tab to a hierarchy view is a great idea. I think that's definitely the way to go.