How to select only vertices within a boxed region or ease selection of single vertices?

[openBrain]

For close integration, I would say that available filters are displayed in the Selection Panel in a list of checkboxes that you can dis(en)able with mouse so people that don't know the keyboard shortcuts may enjoy the feature.
Also a list of the selected items can be displayed with the 'long name' of the items.
Shortly said, I would expect to find in the Selection View all the nice features described here but accessible with mouse clicks so new users or people that seldom use the function don't have to read the doc.

[bejant]

Here is some ideas about key config customization. Which one do you think would work?

• Allow users to customize those key bindings by selecting from prepackaged "selection key configs". Provide only one pre-configured one defined as as you stated (with modifications for the missing keys you mentioned once we figure that out). Might want to define one for left-handed folks and right-handed-folks.
• A variant of the above: Only have one configuration that the user can customize, and allow them to customize it via the right-mouse-button-context-menu and save only one in the user preferences and don't provide separate named configs. (A big con: It leaves out the left-handled folks and they have to define it).
• A variant of the above: Let the user save/load configs by name from that same context menu: They change it, and save it, and the file they saved is made persistent in the preferences so that it is loaded at startup. And provide both a left and right handed config into some subdirectory that, when they open up the file browser to select one there, they can see them and choose one from the mix (and their customized ones will get saved right there).

Each would work but I'm thinking that #3 would be best. Several different FreeCAD users (students come to mind) might use one computer and this way each person could save their own configuration. In addition to customizable key bindings I'd like the ability for the user to change each mnemonic too, and that would (I think) provide the most flexibility regardless of handedness or native language of the user.

Oops, it seems there is an inconsistency between Part BoxSelection and the other two: I checked (on freecad-daily "0.19~pre2~202001251538~ubuntu19.10.1") and left to right and right to left are treated equally and select fully contained faces and faces crossing the bounding box.

I suspect that StdBoxElementSelection was working on Sept 07, 2019 when the wiki page was created. Maybe it broke because of the Big Merge? (That's just a guess, I really don't know.)

StdBoxSelection (Shift + b) will select an entire object if the Bounding Box covers about half or more of the object. I tested this only briefly using the default Part WB > Cube and Part WB > Cylinder using the FC 0.19 version below.

So, I will revise the pre-FR for the above and I will post a new comment when done, eventually. But, before I do, I will wait to give you a chance to comment on the above.

Thanks, and my apologies for this delayed reply.

OS: Ubuntu 18.04.3 LTS (ubuntu:GNOME/ubuntu)
Word size of OS: 32-bit
Word size of FreeCAD: 32-bit
Version: 0.19. (dated 2020-01-25)
Build type: Release
Python version: 3.6.9
Qt version: 5.9.5
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/UnitedStates (en_US)

[bgoodr]

For close integration, I would say that available filters are displayed in the Selection Panel in a list of checkboxes that you can dis(en)able with mouse so people that don't know the keyboard shortcuts may enjoy the feature.
Also a list of the selected items can be displayed with the 'long name' of the items.
Shortly said, I would expect to find in the Selection View all the nice features described here but accessible with mouse clicks so new users or people that seldom use the function don't have to read the doc.

Good idea, and I'll add that to the pre-FR.

But in order to do that, I want to use terminology that is well-documented. You have used the word "filter". Is "filter" a term that users know about already? I searched the wiki and came up empty, so I'm suspecting it is low-level implementation detail of how selection objects are "filtered" (e.g., coding internals for selecting vertices and not other entities), and not a term that non-programmer users need to know about.

[bgoodr]

Each would work but I'm thinking that #3 would be best. Several different FreeCAD users (students come to mind) might use one computer and this way each person could save their own configuration. ...

Agreed. I will add it to the pre-FR.

... In addition to customizable key bindings I'd like the ability for the user to change each mnemonic too, and that would (I think) provide the most flexibility regardless of handedness or native language of the user.

Agreed; the key binding to the action will need to be customized by the user. I'll need to state as such in the pre-FR, taking into consideration the Selection View being discussed earlier. Perhaps the Selection View is best spot to do such customization, versus the right-mouse-context-menu, but I'm not sure yet.

I've removed "mnemonic" from the pre-FR: If the user changes the current binding (in version 2 of the pre-FR), the key they choose may not be in the letters of "Deselect/Select" (think of the left-hand-mouse-users customizing it for the keys under their right hand: "d" is not there).

I take note per chrisb's comments in regards to this key config subfeature: I am recommending it be implemented only after the initial default right-hand-mouse-user key config. Also, I also think it is a rather large portion of the entire feature; It is better to break things down into smaller chunks that someone can implement and test. Otherwise, it will be a daunting mountain for them to climb all at once.

I suspect that StdBoxElementSelection was working on Sept 07, 2019 when the wiki page was created. Maybe it broke because of the Big Merge? (That's just a guess, I really don't know.)

That inconsistency will have to be handled during implementation due my stipulation as such in version 2 of the pre-FR.

StdBoxSelection (Shift + b) will select an entire object if the Bounding Box covers about half or more of the object. I tested this only briefly using the default Part WB > Cube and Part WB > Cylinder using the FC 0.19 version below.

Good catch. I'll also update the pre-FR to address that inconsistency, specifically because if the user has "eXclude" mode enabled, then dragging the Bounding Box over only half of a Part WB > Cube should not select the entire cube, but "include" mode would select the Cube.

So, I will revise the pre-FR for the above and I will post a new comment when done, eventually. But, before I do, I will wait to give you a chance to comment on the above.

