I was not meaning to split the tool (the DSH).
The tool remains exactly what is today. Simply, there are additional commands that initialise the tool differently. If somebody prefers to only remember the shortcut of rectangle (currently, G,R) and then change options by clicking (e.g. to select a rounded frame), I am fine with that. People who currently use the rounded rectangle shortcut (currently, G, O), can continue using that one and then change options (e.g. by clicking in the checkbox of frame).
We need to decide what we want.
If there is a command for round-corner (G, O), then the checkbox of frame should be selected. Alternatively, if we create a command for a frame (currently there is none), a user could use this shortcut and select the rounded corners option.
The previous examples assume that there is not a command for round-corner + frame (or that it does not have a shortcut assigned). While I do not mean it is necessary to always create a command for every combination of "options" (checkboxes), it may actually make sense to do it (in most cases), even if no shortcut is assigned by default (which depends on shortcut availability), so that if there is somebody intensively using rounded frames (and there is no shortcut by default), he or she may assign a shortcut to it.
The idea of providing additional commands (without changing the tool), could be combined with RT's PR about shortcuts, to leverage mnemonics for selection of "options".
RT's PR is directed to improving the combinations possible for shortcuts. Currently, one stroke shortcut "G" prevents from having a two stroke short cut "G,R" starting by "G". The same applies for three stroke shortcuts "G,R,F" preventing to have two stroke shortcuts starting with "G,R". This limitation is lifted in RT's PR (by using time for disambiguation). So it will be possible to have, for example, "G, R" for rectangle and "G,R,R" for rounded corner rectangle, "G, R, F" for frame and "G,R,S" for rounded corner + frame rectangle, despite the fact that the three stroke shortcuts start like the general two stroke shortcut.
Then the shortcut could be a good mnemonic for triggering the right "options". Any later change to the configuration (after the tool has been launched), can leverage the fact that the widget does not inhibit sketcher shortcuts. So, for example, if a user clicked "G,R" and then realised that "G,R,F" would have been better (and he or she does not want to move the mouse to the right checkbox and click it), the user can now directly press "G,R,F", which would effectively activate the frame (or "G,R,S" for a rounded frame).
To have keys assigned for checkboxes is an option. The main drawback is that keys assigned to checkboxes are taken away from the sketcher (while the tool is active), making the widget more intrusive. I do not rule out the possibility, and it will depend on what the community wants, but we need to understand what we lose.paddle wrote: ↑Fri Apr 22, 2022 8:34 am 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 positional shortcuts (the first one keystroke, the second the next to the right, ...), I do not like them much. One needs to count the checkboxes, then think which key to press. They do not rely on mnemonics either.
About the example keys:
- I think that only F1 and F11 are currently taken in FC. I am not quite a fan of this. Some keyboards/computers may not even have them.
- "Q", "W", ... will heavily interfere with normal shortcuts of the sketcher (and the possibility for expanding them in the future). This I would not like.
If we want to leverage mnemonics when the tool is active, we need to end up assigning keys, which makes the widget more intrusive. The only alternative I found to this, is to leverage the shortcut system as indicated above. It has the limitation that once the tool has been activated, changing a checkbox from keyboard is only possible by providing the full shortcut ("G, R, S"). If the tool does not remember previous usage (as we discussed above), it has the further limitation that if "M" was provided to change mode ("G, R + M"), upon typing ("G, R, S"), it will be necessary to press 'M' again. That is basically the trade-off.
I agree that preserving the corner can be a persistent preference. I would blindly enable it a move forward.paddle wrote: ↑Fri Apr 22, 2022 8:34 am 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.
As for whether fillet and chamfer should be considered construction methods or not, I tend to think that they should be kept separated. But I do not have a strong opinion. I think the community should guide us here.
User input is welcome here.
Grid snapping is also used during dragging. I do not think it is acceptable to remove it from the VP and make it specific of the DSH.
My guess is that slightly different behaviour is provided per tool. This general behaviour might not match some tools (carbon copy uses CTRL for other purposes). Then some tools may want a different prioritisation (such as 5degree snap preferred over grid points and objects). I do not have a clear picture ATM. But angle snapping must be considered with the next batch of tools.
For now, I would like to see some more opinions on what is being offered today in this testing branch. I would also like to settle the open questions we have (and are discussing about shortcuts, commands and UI).paddle wrote: ↑Fri Apr 22, 2022 8:51 am 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.
What we are doing is changing quite a lot of different functionality. For this reason I want individual feedback on features. It may take longer, but it should provide a better result.
I will take a look into this. The values provided are visually inaccurate because the point will not ultimately end up there. Snapping should not take priority over autoconstraining. In fact, I think that if a conflict needs to be resolved, autoconstraints should either not be suggested in the first place, and if suggested, if should have higher priority than snapping.paddle wrote: ↑Fri Apr 22, 2022 8:51 am 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.
It may be that I am biased towards an "autoconstraint" directed approach, as opposed to a snapping directed approach. Until now "autoconstraints" have always had priority. This somehow shows that I do not have a clear idea of what snapping should bring to the table yet.