@DavidRutten I hadn’t actually considered icons, tooltips, etc. I was thinking more along the lines of long-form documentation – i.e. tutorials and examples.
If anyone else has any other reference package management projects, please feel free to add to this list.
Yeah, I remember that request. I’m not sure if the Zoo is really appropriate here, though. Perhaps the package manager and the Zoo could be merged at some point, but I don’t think it’s a requirement.
We are starting to rewrite most of F4R, so it’s time to add whatever is needed to the wish list. Already there is a REST api. We are working on it.
Great! Do you have any documentation for this API?
No yet. We are using drupal 7 as CMS, and its Restful Web Services (https://www.drupal.org/project/restws). But we are at the point of designing the data/entitites layer.
I moved 3 posts to an existing topic: Dates on Documentation and Articles
Hi Will, of course Donkey, Horse, Camel and Elephant are the typical pack-animals (beasts of burden). Dobbin sounds too lovely. Tusker would be cool - just some ideas (and I’ve never tried that beer)
An ALL inclusive PACKage > ALPACA
Fun fact from wikipedia about a ‘spitting code’ metaphor: " alpacas commonly bring up acidic stomach contents (generally a green, grassy mix) and project it onto their chosen targets"
Also, all that fuzzy white hair, and cute eyes, looks so charming and familiar. Want to hug them, just like Uncle Bob 
4 Likes
and it seems to translate quite well:
Arabic:
الباكا
Bulgarian:
алпака
Catalan:
Alpaca
Chinese Simplified:
羊驼毛
Chinese Traditional:
羊駝毛
Czech:
alpaka
Danish:
Alpaca
Dutch:
Alpaca
English:
alpaca
Estonian:
alpaka
Finnish:
Alpaca
French:
alpaga
German:
Alpaka
Greek:
αλπακά
Haitian Creole:
alpaga
Hebrew:
אלפקה
Hindi:
अल्पाका
Hmong Daw:
alpaca
Hungarian:
alpaka
Indonesian:
alpaka
Italian:
Alpaca
Japanese:
アルパカ
Klingon:
alpaca
Klingon (pIqaD):
Korean:
알파 카
Latvian:
Alpakas vilna
Lithuanian:
Alpaka
Malay:
alpaca
Maltese:
alpakka
Norwegian:
Alpaca
Persian:
آلپاکا
Polish:
alpaki
Portuguese:
alpaca
Romanian:
alpaca
Russian:
Альпака
Slovak:
alpaky
Slovenian:
alpaka
Spanish:
alpaca
Swedish:
alpacka
Thai:
อัลปากา
Turkish:
alpaka
Ukrainian:
Альпака
Urdu:
الپاکی
Vietnamese:
alpaca
Welsh:
alpaca
1 Like
As the global Rhino platform lead for Woods Bagot it would be nice to be able to author a global config while allowing for various local overrides (per studio/region, per project team, etc.) and even nested overrides, such as the global config being overridden by aspects of project team config, which in turn can be overridden by aspects of an individual user config. Examples of this would be the user overriding the author name in Grasshopper document from a generic firm name to their own name, or a team overriding the global default display styles and other visualization assets with stuff specific to their building project.
I think an important step to making installation more uniform would be allowing Grasshopper-only plugins to be compiled as *.rhi files. I think currently the only way for a Grasshopper library to be packaged as an *.rhi is if the installer is also handling a corresponding Rhino plugin (e.g. Weaverbird or Paneling Tools).
@bringley, thanks for the feedback. This is interesting. Please forgive me for quoting myself…
Configuration of Rhino/Grasshopper is outside the scope of this project. However, if that configuration was something that could be (de-)serialised (@brian? @DavidRutten?), then it’s something that could be distributed using a package manager! Would it make your life easier if you could write a config file containing Rhino/GH settings, template files, required plugins, etc. for teams, projects, individuals? I know it would for us, especially when you want to bring someone new into the team/project.
All grasshopper settings are stored in xml files. I do not use the registry for anything. However I do not think the current setting structuring lends itself well for sharing. UI settings which one might want to share and runtime settings which are specific to a user are both in the same xml file.
Thanks Will and David for the feedback.
Will, yes it would be useful to write config files separately for global standards, project teams, and individual users. The current methods we are using to silently install plug-ins along with core Rhino and the scripts that have to be run afterward to handle individual concerns such as Rhino display settings and Grasshopper templates are quite time consuming. (And this goes beyond McNeel stuff, for instance silently installing things like Radiance and Daysim to the C root to get Ladybug/Honeybee running correctly - but I think you have enough on your plate to be worrying about stuff like that…)
David, I’m afraid I don’t know enough about XML to intelligently formulate questions but if there are any methods for authoring or editing (scraping??) XML to help manage large numbers of Grasshopper users please keep us posted. A simple example of the automation I’m looking for is that all users get the same Grasshopper template file by auto-filling the template file directory in the Grasshopper settings, while individual users would have the Author field automatically overridden to match their Windows user name. A more esoteric example would be automatically assigning a subset of users (those working on custom internal toolsets) working directories in the Grasshopper Developer Settings.
It would obviously be nice to configure Rhino and Grasshopper all at once, but even if there were better ways to manage them separately it would still make a huge difference.
@andheum any thoughts?