MatchSrf / MatchCrv
Spacebar doesnât work for Insert in Windows or Mac Rhino.
The keyboard Enter key does work.
I added it to the defect list.
Added bug items for Match and MatchSrf
In OS X, you can choose the Tab key in the options dialog box, then you can press the space ( operation is run from System Preferences / Keyboard / Abbreviations flagging "All controls"tab space.mp4 (5.7 MB) ). In fact this seems to work well in Rhino. I made a small video hoping can help.
For those who use a 3D mouse, you may want to set a button as Tab (â„)
I ran into a different problem. I selected the bezier curve tool (I donât know what itâs called in Rhino, and I donât have it in front of me) and tried to enter the three coordinates of the end points and control points into the field. It was very frustrating because I didnât realize that I couldnât put spaces between the three numbers. Now I know that the space character is a shortcut for enter, I can see why it didnât work, and I can see why it was designed as it was. However, I have some comments.
-
Coming to Rhino for Mac not from the Windows version, but from many other Mac and Windows applications, I have to say that using space for enter, or space to get the default value, is very unconventional in a GUI. Also, entering three coordinates into a single field is also very unconventional. Conventions for command lines are different, but for a GUI, three values should be entered into three separate fields on screen. As for using the space to enter default values, the more conventional approach is to pre-initialize the fields with their default values. So the space key convention becomes unnecessary. Pre-initialized fields have the advantage that you can see what the default values are.(The three fields can also be useful during mouse entry, showing the values of the mouse location as it is dragged across the work space.)
-
While many users like the convention of using the space key to enter default values, thatâs not what actually happened when I hit the space key. Instead, it seemed to reject the number I had just entered. (Iâm not sure, because I never considered the possibility that it was just waiting for the next two numbers.) The field label was asking me to enter the âfirstâ point, and when I entered three numbers and hit Enter, I knew that it had accepted them because (a) The field label changed, now asking me to enter the ânextâ point, and (b) because a square appeared on screen at the point I had entered. But before I learned to avoid the space key, it silently rejected my entry, leaving me completely confused about what I was doing wrong. This is not a recipe for happy users.
-
I could see the command entered in the pane on the right, but I didnât see any of the coordinates I had entered. Showing me the coordinates would have been very helpful, especially if it had been accepting my values when I believed it was rejecting them.
I can see the value of having a command-line approach to entering data, and I can see the value of having a user-interface tool for each possible command line, and vice-versa. But they donât have to use the same conventions, they just have to give you the same capabilities. I believe itâs actually better if they donât use the same conventions, because command-line conventions are designed for use in a command-line, and GUI conventions are designed for use in a GUI.
My experience of your Bezier tool was very confusing and frustrating, and took a lot longer than it should have. With the three-fields approach I suggested, it would have been much more intuitive.
the thing with rhino is how much you (can) use the keyboard⊠<return> is on the right side, your right hand is on the mouse⊠if you had to press return key for everything, there would be a whole lot of reaching across the keyboard with the left handâŠ
also, i agree with spacebar as enter being unconventional but not so much in cad world⊠or, autocad (for which rhino originally started off as a plugin for), has spacebar for enter⊠sketchup has spacebar for select which is pretty much the most used shortcut in sketchup⊠or- itâs not completely unheard of to use spacebar for something other than space in an application.
idk⊠this is one of those things that even if it feels weird at first⊠donât fight it. itâs not going to change and itâs sweet once itâs ingrained. 
it might be best if you describe or show what exactly youâre trying to accomplish⊠there may be a better approach.
but yeah, itâs possible (probable) rhino could be more intuitive in areas⊠but at the same time, itâs still learnable and not too much effort to do so (not easy⊠not difficult⊠somewhere in between).
1 Like
Yes 
Philip
I was entering a very precise curve using bezier coordinates that were generated by computer. (Eyeballing it was not an option.) I had the numerical values and I wanted to enter them into a Rhino document. So I had coordinates that looked like this:
5.92604, 3.72584, 0.0
And I pasted them into the âFirst pointâ text field, and nothing would happen. Apparently, the spaces were the problem, because I was able paste the data in once I removed the spaces. This is extremely counter-intuitive.
As for your claim that the use space bar for enter is
My point is that itâs probably possible to create a user interface that incorporates more standard GUI conventions without giving up command-line entry conventions like spacebar for enter. My point was also that using the spaces as enter when pasting that line of text in doesnât seem to serve any purpose, and only gets in my way.
An additional point was that the space character wasnât even serving the purpose of entering the data. It was actually preventing me from entering the data. So itâs not quite as sweet as you described.
BTW, if youâre about to suggest the better approach of reading from a command line, I tried that, but couldnât figure out the format of the file. If Rhino is using conventions that are so deeply ingrained that they donât feel a need to provide useful examples, theyâre actually creating a barrier to beginners, which is a huge mistake. The current UI and help system donât support that option very well either.
Hi Miguel-
[quote=âMiguelM, post:29, topic:21859â]
spaces as enter when pasting that line of text in doesnât seem to serve any purpose,
This is how macros (heavily used in Rhinoâs interface) are parsed my the command line in Rhino - Spaces tell Rhino where the string is split into commnads and options
! Line 0 10,10,10
Without spaces Rhino would not know what to do with the text.
-Pascal
Youâre describing a command-line interface and Iâm describing a GUI. My point is that you can keep your command-line conventions where they belong, without requiring them in the GUI.
But actually, the commas indicate that another number is coming. The spaces are clearly required between Line and 0, and between 0 and 10,10,10, but that doesnât mean they need to be forbidden between the 10s.The commas tell Rhino that another number is coming. The command-line language doesnât need to be as rigid as itâs defined.
But thatâs beside the point. In a GUI, the spaces donât even cause the problem youâre describing. If you imagine three separate fields to enter the three coordinates, then I should be able to paste in 10,11,12 (without spaces) or 10, 11, 12 (with spaces) into the first field and rhino would have enough information to distribute the three numbers through the three entry fields. This way, the spaces are actually helpful rather than harmful. Command-line conventions arenât needed in a sensible GUI.
Did you try entering the values in through the GUI like I described?
I just tested fixes for command like Match, MatchSrf, Sweep1, Sweep2, NetworkSrf, Blend, SetPt, etc. and now tapping the Spacebar completes the command like it does in Windows Rhino.
These changes will show up in an upcoming service release.
3 Likes
How about wishifying what the last poster asked for?
Namely that Rhino is smart enough that when a figure containing spaces and commas is pasted from the clipboard into the X-field in a dialog, Rhino automatically distributes the string into x, y, and z values?
I donât normally get close to dialog boxes but the request didnât seem unreasonable to me. (@pascal?)
1 Like
My gut reaction is this would be a monumental programming task to change how Rhino parses input strings that would not result in better surface models or higher productivity commensurate with the effort.
That said, I donât write code so my opinion doesnât matter.
We donât even cleanly support the primarily European swapping of commas and decimals either.
1 Like
Yeah⊠right now, Rhino for Macâs ui is closely tied to the Windows command line arrangement even though it looks different. What it could be on each platform is a perfectly good question though - I was trying to convey the current command line workings, which is indeed strict about spaces.
-Pascal
1 Like
Thank you very much.
You guys at mcneel are the best!
My suggestion of distributing the three values through three fields (2 of which donât exist yet) was a suggestion of how an ideal user interface should work. It was intended for long-term thinking. In the short term, when the user pastes in a string like this into a single field:
5.32, 4.96, 8.76
It should not stop at the 5.32. It should recognize that two more numbers remain to be processed, and should process them. Itâs fine to use the spaces as âenterâ in the sense that it enters the preceding number. But to throw away the rest of the data is a very bad user interface.
As for adopting European vs. American numerical conventions, that is actually very easy to do in software. The only difficult parts are:
a) Getting management to understand that itâs a simple task that wonât slow down development
b) Making sure that QA tests the application in both US and foreign locales.
When I write software, I always write it to work with the numerical conventions of the userâs locale, regardless of whether or not Iâve been given that requirement. The requirement almost always gets added in a later release, and itâs much easier to get it right from the beginning than to retrofit it later on. Speaking as a developer, I always prefer managers to impose that requirement on version 1, rather than waiting till they decide to expand to foreign markets.
itâs not that itâs throwing away the rest of the data, itâs that itâs generating an error with the first entry⊠5.32, <enter> isnât understood so nothing happens after that part.
if you could explain more about what youâre trying to do, what app the data is coming from, how big are the data sets, etcetcâŠ
itâs possible a script could be written which greatly simplifies what youâre trying to accomplish⊠because, to me, copy/pasting individual coordinates from one location into rhino while running a curve command seems more complicated than need beâŠ
for example, if you have a list of 20 coordinates, you could potentially paste all of them at once or import a .txt file and the curve is generated for you automatically.
I was trying to enter a curve using the curve tool. The coordinates had been generated by computer. I first tried to write a script, but I couldnât find any documentation about how to do that. Then I tried just pasting the three coordinates into the âstart of curveâ tool. But nothing happened until I decided to try it with the spaces removed. Once I discovered that it worked that way, the rest of my task was a breeze.
If the presence of a space in pasted text generates an error, this should be fixed. It should not be possible to break a user-interface. The UI should be prepared to correctly handle whatever input the user throws at it, no matter how absurd or strange. This is why you canât drag the arrow off the edge of the screen no matter how hard you try, and why the scroll bar thumb stays inside the scrollbar no matter where you drag the mouse. Sometimes, âcorrectly handleâ means popping up a message telling the user that its input makes no sense. So in this case, âcorrectly handlingâ the space in the pasted text could mean either ignoring the space and reading the rest of the line, or popping up a message telling the user that spaces are not allowed in the pasted text. While I prefer the first option, the second one is still far superior to what actually happened. The current behavior should be considered a bug, and it should be fixed. Also, some sample code showing how to do this on a command line would also be very helpful, but the bug should still get fixed.
Thereâs plenty of documentation.
Start page
Python/Rhinoscriptsyntax online help
Python/Rhinoscript Primer
RhinoCommon samples
RhinoCommon SDK
âMitch