[To be reworked] Sketcher Tool settings : testers welcome!

[paddle]

Also, small detail, but when you select a start point with the mouse, it would be nice if "x of 1st point" and "y of 1st point" would update to the selected point, here it would be 20.00 and 0.00.

Thanks for the bug report.

I don't have the first bug you describe with loosing focus when passing axis. So it's probably on linux side. @Abdullah do you have that too?

Regarding the 'nan' issue, I have it too, it's probably because the angle value is not initialized. Inializing the value to 0 should solve that I guess.

Regarging the 20.00 and 0.00 instead of 20.14 and 0.26, I made a snap feature that will do that that Abdullah will probably add to current branch next.

The general idea is that pressing ctrl triggers the snap-mode. (as it's currently the case for slot tool which snaps vertically and horizontally only.).
When in snap-mode, depending on the tool, you get either 'snap 5 degree' or 'snap to object'. For example line gets 'snap 5 degree', rectangle 'snap to object'.
'Snap 5 degree' will snap the line at an angle rounded by 5degree (so 0, 5, 10...). However in this mode if the mouse is on top of a geometry (point, line...), it will prioritarily snap to that object (ie the mouse position is overriden to be exactly on top of the object).
'Snap to object' only snap to geometry.

I think we'll also add a preference setting 'snap by default' to reverse the effect of pressing ctrl. Meaning that not pressing ctrl would mean snap mode, and pressing ctrl would deactivate snapmode.

[abdullah]

Also, small detail, but when you select a start point with the mouse, it would be nice if "x of 1st point" and "y of 1st point" would update to the selected point, here it would be 20.00 and 0.00.

I don't have the first bug you describe with loosing focus when passing axis. So it's probably on linux side. @Abdullah do you have that too?

No, I do not. The number does not stop being selected:

Peek 21-04-2022 10-59.gif (197.21 KiB) Viewed 1846 times

Code: Select all

OS: Ubuntu 20.04.4 LTS (MATE/mate)
Word size of FreeCAD: 64-bit
Version: 0.20.28697 +119 (Git) AppImage
Build type: Debug
Branch: paddle_widget
Hash: 4e48fafd1d18a1c268d1942ceeb996c51b49ad4f
Python 3.8.10, Qt 5.12.8, Coin 4.0.0, OCC 7.5.2

...

Haavard, what are you pressing exactly when entering the first dimension? Then, are you doing anything else than moving the mouse up and down crossing the horizontal axis?

[abdullah]

But! One major con to merging the tools: This could mess with shortcuts/workflow in a big way.

For some shortcuts, it won't really matter too much. Arc is a great example, as there are only two options. The shortcut for Create Arc remains GA just as it has been. The shortcut for Create Arc from 3 Points would effectively be GAM. A perfectly fine shortcut, just three taps. This will be true as long as every time a tool is selected, the settings begin at some kind of default. Just because I used Arc from 3 Points last doesn't mean that GA should now be Arc from 3 Points. GA should still be Create Arc, and GAM should still be Arc from 3 Points. This is absolutely vital for keyboard muscle memory.

Arc is fine in this regard but rectangle is a different story because there are so many options. I have all three versions of the rectangle tool set to two-key shortcuts. RR (reg rectangle), RF (rectangle filleted), RC (rectangle from center). Two keys each, no modes, no looking over to a widget to confirm my settings are correct. Just tap-tap and then click to place. The amount of times I would have to hit M to get to these on a regular basis (especially for the number of options for rectangles in particular) might just drive me insane. Maybe the separate tools that exist right now can continue to exist at least within the keyboard shortcut customizer. Instead of activating their own separate tool, that shortcut would just launch the new merged tool with that option already selected. If the separate keyboard shortcuts remained an option, then using the most recent mode/settings of a tool would be acceptable. Just as long as there is some infinitely repeatable keyboard-accessible way to get to these specific tools that are being "merged away," I'm cool adapting.

Thank you. This is exactly the reason for this early testing. We need to nail this.

The demonstrator of two tools, a "simpler" one and a more complex one is intended to test the limits of usability. The teachings we take from these will shape the rest of the tools.

I think it is very reasonable to have several independent commands with shortcuts per tool, that would activate the tool with different construction modes (e.g., diagonal corners/center corner) and/or options (e.g, rounded corners, frame). Some may be left out of the toolbar for UI bloating reasons. It would be desirable, if within reason, to have a generally applicable rule to nevertheless restrict the number of commands.

For example, if 'M' (allow me to call it 'M' at this time, configurability for this key is FFS) can be reasonably used to change the combobox mode (as it is the case of the Line; in the case of the rectangle this would be between diagonal corners/center corner). If the checkboxes are provided as commands (for example, RR for normal rectangle, RF for rectangle-fillet, and RT for rectangle-frame), then it would be:
- RR => Rectangle diagonal corners
- RRM => Rectangle center corner
- RF => Rectangle diagonal corners + Fillet
- RFM => Rectangle center corner + Fillet
- RT => Rectangle diagonal corners + frame
- RTM => Rectangle center corner + frame

This would make into the menu (not necessarily the toolbar) three commands RR, RF and RT.

Then, during execution of a single command, as Paddle says, it is possible to keep the settings unless the user changes them manually, until the end of the tool.

The global behaviour is quite interesting. Because the shortcuts are active during tool execution, it would be possible to switch on/off the checkboxes by using the shortcuts above. So if, for example, we do RFM, we can switch to no filleted frame by using RTM.

Sorry, I need to go now. I will post further later on.

[abdullah]

Regarging the 20.00 and 0.00 instead of 20.14 and 0.26, I made a snap feature that will do that that Abdullah will probably add to current branch next.

The snapping functionality will ultimately be added. There are two reasons why it has not been added. The first is that it interferes with the grid snapping of edit mode and there is a need for a good general solution. The second is that adding it would have delayed this user input further.

Several tools use angle snapping and thus there is a need for it.

However, from the screen capture I realise that one autoconstraint is being shown. This alone should make the coordinates shown "snap". In other words, we might need to take into account proposed autoconstraints when updating the widget... something to take into account as further input...

[BrandonGene]

I think it is very reasonable to have several independent commands with shortcuts per tool, that would activate the tool with different construction modes (e.g., diagonal corners/center corner) and/or options (e.g, rounded corners, frame). Some may be left out of the toolbar for UI bloating reasons. It would be desirable, if within reason, to have a generally applicable rule to nevertheless restrict the number of commands.

For example, if 'M' (allow me to call it 'M' at this time, configurability for this key is FFS) can be reasonably used to change the combobox mode (as it is the case of the Line; in the case of the rectangle this would be between diagonal corners/center corner). If the checkboxes are provided as commands (for example, RR for normal rectangle, RF for rectangle-fillet, and RT for rectangle-frame), then it would be:
- RR => Rectangle diagonal corners
- RRM => Rectangle center corner
- RF => Rectangle diagonal corners + Fillet
- RFM => Rectangle center corner + Fillet
- RT => Rectangle diagonal corners + frame
- RTM => Rectangle center corner + frame

This would make into the menu (not necessarily the toolbar) three commands RR, RF and RT.

Then, during execution of a single command, as Paddle says, it is possible to keep the settings unless the user changes them manually, until the end of the tool.

The global behaviour is quite interesting. Because the shortcuts are active during tool execution, it would be possible to switch on/off the checkboxes by using the shortcuts above. So if, for example, we do RFM, we can switch to no filleted frame by using RTM.

Sorry, I need to go now. I will post further later on.

Took two reads to make sure I understood, but I like this proposal quite a lot and it has finally occured to me why after reading it for a third time . In this example, M doesn't actually change the geometry in any way, only the style of construction used (center-to-corner vs corner-to-corner). Is this maybe a good distinction with which to draw some lines?:

If the resulting geometry is different, then it remains a separate tool. If there are multiple ways to construct the same geometry, then they are merged and M cycles between them.

This ends up splitting the difference between merging and not merging. We'd end up with...

Merge:
Arc + Arc by 3 Points
Circle by Center + Circle by Rim Points
Fillet + Constraint-preserving fillet
Rectangle + Rectangle Center-to-Corner
Ellipse by C/MR/P + Ellipse by P/A/MR

Don't merge:
Rectangle with Frame (but do maintain M key for cycling between center-to-corner and corner-to-corner)
Rectangle with Rounded Corners (but do maintain M key for cycling between center-to-corner and corner-to-corner)
Arc of Ellipse, Hyperbola, or Parabola

Unsure:
B-spline / Periodic B-spline (I don't know enough about B-splines to know if these are different geometries)

This also means that the M key only has to cycle between two options in all these instances, which I'm a really big fan of as well. This obviates the need for "hidden" tools that only show up in the keyboard shortcuts or are eliminated from the toolbar, since 3 keys is totally fine for practically everything. Thoughts?

[Haavard]

I don't have the first bug you describe with loosing focus when passing axis. So it's probably on linux side. @Abdullah do you have that too?

No, I do not. The number does not stop being selected:

...

Haavard, what are you pressing exactly when entering the first dimension? Then, are you doing anything else than moving the mouse up and down crossing the horizontal axis?

I set up a VM with ubuntu 20.04 and compiled there to remove fedora and wayland from the equation.

The bug regarding negative numbers not being active remained, but i found the cause of the issue:
- If i set the number format to "Operating system" in Preferences -> General -> Language, i have this issue
- If i set the number format to "Selected language" or "C/POSIX" the bug goes away


The locale settings in my VM is:
Language: EN-US
Keyboard: Norwegian

Code: Select all

OS: Ubuntu 20.04.4 LTS (ubuntu:GNOME/ubuntu-wayland)
Word size of FreeCAD: 64-bit
Version: 0.20.28816 (Git)
Build type: Unknown
Branch: paddle_widget_testing
Hash: 4e48fafd1d18a1c268d1942ceeb996c51b49ad4f
Python 3.8.10, Qt 5.12.8, Coin 4.0.0, OCC 7.3.0
Locale: English/United States (en_US)

[paddle]

Merge:
Arc + Arc by 3 Points
Circle by Center + Circle by Rim Points
Fillet + Constraint-preserving fillet
Rectangle + Rectangle Center-to-Corner
Ellipse by C/MR/P + Ellipse by P/A/MR

Don't merge:
Rectangle with Frame (but do maintain M key for cycling between center-to-corner and corner-to-corner)
Rectangle with Rounded Corners (but do maintain M key for cycling between center-to-corner and corner-to-corner)
Arc of Ellipse, Hyperbola, or Parabola

Unsure:
B-spline / Periodic B-spline (I don't know enough about B-splines to know if these are different geometries)

This also means that the M key only has to cycle between two options in all these instances, which I'm a really big fan of as well. This obviates the need for "hidden" tools that only show up in the keyboard shortcuts or are eliminated from the toolbar, since 3 keys is totally fine for practically everything. Thoughts?

I personally think it would be easier to leave the round corner and frame in the main rectangle tool.
Because if we split the tools, then what about the case of a round-corner + frame?

Regarding the shortcuts for the checkboxes, what about using something consistent between all tools? I think it's the best to make learning shortcuts easy.
It could be :
'F1' to enable/disable first checkbox
'F2' to enable/disable second checkbox
...

Or something like 'Q' 'W' 'E' 'R' or 'Q' 'S' 'D' 'F'. Though that is optimal only for qwerty keyboards. Or we can use S D F G which will be more consistent between keyboard layouts, but it doesn't start at the beginning of the row.

Regarding fillet tool, currently the constructions modes are : fillet and chamfer. Then you have a checkbox to preserve corner (which ideally will be a preference setting, meaning it wouldn't reset, as I guess most user will want to use always one case rather than the other? Though alternatively we could have a fillet tool and a chamfer tool, and have preserve corner as construction mode.

Regarding bspline we haven't tackle it yet. Though I would be in favour of merging them and have construction modes 'Open' and 'Periodic'.
Also bspline could then be in the same dropdown with polyline.

[paddle]

The snapping functionality will ultimately be added. There are two reasons why it has not been added. The first is that it interferes with the grid snapping of edit mode and there is a need for a good general solution. The second is that adding it would have delayed this user input further.

Several tools use angle snapping and thus there is a need for it.

However, from the screen capture I realise that one autoconstraint is being shown. This alone should make the coordinates shown "snap". In other words, we might need to take into account proposed autoconstraints when updating the widget... something to take into account as further input...

Regarding grid snapping, the main question is where the code should be. I think we can just remove it from sketcherViewProvider and put it with the other snapping functionality in the DSH. It's only a matter of reading the 'snap to grid' preference at the beginning of the snap function it should be straight forward.
Then the best behaviour IMO is :
- Don't snap if user isn't holding ctrl.
- If user is holding ctrl, snap to (in order of priority) : objects, grid points (if at 1/5 of grid point), 5 degree (if snap5degree)

And yes we can add it later if it's delaying things. Though I thought it could have been better to integrate it now as we're doing an overall of the DSH, might as well add all the functionalities that we want now. This way the tool can be tested on all the new features at once. Rather than having to come back at testing each tools again after snap is added. Though that's up to you, as you prefer. I don't have a strong opinion on that.

Regarding taking into account auto constraints when updating the widget, I think it's maybe overkill and I'm not sure it's actually beneficial. Because having 20.14 vs 20.00 when snapping, gives a visual feedback that holding ctrl is snapping. So I would rather not have 20.00 when not snapping because of autoconstraints. Besides that might need quite a lot of code to take into account all the cases.

[cadcam]

First can I say that I see this, combined with all the other work going in Sketcher by Abdullah et al,
as amazing for a open source package and really is up with some of the best commercial offerings. Very Impressive!
Very many thanks from a lay user

Some comments/thoughts, mostly related to ergonmoics/speed of use and
ability of the non-expert to find the function they think should exist.

1) Very happy to have tools combined in the tool bar, but RETAIN the pull -down menu with
a) The last tool used shown on the menu bar
b) Ability to show user defined short-cuts adjacent to pull down**
c) Informative tool tips

