Adding a search path in Python editor (Windows Rhino)

Either I’m stupid or the editor is… How do you add a search path in the editor that you can’t easily browse to - like a hidden folder?

As far as I can tell, no way to add a path by pasting or typing… And Browse for folder doesn’t show paths to hidden folders or shortcuts…


Hi Mitch,

If you type this in a terminal:

defaults write AppleShowAllFiles TRUE
killall Finder

That should work.

To paste a path, in the Open dialog type shift + cmd + g to open the Go to the folder: dialog and context click the edit box and select Paste.

Hey Alain… Windows… Built in editor… Sorry, I wasn’t very clear.

Hi Mitch, seems like the BrowseForFolder dialog is just crippled. Meanwhile you could close Rhino and try to add your path to settings.xml here:

C:\Users\heynick\AppData\Roaming\McNeel\Rhinoceros\5.0\Plug-ins\IronPython (814d908a-e25c-493d-97e9-ee3861957f49)\settings

Note that is not meant as a permanent recommendation, just to get the path in and proceed until the BrowseForFolder dialog is improved. You may make a secure copy of the xml file before editing it just to be sure.


BrowseForFolder is a standard windows dialog, it has always been “crippled” in this way, I have seen the same thing happen in other programs. The main thing is not to use it for these type of situations… The files search path dialog in Rhino options also uses BrowseForFolder with the same limitation, but fortunately the dialog also lets you paste in a file path directly, which the Python editor does not…

My main problem here is that I want to instruct people to put a folder somewhere inside


and then have them set a search path in the Python editor to that folder. Unfortunately, that does not seem possible, and I’m not going to ask people to edit the .xml.


No. Run _SetWorkingDirectory to see a different way for browsing with a text field in Rhino. It seems to be possible…

Maybe your first post was not clear as it stated you wanted to paste a hidden folder location. If you do not hide the folder beforehand, it should be possible to use the existing dialog to pick it. I am asuming that the folder path remains unchanged if you hide the folder later.

Regardless of where and how you or others will put the path there, why do you want to hide this folder if the path to it will be visible in the module search paths ?


This is a hidden folder… Anything inside it is also hidden… I do not want to hide it, it is hidden by default. It is the “default” place where things concerning user settings in Rhino are stored.


I think what @clement means is if you un-hide (read: show) your default hidden folders, you’ll be able to navigate to AppData\Roaming\McNeel\Rhinoceros\5.0 with the “Browse For Folder” dialogue box. This is indeed true. See screen shots below.

First select “Show hidden files and folders” under “Folder Options” in the Control Panel.

Now you can navigate to hidden folders in the “Browse For Folder” dialogue box.

Maybe this helps?

P.S. I should note that I completely agree that this way of browsing for folders and files is a pain. I’d much rather be able to input (type) the path similar to a standard Windows Explorer window.

Yes, I understand about showing hidden folders in Windows. This is not about me finding stuff, this is about creating a set of instructions for an average user to set a file path in the python editor to a folder somewhere inside the user’s appdata/roaming…Rhino… folder - which is where Rhino stores most of its “user” settings - without having to tell the user to show hidden folders.


Hitting the nail right on the head here. I have this issue every single time I issue GHPython components which implement modules/assemblies that need to be referenced. We discussed this issue over on Github last year.. Honestly, just being able to copy/paste the path to the editor would be terrific at this point :wink:

1 Like

@AndersDeleuran I agree 100% that this limitation should be removed, and I did not add it in the first place so I am not here to defend it. However, in general I think it is hugely counterproductive to instruct users to install things into the Rhino appdata folder.

The best place would be a folder they have easy and common access to. This would also allow to load different versions of the module if your users need them in parallel with other ones. Installing into the Rhino appdata folder is, in Rhino terms, like those old programs that used to install their .dlls in the Windows folder in old Windows 95 days… usually the result was some conflict.

Just my two cents


The problem is that on both platforms, some of the stuff the user does need access to is indeed stored in hidden locations. On Windows it’s Appdata… and on Mac it’s Library>Application support…

I would be very happy if all that changed, but for the moment that’s the way it is… --Mitch

Just checked today on one of your Win8 labs computers, it was not hidden at the university. But i am not sure if someone messed with the windows default settings. On my system the folder was not hidden either, i wonder how i would open


to access my workspace files if it is hidden. I agree with @piac about the fact that this location is not the best place to store new data in, especially if it seems to be hidden on purpose, but it justs seems inevitable eg. if i create a plugin using a *.rhl installer including configuration files, workspace etc. and it is installed for a single user, the content usually ends in a subfolder of the plugin directory under AppData as well. The only file i`ve ever deliberately added to:


is a link to my python script folder. This was necessary in older versions of the PythonScript editor because it somehow started any file browing at this location.

Imho there is the problem. Why hide workspace files and other important things from the user ?
I do not get why you would do the same with scripts ? eg. If the average user manages to paste a hidden path into the FolderBroser dialog, how would they access the scripts stored there without unhiding the folder ?


Unfortunately, it is the only spot that I know of in Windows that users can save files to without some sort of admin rights. I guess Windows has a quick link to the ‘Documents’ directory (which is really still in this appdata directory.) Would Documents be a better spot?

I guarantee you it’s hidden by default. Every “stock” install I’ve ever seen has it hidden. I have always accessed these locations via either shortcuts - a shortcut to a hidden folder is allowed and is visible - or by typing %appdata% at the start search box. Neither of those methods work of course in the Python editor search path box.

As Steve said, I always believed this was the “recommended” place to store stuff without having to worry about permissions. I also hate when a program adds a folder to “Documents” without asking - some still do.


No doubt with that, therefore i would recommend storing scripts in a location which can be user accessed without unhinding the folder. I hate all these UAC features, especially when i have to setup SyncToy.


Agreed, that’s also what I’ve been doing since our thread over on GitHub. The problem is more related to when you implement say Kangaroo2 or Plankton in your Python scripts (and you don’t want duplicate dlls floating around your drive). Didn’t mean my comment as a criticism, just to say that this process is indeed rather clunky.

I don’t actually have a problem with having stuff in hidden folders if there is an easy way to get to them when needed. It’s not such a bad idea to make it difficult to accidentally delete something like the toolbar file or the license file…

I like Grasshopper’s method of having a “special folders” menu item. If one can paste a path into something like the file search path dialog, then all you need to do is tell the user to open the folder via the menu, copy out the path and paste.


Just installed Windows 10 on my home laptop. For what it’s worth, it made this process much smoother if you check this guy:

Which also seem to affect this guy:

It’s a Christmas miracle :santa:

Edit: Come to think of it, this might actually also be the case on Windows 8