SPACEBAR not the same as ENTER, please make it so!

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

Excellent. Thank you. I was actually looking within the help feature of the application, which was where I couldn’t find anything. Links to those articles in the help system would be helpful. But those look like useful links. I will check them out in the morning.

1 Like

There are some links in the Help file on the windows side but maybe they have not made it over to the Mac side yet, I will put in a request. Looks like the links on the Windows side are also out of date, I will report that too… --Mitch

FWIW:
Mac help > Scripting and programming > Rhino scripting

Right at the top of this page it says:

A space between characters or a new line act like pressing Enter at the command line.

Towards the end of the page, the following links are given:
http://www.rhino3d.com/5/ironpython/index.html
http://wiki.mcneel.com/developer/python

@wim

I think the Help files are not all that clear so I filed a bug report for @margaret to look at :

http://mcneel.myjetbrains.com/youtrack/issue/RH-31070

Feel free to add your comments…

–Mitch

I’m not objecting the the space behavior in a command line.

1 Like

It seems to me that there’s a simple solution. If spaces aren’t allowed in the input fields of the curve tool (or any other tool where spaces aren’t allowed), it should be a very simple task to remove all spaces from pasted text before processing the line. In software, it’s very common to first remove spaces at the beginning and end of a line before processing it, so removing spaces from inside is not much of a stretch.

In addition to the “space after comma” problem for new users entering coordinates, it would be really helpful to make it easier (or even more obvious) to differentiate between world and relative coordinate entry.

Many programs use relative as their default, while Rhino is using world. This is also vexing for a new user. And finding the information to prefix their coordinates with “r” is a gamble with poor odds.

I also like the suggestions being made for tabbed fields for a number of reasons. Not mentioned is that A) it’s faster, since the left hand is covering the tab key and one does not have to hunt for a comma with their mousing hand, and B) Rhino could also display a checkbox indicating relative and world data entry. ~Dave

heh… just noticed that spaceBar now works as enter for many of the commands reported in the thread.

i’m not sure when it happened so maybe it’s old news by now but just in case anyone isn’t aware of the change… some changes have been made.

(@DigiFabLab @Philip )

Thanks Jeff! I haven’t noticed… :slightly_smiling: Have to check when I get my new(er) MacBook Pro configured…

Philip

Spacebar still doesn’t work as an Enter when entering values in Gumball. I wish it did.

Me too…

Philip

I see that too. Logged in MR-2907. Thanks for reporting this.

-Dan

1 Like

This long-standing paper-cut:

RH-36510 Gumball: Pressing Space in value entry does not function as Enter

should now be fixed in Rhino 6 for Mac 6.19.

3 Likes