The idea is to have the major Command line options listed next to the mouse pointer as a convenient way to complete the command without the need to reach the Command line options or a specific key relative to the given option (such like the F key which doubles as the “FullCircle” option for the “Revolve” tool). The position of those options should be adjustable in a similar way like the Cursor ToopTips window. X offset 50 and Y offset -100 for the lowest option (if 2 or more are displayed) should be fine.
See the example image below with the “FullCircle” option being positioned that way next to where the mouse pointer was initially upon picking the revolve axis. Once those hovering options appear on the screen, they won’t move together with the mouse pointer! Instead, they should only appear next to it at a specific step of the command so that they will stick on the screen to this very position awaiting to be reached by the mouse pointer subsequently. The “FullCircle” option is the most used one for the “Revolve” command, so it’s logical that it will appear as a hovering option closer to the mouse pointer, unlike some less commonly used options that will still be accessible via the Command line (clicking it should complete the “Revolve” command). That feature will speed up the work significantly if used the same way with other tools. People using a 3d mouse will no longer be forced to constantly reach the keyboard with their left hand to activate the most common options.
Yeah, something along those lines - not that specifically, yet, but more generally, interactive in-the-viewport UI is among the revisions we are looking at (down the road)
For those of us who regard the command line in apps like Rhino as a quaint anachronism from the last century and use the mouse almost exclusively this would be very welcome. Since it sounds like the team has several variations in mind why not start the necessary user evaluation and development process right now?
I suggest that a half dozen or so commands in the WIP be chosen for their coverage of the various types of detailed interactions that would benefit most from the in-the-viewport approach. Then ASAP begin coding the various approaches so we can try them out in the WIP via an “original vs experimental” switch. Then perhaps when V8 is ready the user base will have already indicated the preferred way to go. Then we’d have a more efficient interface sooner rather than “down the road” like, say, version 12 in 2040. Our projects would be completed sooner and our customers would be happier and our enterprises would be more profitable. Probably McNeel’s enterprise as well.
There is an easy way to make the Rhino developers feel the need for those in-viewport clickable options. Simply put those developers at full-day modeling sessions using a 3d mouse with the left hand. Then, one week later they will perfectly understand why it’s so essential to be able to complete the major commands via a quick mouse click about 10-20 mm away from the mouse pointer, in order to avoid moving the mouse to the Command line and/or to rely on constant use of the keyboard.
In my case, since I use a 43" monitor, I’m forced to move the mouse pointer 500 mm from the center of the screen each time I want to reach some Command line option. Now, compare that to just 10-20 mm. This is basically 25-50 times less mouse travel. Best of all, the hovering options should appear in the exact same location relative to the mouse pointer, no matter where it’s located in the viewport, which is an advantage for the muscle memory.
As for the “Revolve” command, I would put 3 hovering options:
“FullCircle”;
A new (non-existent yet) option called “UseLastAxis”;
“Vertical”. This one exists in the Command line as a command prompt “Press Enter to use CPlane z-axis direction” and can be activated either by leaving the 3d mouse or the regular mouse to press the Enter key or by clicking the RMB, but having it as a hovering option is way more useful.
I am a big fan of accessing the options via the keyboard, pressing single keys / characters / letters.
But i would love to have a consistent assignment / mapping between letters and options. - i posted this already somewhere but i can’t find the post/topic - sorry.
My wish for the command options:
always the first letter should identify the option.
if more then one option starts for example with ‘d’ then a repeatable press of ‘d’ should cycle through the different options - with some feedback, text background, transparent popup, …
why ?
sometimes it is really non-intuitive to have Distance = 12.3 → D
Delete = Yes → e
for another command Delete = Yes → D
pressing D for the first command should show a “Distance” as feedback
pressing DD should show “Delete” as Feedback.
I think the team should reconsider this. Surely program objectives can be adjusted for such a major workflow improvement as this. It will benefit ALL mouse users, not just 3D connection users.
I totally agree with this. Rhino is a NURBS modeling program and as such its users will benefit a lot from this particular feature that make their workflow both quicker and more convenient.
The programmers from the “McNeel” team also may think about the way they consider which feature request by the users is important or not. I have seen plenty of great requests posted by various users that got zero or just 1-2 likes, despite being very important and (if implemented) able to make the modeling with Rhino a much greater experience. For example, the request from this topic only got two likes thus far, so judging by the likes alone it seems like the request is not so important. I remember that a few years ago somebody from the “McNeel” team mentioned that user requests are considered based on the likes and posts in the respective thread. This is a bit misleading, because many users may support some feature request without hitting the like button on the original post. I’m pretty sure that at lest 80% of your users will be happy to use hovering options that pop next to the mouse pointer.
I have a friend who is mainly a game programmer, however, if you feel that your programmers are way too busy now and can’t implement hovering options for Rhino 8, he may be able to do that coding for a very short period or time before the release of Rhino 8, in case that you are willing to take that opportunity.
As I mentioned before, the best way to feel which future features are most essential for Rhino is for the Rhino developers to be a direct part of the modeling process with the program in a repetitive way, meaning having full-day long modeling sessions that require you to use those tools all the time. Then you will better understand how your user base feels like while using Rhino. Hopefully my poor English was good enough to explain what I mean. Don’t get me wrong, I LOVE Rhino and I would like to see it evolve and perform better, because it deserves to be better.
Another example clearly showing the advantage of having hovering options next to the mouse pointer: Running the ! _Fillet should display a vertical list with the (10 or whatever amount is chosen in the options) most recent radius values used within the current session, so that the user could quickly pick one of them without the need to manually enter the value in the Command line. This is especially useful for those who use a 3d mouse, but also for everyone else. Not to mention that it’s a nice way to keep a list of the radius values used so far and not having to guess what were the exact numbers.
(hint: implement if before the competition)
That would definitely include me although I don’t think there’s any need for the units on each entry or even at all. Perhaps better would be a single entry at the top of the list labelling what the list is ready to provide. I also think that cosmetically the button widths should all be the same based on the longest required, the entries should be decimal aligned vertically and trailing zero filled.
Similar concepts have been suggested over most of Rhino’s history but obviously never gained any traction with the developers. Maybe with V8’s extensive UI rework it will.
The above example is one of the many possibilities that the hovering options could provide for the majority of modeling tools. Solidworks uses a slightly different approach, but the difference is that it works in the reverse way: it evokes various sub-object dependent icons in a tiny pop-up menu upon selecting edges, curves, points or surfaces. For example, selecting a surface edge between two adjacent surfaces lets the user quickly click on the fillet icon next to the mouse pointer. Selecting on a surface which is partt of a solid object will evoke the shell icon, and so on. My proposition is different, because it evokes the most important hovering options for commands that are already activated.
