Just as idea for the future. A bit like adobe. After an update with a change like that, a pop up message appears. Describing shortly the „major“ change with an option, to stay with old behavior or to switch to new one.
1 Like
I know we disagree on this, at least to an extent. I think your analogy is somewhat strained though, wouldn’t it be more like a restaurant removing and adding new dishes to the menu? If you really like their Chicken Kiev and one day there’s Szechuan Duck in its place, you will be justifiably upset and may well complain to the waiter, but the alternative is either (a) nothing ever changes or (b) you end up with a menu which lists all possible combinations of all the ingredients the restaurant stocks and you have to spend half an hour just reading through endless permutations of olives, ham, salami, pepperoni, artichokes, onion, pineapple, mozzarella, sardines, capers, and bacon until you finally find the pizza you like. Which then of course ends up being the Calzone, so you weren’t done after all.
My ideal software has no options. That’s a pipe-dream, I know, but it gives me something to aim at.
2 Likes
My ideal software has no options. That’s a pipe-dream, I know, but it gives me something to aim at.
1 Like
Yeah I think Apple’s approach ( to Mac OSX in the past, at least) is kinda the best of both worlds - expose the bare minimum of options in the UI to make things simple and intuitive out of the box, but at the same time provide deep support for under-the-hood tinkering and productivity enhancements for power users.
Personally I’d be fine with hand-editing a JSON or .config text file stashed away somewhere in the AppData folders; the threshold may be different for other people but raw XML…? That’s crossing a little into “complete hack” territory , stuff that’s not intended for human eyes and too easy to break syntatically 
More interestingly though, why the huge difference in UX philosophy between Grasshopper and its “host” application? It must be pretty jarring for users coming from Rhino where the settings page has 5000 different knobs and switches, with the basic expectation to be able to define custom macros and aliases for just about any workflow.
I’m constantly reminded of this when switching back and forth between the two environments, having to go from the flow-state of using personalized 1-3 letter Rhino aliases, to second-guessing the random order which things pop up in the GH search box. ( actually ended up uninstalling the TreeSloth plugin just because of the way it was interfering with common searches)
( actually ended up uninstalling the TreeSloth plugin just because of the way it was interfering with common searches)
could be nice if there is an alternate shortcut. Since “space = search” and “ctrl+space = radial menu” maybe something like “alt+space” could do a native component only search.
Different people in charge. Also Rhino is much older, much bigger, and has been developed by a fairly large team, whereas GH UI is just one person.
Feature and option creep are discussed for Rhino, and everyone seems to dislike it, but in the end taking a risk seems to be harder to justify when it’s the company’s money-maker and there’s 50 colleagues and 50 times more users who might get mad at you.
One reason I’m rewriting GH2 from scratch is not just that the code is becoming unmaintainable and unimprovable, but that it will give me a chance to get rid of 10 years of bad UI and feature decisions.
1 Like
Alt is tricky because Windows assigns it menu functionality. Would prefixing the search with a custom character also work as an option? This is already implemented for the # prefix, maybe tick or underbar? Period?
Underscore might be a good option, given the semantics of “canonical name” that is attached to Rhino commands?
But much more powerful would be the option to specify custom aliases, eg.
“P3” => Populate 3D
“SFP” => Surface From Points
etc.
and have those be privileged in the search box so you can call it up and type the characters instantly without having to look and confirm.
You can via the context menu of icons on the tab panels.
I recall that those aliases don’t always get first-billing on the search box, which defeats the purpose a little - and there’s no way of right-clicking on items that only appear on the dropdown menus?
Actually on a similar topic, user objects could really do with a bit of love in GH2 - the current state seems a bit of an afterthought with no way of saving multiple objects or editing them after the fact.
e.g. 90% of the time the Gradient component comes paired with Remap numbers and Custom Preview - enough of a logical “unit” to seem like a chore instantiating each one separately, but not to justify packaging into a dedicated cluster
Sorry for the nitpicking - I know these are small matters but GH is great for freeform prototyping explorations, they end up being like tiny annoying roadbumps in the way of focusing on the problem 
And hopefully these posts aren’t getting in the way of your big rewrite - keen to see how things will turn out in GH2!
That would be a bug. Have you got an example of an alias that fails to be the top result once typed in full?
Yeah, that’s a general problem with the dropdowns. You have to enable the option* that shows obscure components on the panels and assign your aliases in that mode, then switch back to regular mode.
* See? Another needless option solving an issue that shouldn’t exist in the first place…
Agreed, the current implementation sucks.
maybe the text box should appear when you start typing without having to do anything at all?
the middle mouse button on my mouse is terrible and the control key on my keyboard is trash
i’ll settle for allowing customization of the extra buttons on my mouse
Sounds like it is time to replace the two with fully functional devices.
If you just start typing it assumes you want to run a Rhino command. Early versions of GH didn’t send unused keystrokes to the Rhino command line and that was a major pain in the neck. Half the time you start typing a command nothing happens because GH was the active window.
Upshot is that Grasshopper can now only respond to keystrokes that could not conceivably be rhino command characters. I.e. control, shift, alt, arrows, tab, space. Of course once one of those keys has been hit it can put GH into a mode where it does parse regular characters, but that conflicts with another UI paradigm I subscribe to these days; “don’t mode me in”.
1 Like
Ah, active-window indecisiveness. I have this problem w/ certain panels in RH6… a total and complete pain, esp when it’s not all the panels & just some of them [layers, prop’s work fine…CPlanes or something doesn’t–try it].
I loved the two-button mouse interface of former GH iterations, because it was simple. and a big fat button like space bar was similarly simple enough.
IFF I have to use 3 mouse buttons, it’d be nice if either: a) I can customize their behavior; or b) or they could at least perform similar to the RH interface (e.g. righ-click menus, mmb=pan/orbit/whatever).
I use the radial all the time–perhaps because it’s prettier than the right-click-options when something is pre-selected; (perhaps some of you customize your mmb differently in RH?)
As an aside*–the icons in the radial (preview & enabled) are confusing visually as the one with a bolder (black) presentation has the opposite meaning in the two categories–even after years, I still have to look carefully…“ON” should be bolder, while “OFF” should be grayer (respective to preview/enable toggles).
David & Team–
Please bring back the option for the radial menu access with the space bar. It’s not only a condition of muscle memory but having “ergonomic balance” with not having to access everything via one hand (ie mouse hand)
Ctrl+Space—> radial menu
My comment was not for the Mac version. For good old PC.