Many users will predominately use the same function in a pull-down, e.g. centre-radius for a
circle/arc. When they are looking for a different way to construct something similar they
don't want to look for options by 'guessing' the host function and then either

a) Move their mouse to the main function menu to access the pull-down
or
b) Hit 'M' an unknown number of times to choose the function only seeing
each option once at a time.
Very useful if you now the number of presses, but if searching for
a varient very frustrating having to step through again using M
attempting to step

[ There looks like there is reasonable screen real estate associated with the
menu, so is it possible to show an enlarge icon, perhaps highlighting the
associated dimensions]

Nothing is perfect, but being able to brush the mouse along the menubar
and have the drop down menus appear showing the options I believe is a much
quicker way to find the option the users is not sure exists

2) Each user has a different use requirement for a CAD system, e.g one user
may regularily be drawing a couple of polygon shapes as part of their work
and the ability for them to set up a simple hotkey to choose
which on to use is very important. Having to choose a tool -> step
through options (sometime pressing the wrong number of 'M's)
could slow use or become frustrating

** Display of hot-keys in the pull-down should not be hard coded
but be updated by the user denfinitions

3) While it is probably good to use a common hotkey to step through options
it should be user definable. 'M' may not be the easiest for all users to reach
on the keyboard, others may wish to map the function to another special keep
associated to an additional mouse button.......

