generative modeling for Rhino
This has come up a number of times, but I thought I'd ask one more time before I start typing.
Would it, or would it not, be useful to have a switch between Expert and Beginner modes in the Grasshopper UI? At the most basic level this would involve hiding freaky components from the Beginner mode, but I imagine that I could also hide items from popup menus and other UI elements.
As there are more and more components every release, being able to hide the geeky ones must be a relief for beginners. Or am I wrong?
Certainly these data could be used by xkcd to derive funny conclusions :]
I've been thinking for a while about some kind of reminder/alert, or color-coded info, warning user about how slow components usually are and/or how propense they are to fail.
That would be great for teaching purposes, when you haven't enough experience using some components (so you can't identify them as clearly dangerous) or when you want other people to make a profit off of your use of Grasshopper (XML file storing these data) but not needing to say "Hey, watch out those Solid Difference; you'd better use Brep Join!" (for example).
I've been using Gh for about a year now (off and on). As an intermediate user I think it would be nice if there was some sort of way to edit each component so that it displays its data in color. I know this might sound cheesy but one of the things that I struggle with is data manipulation and how it is distributed to other components. (Especially with data trees and list) ie: lets say you have two components that are being combined into a stream or dispatched. If the compnents up stream could have an icon in the right click menu for "color" (like the panel icon) then teachers could show students how each components data is interacting within "list" or "tree" components with that data "color coated". I know that there is a draw option for trees but maybe this could be something that could even linger over into that option as well.
just my thoughts, so forgive me if this would be extremely complicated on your end!
Thanks for all of your work!
David, while I'm by no means an expert, I do try to do weekly "lunch-n-learn" sessions on GH with interested colleagues, and I have to say the most confusing thing for most people are the data paths/data structures.
When I was first learning GH it wasn't nearly as robust, there was no path mapper, no flatten & graft, etc, and i think these components (the ones that deal more directly with data rather than geometry) are what throw people off. I don't have any good suggestions for how to "do away" with these as they're obviously such an integral part of GH now, but that's just my two cents.
I think others have mentioned that training videos are a huge help, and I agree, but most of the videos that I watched when I was first getting started are now hopelessly out of date.
To sum up and express my own opinion: fully customizable workspaces, being able to choose Tab.Panel names, separators and maybe icon layout (normal/disabled/hidden/&c.) would be the most flexible choice. These workspace templates could be stored in one or several XML files.
Tooltip message showing Tab.Panel (actual workspace, of course) would be really useful when trying to figure out where components are located.
Being able to hide Panel but keep Tab visible, as previously mentioned by Danny, is interesting.
I guees that being able to choose the arrangement of components and wich and how many of them just appear and wich of them are only available via the drop-down panels would also be useful/desirable when customizing.
Markov info (statistical data of use more than Markov chains) could also be used to arrange/sort components and [dinamycally] decide (customizable/switchable behaviour) which of them would be only available via the drop-down panels.
I see these features working for standard, plug-in (Kangaroo, Firefly, gHowl, &c.) and .ghuser components but, what about components that aren't available on panels at all? Should workspace templates (thanks Danny for terms) be per .ghx? Should these components do not provide info about Tab.Panel? Should default Tab.Panel info also be always provided?
I also like how vvvv highlights compatible inlets when you pick an outlet.
Not entirely on topic, but something I've always thought would be helpful (for use but especially for teaching) is an "Apply" button for script windows that updates the definition without closing the script editor in addition to the "OK" button which updates the definition and returns you to the canvas. When leading a tutorial I often want to be able to show the result when the code is changed, but closing and reopening the editor is problematic for students following along, who might not be typing as quickly. Being able to leave the script editor open so they can catch up but also demonstrating the results for the faster students would be great.
(It would also be nice especially when working in subroutines not to have to rescroll/find my place after every test update but just apply the change and continue typing where I left off.)