My Wishlist for WIP-GH2

grasshopper
rhinowip

#1

A number of simple things making a 's life so much easier :

Wish #1: Data Description

I found it being extremely useful to use the “Data Description” component from the Elefront plug-in in all my GrassHopper implementations. Which hints that it’s a generally useful component to be added in GH2 as a std component (although Elefront is - plug warning - is a very useful plug-in, and I use it a lot apart from the Description component, it is not so good if every project should involve 3rd party plugins for the most trivial things).

Fig. 1. This Elefront component (plug!) gets my +1 for introduction into GH2:

Edit: Answering a question in the thread below, the idea with the component is as follows.

Fig.1. Example of a “chained path” made with description components, starting in the upper left corner, propagating the same name down-stream :


.
.

Wish #2: SphereC/R

Same here, the one component I keep looking for a zillion times a day and… it’s not there!

Fig.2. Sphere Center & Radius component :

I would just love to see a (intuitive) std such component in there.
.
.

##Wish #3: Lock Layout Positions

Canvas layout position locking for individual Components and Groups (locking Group’s components & sub Groups).

Locking position, as opposed to Endable/Disable/Preview etc, is crucial for utilizing the GH canvas as a “user interface” with Sliders, and Toggle Buttons etc.

As it is now the layout groups and components are too easily messed up by the slightest careless mouse move and… well, that’s all there is to it. If positions could be locked the problem would go away altogether.

Sliders and Buttons would of course still work as expected, but they would not be accidentally moved or deleted.
.
.

##Wish #4: LED Diods (R, G, Y)

Yes, red, green and yellow LED Diods. Often I have to “disable” parts of a complex diagram while testing other parts without bogging down the computer with heavy calculations. And when done with the troubling parts I’d like to enable the disabled parts again. But where & which are those disabled parts?

Introduce std outputs on ALL components, including Groups, broadcasting whether it is Enabled or Disabled. LED Diodes could then be assigned to these ports, and from any zoom level it would be obvious where the angry shiny red LED Diodes are located.

Related features :
.

##Wish #5: Enabling/Disabling of Groups

Things related to LED Lights being used as state indicators as mentioned above :

  • Add Enable/Disable to Groups, propagating the state to included Components.
  • Indicate in the group frame whether the Group area is enabled/disabled (for those weaker among us being allergic of LED lights and thus wouldn’t take on the useless work of attaching LED lights to visibly indicate the enabled state)
  • A jump list main menu (+ popup menu) for cycling from LED to LED (or disabled Group to Group) would make it easy for developers to maintain and restore desired groups / parts of the model.
  • This feature would, of course, be more important than the LED lights, but I immediately feel I shouldn’t have told you that.
    .

##Wish #6: Stateable Toggle&Push

This may sound weird, but as a matter of fact, when I test local logical networks, sub networks which I often “chain-activate” by boolean triggers from other (earlier) stages of calculations, I often want to be able to trigger locally during development & testing of the sub network. For such situations I apply a std layout which I use frequently copying and dropping here and there in the logical network), like so:

Fig.3. Use Case : Picture shows a typical case, where I’m here is breaking up a “Bake signal” by inserting a component group used for Enable/Disable the “bool channel” altogether - while keeping the original signal attached. While at the same time providing myself with a loop-hole to locally trigger the signal (the “Pulse” button) for testing purposes.

Notice the double functionality; #1: Enable/Disable the signal altogether, and #2: while the original signal is available but not currently sending its signal, I can still trigger locally a (bool) pulse by pressing the Button component.

Fig.4. This component consists of the following logic :

So why don’t I just use what I already have? Well I do use it, all the time, but the buttons are not included in a “cluster” component, and thus will not be dropped on the canvas together with the logic. And, dragging this thing around suffers from the problem related to position locking of the components - the whole group is easily messed up when dragging it around in order to have it “within reach” from the trouble-spot being tested.