Thanks, and my apologies for this delayed reply.

No worries at all; it gave the other folks a chance to weigh in, and gave me time to absorb their inputs into the pre-FR.

[bgoodr]

I've revised the pre-FR to Version 3. See the Revision History section at the bottom. I added a mockup drawing of one option for close integration with the Selection View.

[chrisb]

Sorry for not bringing this up earlier, but I tend to forget these: Is it necessary to consider different MouseModels? I use Gesture, and it all sounds reasonable. Users of different models may comment.

[openBrain]

But in order to do that, I want to use terminology that is well-documented. You have used the word "filter". Is "filter" a term that users know about already?

At least this is used in the commercial ECAD software I know. But I don't know in which extent this is a widely used term.

I searched the wiki and came up empty, so I'm suspecting it is low-level implementation detail of how selection objects are "filtered" (e.g., coding internals for selecting vertices and not other entities), and not a term that non-programmer users need to know about.

What I pointed out is ATM definitely a low-level function used by feature developers to limit objects that are selectable by users. I just linked to that because it may be good implementation way to just bring this to the user with a friendly interface (rather than coding a function from scratch).

[chrisb]

To me using "Filter" in this context was a bit strange, but understandable.

[bgoodr]

Before I respond to the current posts, needed to do some cleanup of a pre-FR boo-boo I left in Version 3 of the pre-FR, revising it to Version 4:

If the Selection View was triggered to be shown when it was not already made visible by the user, unshow the Selection View when the command ends. They didn't ask for it, so don't leave it hanging around to consume screen real-estate.

And, if the box command is going to show its controls all within that Selection View, then only do it when the command is active, and no where else, because it represents key bindings and drop down boxes that are specific to the box command modalities, and not for non-box-selection.

[bgoodr]

Sorry for not bringing this up earlier, but I tend to forget these ...

No need to apologize and thanks for bringing this up.

... Is it necessary to consider different MouseModels? I use Gesture, and it all sounds reasonable. Users of different models may comment.

I gave this considerable over-thinking (what's new?) as a direct result of trying to resolve the conflict between the two warring factions in my mind.

So there are for and against notions to grapple with:

"No":

The "current left-to-right and right-to-left Box Selection behavior" is already controlled by the specific box command (e.g., Std BoxSelection), and should continue to ignore the users chosen Mouse Model in that mode, because if we change it now, it will frustrate users who have developed muscle memory from those commands.

"No":

The modal behavior of those pre-FR-specified box selection commands has to be kept modal to allow for those pre-FR-specified, box-command-specific, key bindings that toggle things on and off or switch "submodes". That modal behavior has to be such to avoid conflicting with global shortcuts to select those submodes. And those "submode" key bindings have to be there to be single key clicks, not modified-key-bindings like Shift-b to start the whole commands (has to be in order to avoid conflict with other global short cuts).

"Yes":

Certain mouse models like Mouse_Model#CAD_Navigation, do reference specifically how multiple objects can be selected:

Code: Select all

Holding down Ctrl allows the selection of multiple objects.

The "current left-to-right and right-to-left Box Selection behavior" is currently controlled by the specific box command (e.g., Std BoxSelection), but should not have done so. Doing so ignored the users chosen Mouse Model. That implies that the current box commands are over-specified by controlling something they should not have. And it means that the Mouse Models are under-specified by not addressing multi-object selection needs that were always present: The Mouse Model has models that only offer [1] the CTRL key to select individual objects with down/up left-mouse-clicks with no time-budget given to implementing rectangle, lasso, or stroke approaches, which is the key aspect that the pre-FR is trying to rectify inside the "private world" of the box commands.

"Reconcilation":

One option I considered to deal with the above would be to relocate the behavior for all mouse models into the Mouse Model to make the Exclude/Include behavior global, and not coded redundantly in each box-command. Not sure about what the effects would be: Do left-handed users naturally select groups of objects in non-box-selection use-cases from right-to-left whereas right-handed users tend to always stroke from left-to-right? I don't know for all FreeCAD users, but I have one data point from a non-FreeCAD user: My wife. She is left-handed and said that she already uses the mouse from her right hand because years ago she didn't know there was an option to change it, so it became habituated. If that means that most left-handed folks use right-handed mice, then my hand-wringing over left versus right handers is unwarranted.

Doing so open up some possibilities for improvement, because the "left-to-right" and "right-to-left" motions are only two of 4 rectangle mouse gestures available to us:

1. Upper-left-to-bottom-right -- What I interpret "left-to-right" to mean in the wiki
2. Bottom-right-to-upper-left -- What I interpret "right-to-left" to mean in the wiki
3. Upper-right-to-lower-left -- Is it a no-op or one of the first two above?
4. Bottom-left-to-upper-right -- Is it a no-op or one of the first two above?

"Slimy Side-step":

Add to pre-FR to require a documentation change: Add a cross-reference to all places in the Mouse Model referring to "selection of multiple objects" to say "See also Box Commands for multi-object selection modes", and then spawn a new Box Commands page that has all three of our box commands grouped together since now they will be tied at the hip internally anyhow as specified by the pre-FR.

"Conclusion":

Unless I'm not seeing just how "Reconciliation" is acheivable without user disruption, that probably means that the first "No" above is probably the route to take to avoid frustrating users to introduce a feature that it is not yet clear is of wider utility.

[1] Maybe not true, I didn't read the entire wiki page for other ways if they exist.