Userobjects in the cloud

Hi,
Now that most people work from home it has become so evident why userobjects have to be synced between locations.
Having one set of components in one computer and another set in some other and distributing to other colleagues as well makes life very difficult. Hard to tell which component is the latest anymore, which ones are new in one location which ones are new in another. Which component I sent to whom.

So chaotic.
Any suggestions?

We have a shared dropbox folder which contains the components, user objects, etc.

We then copy it to the appropriate folders in rhino. I guess you could use symbolic links or some automation tool to have the 2 folders sync automatically.

It would be great if Grasshopper just let us set our own folder for components, user objects, etc. So you can have different sets of plugin and/or shared sets of them on Dropbox or a file server.

You can create a text file with your folder direction, change its extension to .ghlink and put that file in the gh folders. Doesn’t this work for you?

Oh I didn’t know that was a possibility.

Is there documentation on that somewhere? Can they be absolute or relative? Do I have any variables like Windows User Folder?

Hi @Dani_Abalde,

Doesn’t seem to work for me. I tried placing the .ghlink file in:
AppData\Roaming\Grasshopper
AppData\Roaming\Grasshopper\Libraries
AppData\Roaming\Grasshopper\UserObjects

…

Yeap, I just tried and it doesn’t work with google drive. I also tried to set the folder using the command: GrasshopperDeveloperSettings and it works only for .gha, not for .ghuser files.

Having one folder is not such a great idea after all. Imagine several people working on their own components, each of them in their own folder and each of them wanting to access the folder of others.

If 2-3 userobjects get created or modified per day, it takes a lot of effort to organize.

So it will be good to be able to add and track several custom folders of userobjects.

Yes, but I think that even though two different Rhino sessions can modify the same userobject in a shared folder, neither session will be aware of the other’s change because the components are loaded when you start GH, so it would force you to close and open Rhino and in the end only the modified version that has been saved last will survive. There would be a lack of version control and communication between the developers of the userobject.

I need to resolve this issue as well. In the future I will try to use github as a version control and storage and include a script in my plugin that downloads the .ghuser from github when you start GH. No idea if it can work.

“the components are loaded when you start GH” - Nope, the components get loaded when they get modified. Once you delete, create, rename a userobject in the UserObjects folder you will see it prompted in Rhino commandline.

The only thing missing is multiple custom folders for userobjects. (or cloud platform for distribution and management)

Yes you are right. Anyway you work with a copy of it in gh once you instantiate it on canvas. So, as you say, you have to delete and create a new one to “update it”. Two developers cannot work at the same time on the same tool. But well, it’s not that bad, and maybe not even a good idea.

@stevebaer, @DavidRutten any suggestions for centralizing user objects in the cloud?

EDIT: btw, where are saved the assembly folders? in the grasshopper_kernel.xml I found this with empty value:
< item name=“Assemblies:Folders” type_name=“gh_string” type_code=“10”>< /item>
but using GrasshopperDeveloperSettings I have many paths that I can not (or I don’t know how) to delete.

1 Like

Or at least multiple custom folders for userobjects (so we can use dropbox)…

1 Like

@will is this something yak can help with?

@stevebaer, why not just implement custom folders for userobjects in GH? Seems like a simple straightforwards solution for .ghuser. Yak is more devoted to serious packages.

I would rather see what is already possible or planned possibilities first.

@stevebaer, this sounds a little bit conservative. :smiley: Not to mention that Yak is aimed for plugin developers, not for end users, who don’t know much programming.

I didn’t propose a solution; just collecting information at this point.

Just saying, because implementing custom folders for userobjects in GH seems so simple to me. Yak could very well handle packages.

I don’t know how simple this would be until digging in. Sounds like there are file and directory watchers involved so it may not be quite as simple as suspected.

1 Like

Thank you for looking into this. It might be a thing…