So: A component to be desired is on which, when you drop it on the canvas, includes the buttons as well as the logic AND keeping the component group together as a whole when moving it around. It should have a regular Group area as a bottom plate as well, since that allows for different colors (for example making the group area glaringly red as to hint about local “tweaks” to be removed from the model when its tested and done). The buttons & the component should be position-locked to the local inner area of the group-area (see Wish #3 above) while allowing the area itself (the whole) being freely moved around.
.

[Edit: 2017-05-25, 06:46]

##(Fix) wish #7: Default Cursor Focus (Scribble)
Amazingly enough, the cursor focus when opening the Scribble dialog is not on the main idea with Scribble as a concept - the text. :slight_smile: Dropping the component on the canvas or even clicking a text to edit, does not(!) end up placing the cursor in default position in the text field of the dialog.

A 10 second fix? Or 5? :slight_smile:
.

[Added: 2017-05-25,12:31 (UTC+1)]
##Wish #8: Lock Existence State
Prohibiting Rhino objects (including Gh components & groups) from being deleted (preserving the “existence state”) while allowing for “everything else”, like selecting and transforming etc.

Example use case where this makes very much sense is when creating “guide objects” (by baking or using pre-existing objects in Rhino template files) which the user is supposed to move around (but not delete) as to guide GH for where to perform its thing (in real-time or on user demand). As usual in UI situations, the risk is that the user accidentally deletes the guide objects which serves as input data for the GH logic, and the show would then disappointingly stop.

So, the ability to “LockFromDelete” or “PreventDelete” of objects would be gold in so many situations.
.

[Added: 2017-05-25,15:01 (UTC+1)]
##Wish #9: MarcusStrube Color Palette.
MarcusStrube’s Colors’ wish (which by mere coincidence is also my wish): A nice color scheme component.

Anyone using the existing color-thingy, trying to remember color codes, knows why this wish.

  1. http://paletton.com
  2. http://coolors.co

.
.

[Added: 2017-05-26, 04:00 (UTC+1)]
##Wish #10: Strube Input
Marcus Strube said (in a post here) what had to be said :

  • #.a … namely that Gh-component inputs should (optionally) display any entered constant values (Set Values) instead of only the input name.

  • #.b Double clicking on individual in-ports should toggle on/off the overlay/name-prefix info.

Marcus Strube’s illustration in Fig1 below demonstrates the idea. The value could be a “transparent overlay” or concatenated with the input name (Fig2) :

Fig.1. Transparent overlay of values - @MarcusStrube’s illustration shamelessly replicated here for your convenience :

Fig.2: Alternatively concatenated name+value pairs could be shown:

S:17
N:8
C:19

(The port names would still remain being S, N and C respectively).

.
.

[Added: 2017-05-27, 15:45 (UTC+1)]]

Wish #11: Named Views -> “Restore By Group” instead!

“Restore Named View” should include “Restore Group View”, in that a specific group is the target for the Named View.

  • Hit the target View - The “Named Views” feature in Gh is a good thing. Only problem is that it is based on a specific area of the canvas - only, and that area may (will, most probably) change during development, and so the intended target view is gone, or dislocated. If the target was identified by a Group instead, it is less likely that the view becomes useless, even if it would be moved far outside of the bounds it had when the View was defined. You will always hit the target of it is a Group that still exists.

  • By Name - Internally the target group could be identified by a GUID isntead of a name that may change.

  • (Re) Size : With a fixpoint in the upper left corner, the group will always be a valid target, although the size of the view may vary. But so can the Restored View (the Restored View can take on exactly the same size, or the same proportions as when defined, in both cases the likeliness of a useful Restoration of the View would be good).

  • UI surprise : That droopy eye UI-component is puzzling, even a bit surprising. It has the smaller tiny little click-target-area dedicated to the action which the user uses the most (although it requires higher precision, and thus is more tiring, to hit that little down-arrow at the side very often) while the big fat eye-area, which is used the least (for defining new Named Areas) is easy to hit, even without aiming. This is a school example of how to wear out the users. May I therefore I suggest to swap the areas so that the most frequently used click-area is the bigger one (the eye, that is).
    .
    .


Wish #12:

.
.

To be continued. :hourglass: :slight_smile:

// Rolf


#2

I know Rolf’s 9th wish! A nice color scheme component.

1: http://paletton.com
2: http://coolors.co


#3

You were perfectly right! I actually forgot just that one. It sucks to try to remember the color codes. I’ll add it. thank you for reminding me. And feel free to add more #wishes:slight_smile:

// Rolf


#4

…So what does it do?


#5

Once you enter a descriptive text to the Description component, you can with a click of the RMB expand (or propagate) another identical component ahead of you auto-connecting it and naming it for you, like so :

Fig.1. Demonstrating a “chained path” of description components, starting in the upper left corner, propagating the same name down-stream :

A description component will also auto-update the names downstream if you later change the name at the starting point up-streams (you cannot change it midways since chained names are kept updated in real-time).

The Description component simplifies making very clear and readable diagrams.

// Rolf


#6

That is indeed quite useful!

I agree with most of your wishes and would like to add one: Colour changing toggles. To display if a toggle switch is set to False or True so you can see the state without having to zoom in on the toggles.
I’ve already requested this before on the Grasshopper forum: http://www.grasshopper3d.com/forum/topics/suggestion-1


#7

Yes. This seems related to the Wish #4 (LED Diodes) and Wish #5 on enabling/disabling groups and components, including indicating their state with colored frames etc.

In short, very marked visualisation of states in general. When the models grow big being able to spot state in a out-zoomed overview is very important.

// Rolf


#8

I just had/have one other idea/wish or something where I sometimes think that it could be useful… I almost never use “Set Number” and almost always use a panel when using just one value as input for a component. And my 2ct opinion is that something like a toggleable input field for components could be a nice thing.


(David Rutten) #9

I’ll try and get around to it soon, but the era of 10 second fixes is over. These days it takes a good hour and a half just to start working on a fix due to all the code-synchronising and downloading and compiling-of-Rhino twice (once before I can start working and another test compile to make sure my changes didn’t break the compile).


#10

Safety first. :thumbsup: :slight_smile:

// Rolf