As per the recent RCP posts, here are a couple of the most immediate points of feedback/wishes I could recall:
Edit Slider Color: It’d be great to be able to edit the green accent color, as one can with groups.
Set Default Slider/Group Colors: Being able to customise the default colors would also be terrific (ala Grasshopper Settings -> Palette).
Publish Multiple: Being able to select multiple elements on the canvas and publish them simultaneously would save a lot of right-clicks.
Slider Fidelity and Lag: The RCP sliders feel slightly less responsive than their canvas counterparts, also their dragging fidelity seem less precise (this might simply be because one can’t zoom in).
Slider Set Value: Being able to double-click a slider to type in a value would be great as well.
Element Wishes:Gene Pool, Value List, Color Swatch, and an editable Panel.
Canvas Group to RCP Group: This is a very loose idea. But something like selecting a named canvas group, iterating its elements, getting the elements that are RCP publish-able and named, and automatically making a new RCP group with these elements, might be useful (although it is definitely in Metahopper and scripting territory).
Best,
Anders
Edit: Regarding slider fidelity, that’s probably not actually an issue, as one can simply make the RCP window wider, to achieve the same effect of increased dragging precision as one would by zooming in on a canvas slider. Never thought of that, doh:
I would add to this a Complex Slider type with Base Value + Range value + Reset Range.
If often find myself setting up “start values”, which are actually deafult values, and then modify these values. In complex cases I sometimes have to try several times and need to start over, from the initial start values.
Typical case here. The sliders on top are initial values, the sliders below are “adjustment range values”. A solution that integrates all these three aspects into the sliders would be gold.
I’m not really sure how this relates to the RCP, but I come across this situation quite often myself. The approach I’ve been using is to script both setting/resetting the dimensions and values of genepool/sliders like so (having a button that enables one to reset them published to the RCP):
Cheers, I suppose the question might then be: Should a standard canvas slider have these features added, and, should one be able to access/set them from the RCP? I worry that adding too much default complexity is a slippery slope. I assume that cases such as these aren’t really that typical, but may very well be wrong here.
Ability to set the size (height) of elements. Maybe an overall switch (S, M, L). Right now usually the controls are very small. We already have the ability to collapse groups, so why make everything so tiny that it even clips off the lower part of a lowercase “g” for example. Especially now that resolutions and screen sizes have gone up considerably compared to 10 years ago.
Text Input through panels and showing the name of the panel
Make the button look more like a button. Right now a published panel and button look almost identical.
Just make it look better. Even in the realms of Rhino UI they look way too 2-dimensional. Why not at least the same style as for example the Properties panel in Rhino?
So all in all I love what RCP can do functionally, but in terms of usability it should just follow standard user interface guidelines for input fields and I think there are some very good guidelines and tried and tested best practices out there (like from Google Material Design or IBM’s Carbon Design System).
I asked for this feature long time ago and nothing changed from then. The actual sliders are not very useful because you can’t enter a desired value, and to scrub the slider up and down can be very slow with large definitions because GH it is trying to calculate the result for every value change.
A time-saver feature, indeed.
Also I want to be able to publish a “Geometry (Geo)” selector component to RCP (actually all the Params components will be useful to have this functionality) so I can run Grasshopper in the background without the need to open the GH window just to reference Rhino geometry in Grasshopper. Makes sense, I hope.
The new GrasshopperPlayer appears to share some functional/conceptual overlap with the RCP (i.e. a user indirectly interfacing a Grasshopper definition). Where the RCP allows the user to dynamically manipulate sliders/toggles/buttons and write to output panels, the GrasshopperPlayer appears to support defining input geometry and baking output geometry. As such they appear to fill gaps in basic Grasshopper functionality that the other is missing.
While I gather that one can likely use the RCP while GrasshopperPlayer is “playing”, are there perhaps some plans to integrate these two strands of development (I would love to be able to define input geometry and bake from the RCP for instance), or are they considered as servicing different user experiences?
Look who’s playing with the bleeding edge toys We haven’t even announced this feature yet as it is going through a ton of changes right now.
I think we can provide options to the definition to specify that it would like to use the RCP style UI when running as a command. Right now, we’re just trying to get the basic parts in place so you can have the definition perform different actions based on the context of how it is running. Running in GH, in a command, or on compute are the different contexts that we are trying to support for starters.
Haha, ever the I’m currently working on my personal laptop running Rhino 6 Evaluation. But I’m definitely super stoked to try this out when I’m back in the office! Thanks for the update Steve, this sounds and looks very exciting already
It’s awesome to see that the RCP has been updated for Rhino7. My monochrome OCD is super grateful That said, the new light grey colour scheme on buttons, booleans, and sliders makes it look like they are not enabled (to use Grasshopper terminology):
If I might slide in here with some feedback:
First off, thanks for the already improved RCP!
Then I have two questions / suggestions for improvement:
RCP can not be scrolled using mousewheel. That makes it different from almost every other panel that’s available in Rhino and it is really cumbersome. Why is that and can it be fixed at all (as in before GH2)?
When having lots of groups and a large RCP (the image that Anders posted gives a good example) there is a really annoying bug with scrolling, too: When expanding/minimizing groups you always have to move the scrollbar because otherwise your mouseclick in the RCP will be at a completely different location than what you see. This is really terrible because you could accidentally click on all sorts of things.
Any help / comment / insight is appreciated as always!
Still waiting patiently for ANY love given to the old RCP (now called Grasshopper, I guess not to confuse it with RPC).
When you publish a Panel to RCP to get some status information for example, I noticed that it can display multiple lines, but it doesn’t break lines for longer text.
@DavidRutten Are we ever going to see an update to it? Or shall we look for alternatives already? It’s a shame that such a handy integration of GH into Rhino is stuck in like version 0.1 since the beginning, while the rest of GH is so polished.
Apologies for bumping this one. Here’s my current project setup. The greyed out sliders and toggles in the RCP look like they’re disabled, while the panels appear dark/enabled. Maybe the sliders/toggles could get the same appearance (not sure if this is still one for @DavidRutten)?
We haven’t even announced this feature yet as it is going through a ton of changes right now.
I’m currently working on my personal laptop running Rhino 6 Evaluation. But I’m definitely super stoked to try this out when I’m back in the office! Thanks for the update Steve, this sounds and looks very exciting already 
That said, the new light grey colour scheme on buttons, booleans, and sliders makes it look like they are not enabled (to use Grasshopper terminology):
