PointsManipulator visual feedback

neobobkrause

I'm using pointsManipulator's in a FS. The way I'm using it is to allow the user to toggle the selection of a point. So the count of the points the manipulator refers to is always 1. When this point is unselected, which it is initially, the "index" of the manipulator is set to 1, and the single manipulator is drawn as a hollow grey dot. When the user clicks the manipulator, the manipulator is briefly displayed as a hollow red dot, but then returns to grey. In the manipulator change function, I change the manipulator's "index" to 0, indicating that the single point is to be displayed as selected. Problem is, the appearance of the point doesn't change - or if it does, the change isn't at all obvious. How does a selected point of the set present differently than unselected points?

Update...

After researching a bit more, I found that selected points do stay red, but that there was an error in my code that caused points to be unselected. But now I find myself with another pointsManipulator challenge. - Clicking on a selected point doesn't generate a manipulator change event nor an edit logic event. So once marked as selected, there's no means to recognize when the user wants to unselect a point if, as is the case in my code, there's only one point in the set.

It seems to me that there would be value in calling the manipulator change function whenever a point is clicked on - whether the point is already selected or not.

- Bob

Evan

Hi @neobobkrause - it sounds like your use of the point manipulator is deviating a bit from our intended purpose.  The manipulator is intended to allow a choice of selection between multiple points.  I anticipate problems with trying to use it as a toggle mechanism.  Specifically, once a point is selected, the only means to de-select it is to select a different point.  If you only have one point, I would expect it to stay forever-selected after it is first selected.

Now, it sounds like you experience something slightly different: you select a point and it never actually gets the red selection highlight.  This is unexpected.  If you have an example to a document that exhibits the issue, please feel free to post it here.  Though, even if we sort that out, I anticipate we will then hit the issue outlined above.

If you think a "toggle" manipulator would be of general use in the system, you could file an improvement request to add such a manipulator.

A short-term workaround could be to use the flip manipulator (https://cad.onshape.com/FsDoc/library.html#flipManipulator-map).  It can function as a toggle of sorts by examining the "flipped" value.  Though, it will have an extraneous direction attached to it.

neobobkrause

Hey Evan,

Thanks for your considered response. I've just made public an initial version of the project I'm working on that uses both pointsManipulators and linearManipulators. The feature is called Meta Sculptmaximilian_schommer  excellent Sculpt Face feature. In this update, Meta Sculpt uses pointsManipulators as a visual clue and gesture target used to toggle the selection of spline intersection points the user wants to move to sculpt the face. Multiple points can be selected at a time, allowing a single drag using the linearManipulator arrows to affect all selected points at once.

Meta Sculpt uses pointsManipulators to directly manipulate the selection of points. Though I considered using a query parameter, that option is unworkable because the use case for sculpting tools is that each point might have a different set of movements. A query parameter doesn't gracefully support this user experience.

A pointsManipulator can refer to a set of points. - However, only one point referred to by a manipulator can be selected at a time. My use case requires that the selection and deselection of as few as zero points and as many as all points be toggled simply by clicking on each point. I also want each selected point to appear selected - that is, have an appearance unique from deselected points. I'm using a separate pointsManipulator for each selectable point and setting the manipulator's index value to one. But I can never set the index to zero because once I do the manipulator change function will no longer fire when the user clicks on a selected point. The big downside of this workaround is that selected points have the same appearance as non-selected points.

Some of the OS team may see my usage of manipulators be "novel" and outside the way they were initially intended. But I believe that the user experience is much improved by more direct manipulation using constructs like manipulators instead of dialog boxes and other "modal" interfaces. So I applaud the availability of manipulators and encourage the OS team to expand their availability and capabilities going forward.

Let's get concrete. I recommend that the following capabilities be added to pointsManipulators, and that these changes be added in a backward-compatible way...

* Just as the number of optional arguments accepted by OS's edit change function will affect which editing events the function is called for, the manipulator change function should also accept optional arguments. The inclusion of these optional arguments should enable the function to be called when a selected point is clicked on. 

* It should be possible for the pointsManipulator to be configured to allow zero or more points in a set to optionally be selected at once, and a means for querying which of the points are selected and which have changed in the current call to the manipulator change event.

* It should be possible to change the visibility of points of a pointsManipulator. This capability should allow the visibility of individual points, selected points, non-selected points, or any combination to change.

Thanks,

- Bob

Evan

Thank you for the detailed reply, Bob! Having the in depth use case really helps us understand the motivation. What you propose does sounds like a natural extension to the existing point manipulator functionality.  It would be most helpful if you file an improvement request with this idea. This will help us prioritize such a change.  (See this post for more information on how to do that.) What you've written in your reply would serve as a good body for the request, as it already has your use case and the concrete changes you'd like to see.

neobobkrause

@Evan, if this thread is a good body for an improvement request, then it seems to me that, as the author of a post, there should be a checkbox I can click that allows me to indicate that this thread IS an improvement request without having to reenter the same text somewhere else. The OnShape team would prioritize adding this checkbox if you really do value our input and want to capture it efficiently to improve the product and its position in the CAD market.

This post should also be considered an improvement request. I don't have time to reenter it elsewhere. I'm going to spend that time writing useful feature scripts and other aspects of my job. 😉

- Bob