4) When drawing pulling out a shape the user's concentration can be split to
two sides of the screen, e.g.

1) Mouse pointer to see position relative to existing geometry
2) Absolute value in menu
It would be very nice to have the option to see the numeric values close to the
mouse position to avoid eye movement/refocus. Possibly simply a box with transparency
showing the current numbers and the order in which they are to be entered, e.g.

------------------- --------------
| x: 100.20 | or | r: 34.56 |
| y: 50.34 | ---------------
-------------------
If the user has manually entered a value, e.g. x , it will obviously stay
constant, unless changed in the menu/retyped, and the texted change colour
or highlighted in box?

5) Include a icon on the bar that gives access to special shapes and a
API to enable users to make them to be appear nicely in the new widget, e.g.

- L,C, U, I profiles
- Al extrusions
- Gear, Rack, Single teeth
- Bespoke User profile library
......

6) Primarily related to polygons. Users often swap between diameter and across-flats
dimensioning. Could the option be included in the menu and the last setting remembered
between function uses?

7) Perhaps slightly off topic. Might it be possible to add an option to the circle
function to mark it as a item that is going to become a 'hole' in particular
if it is going to be threaded. possibly with selectable diameters and/or slightly
different colouring. Enabling the correct proportions to be maintained more easily
and potentially allowing for a checking mechanism, that all circle/arcs/datum pts? drawn
in a sketch ready for holes have subsequently be fully defined. [Apologies if this already exists,
I have not found it yet]


BW

[abdullah]

The bug regarding negative numbers not being active remained, but i found the cause of the issue:
- If i set the number format to "Operating system" in Preferences -> General -> Language, i have this issue
- If i set the number format to "Selected language" or "C/POSIX" the bug goes away

I must admit I did not see that one coming...

I am unfamiliar with this setting, but as it affects the focus of widgets, which is unexpected, I would treat this one as a bug.