I just got a customer wish that makes a lot of sense:
Double click on a curve to show controlpoints.
And double click again to hide them for that specific object.
This way one can turn on and off controlpoints easily and turn them off for only the specific object.
Thanks
+1 good idea
+1 Yes please.
Hi Jorgen, all - I can imagine a collision with block editing and polysurtaces - I’m not sure how that should be handled. Polysurfaces could show SolidPts, I suppose, but that seems like asking for trouble as things are now. Block instances do have points - at the insertion point, and since there is no obvious visual cue to an object being in a block instance, this seems like it would need to be thought out- any brainstorms?
thanks,
-Pascal
I see your point, but I still like the idea.
Could Ctrl-doubleclick do the trick?
I now see the subject specifies this is for curves, so that eliminates at least some of the complication.
-Pascal
It would be great…something to get used to.
But if implemented just for curves it will be yet another dispersion of UI paradigms.
Please try to get double click functionality right from the start.
IMO it was already a very bad decision to allow blockedit to hijack double click functionality.
It is a very potential UI feature that is now allocated for blocks only. And to make things worse it is broken the moment you enter blockedit mode.
IMO too many of these ad-hoc implementations have been made during the Rhino development.
It’s the reason why blocks and their handling feels crippled, why layouts/pages and the management of details feels clumsy and half finished.
Please think twice before handing out double click to curves and their controlpoints…
-Willem
Would it not make sense to use subobject selection (CTRL+SHIFT)? Would controlpoints not be considered subobjects of curves?
Ernest
I hear you, but what do you mean by “getting it right”? What is your proposal?
It makes sense to me to double click blocks to edit them, BUT I miss being able to double click the nested blocks. That too should be added in my opinion. Not used as an argument in not implementing it on other objects.
How about using ctl double click on blocks?
Hi Jørgen, All
I do not have a standard proposal of how to implement double clicking.
My main point is for McNeel to be cautious about granting such a wish in a ad-hoc manner.
Like I stated double-click functionality is a very basic powerfull UI feature, it really deserves to be able to do more than just edit a parent block (among a few other things). This is part of what I mean when talking about “getting it right”:
The way this is currently implemented for block-edits is just a prototype setup IMO. It feels not thought through that only parent blocks can be edited and then the user has to resort to _BlockEdit anyway. It’s half of a solution causing more clutter than a single unambiguous way to edit blocks.
It makes sense for me too to edit blocks with double click, as does it make sense to activate a detail-view, or edit text objects or dimension text or…(am I forgetting any).
It would also make sense to me to turn controlpoints on or solid-points or enable/disable clippingplanes in this view, or…
@Pascal I’m pinging you at this point to wishify my setup for double click below:
If I would have to decide on double-click functionality for V6, I would set it up in a way that is transparent en not hard-coded. I imagine that there is mechanism to catch double clicks, a table customizable by the user will decide what action to take, based on the objects that were double-clicked.
In short: sort of like the setup of the delayed context menu but more elaborate: http://docs.mcneel.com/rhino/5/help/en-us/options/context_menu.htm
McNeel can decide on a vanilla setup but the user can customize that.
For instance I can setup double-click to apply curvepiping to curves when double clicked.
Imagine what possibilities it offers when the users can control what double click does via his/her own macro’s and scripts.
DC will show/hide mapping widgets.
DC will export the object, and delete it.
DC will report the objects layer
DC will report a curves length.
If these Double-Click tables could easily be interchanged it would be simple to have various setups for different tasks. Or make a setup for specific projects with task specific functionality.
-my2c
One thing to mention that will need to be sorted out: double-click and selection ambiguity.
The selection menu pop-up, currently prevents double-click to be efficient in dense models. It would be needed that a double click is caught/flagged and passed through the selection-menu pop-up.
So if I double click and the popup asks if I meant to click the text or the block, if I decide either of the 2 they will be opened for editing regardless of the selection menu.
Thanks
-Willem
Hi all- thanks for the feedback. I have no idea how hard or easy any of this is, but I’ll wave my arms in front of the developers and see what happens.
-Pascal
Thanks Pascal,
Just take it easy with the waving or you end up looking like this:
-Willem
Some say I already look like that, being, at least partially, a Frenchman.
-Pascal
Willem, all,
I am also in favor of enlarging the possibility of double click functionality, and I agree with Willem that this needs to be a coherent system-wide application, not just here and there (“ad-hoc”) based on user requests.
On the other hand, to offer a counterpoint to Willem’s suggestion that this should be a user-configurable setup - I would argue for a well thought out fixed set of functions with little user customization possible. This mainly to make sure everyone is “on the same page” for the purposes of support, documentation, online help, etc. It just seems basic enough to me that it should be predictable and do the same thing for everyone, in much the same way as a single left click…
My 2 centimes…
–Mitch
+1 for double click. At least for control point of curves and solidpts.
Of course a more congruent thinking for all the tools could be a great user improvement.
Ha, ha made my day!
+1
Hi Mitch,
In the past there was talk of a divided options set: regular and advanced.
This might be a candidate for the advanced set.
I agree that there should be a well thought of set of features coupled with the double click.
However being hard-coded will limit the possibilities for many users. How many trouble does the configurable aliases generate? How many users will customize double-click at all, and how many of those forget they did that?
Indeed double-click is very basic and should be well thought of. However the diversity of Rhino users’ field of work and the versatility of the software IMO justifies a customizable behavior for double clicking.
-Willem