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

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Sketcher Tool settings : testers welcome!

Post by abdullah »

paddle wrote: Fri Apr 22, 2022 8:34 am I personally think it would be easier to leave the round corner and frame in the main rectangle tool.
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).
paddle wrote: Fri Apr 22, 2022 8:34 am Because if we split the tools, then what about the case of a round-corner + 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).
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.
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.

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.
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.
I agree that preserving the corner can be a persistent preference. I would blindly enable it a move forward.

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.
paddle wrote: Fri Apr 22, 2022 8:34 am 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.
User input is welcome here.
paddle wrote: Fri Apr 22, 2022 8:51 am 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.
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.
paddle wrote: Fri Apr 22, 2022 8:51 am 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)
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.
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.
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).

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.
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.
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.

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.
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Sketcher Tool settings : testers welcome!

Post by abdullah »

cadcam wrote: Sat Apr 23, 2022 1:43 am...
I do need some more time to process the post. I will come back later.
openBrain wrote:...
chrisb wrote:...
Could I have an honest expert feedback from you?
Haavard
Posts: 217
Joined: Wed Feb 17, 2021 10:48 pm

Re: Sketcher Tool settings : testers welcome!

Post by Haavard »

My thought regarding shortcuts.

My opinion is that as long as shortcuts are customizable (not hardcoded) it does not matter too much at this stage exactly what they are. Hopefully shortcuts will be included in "preference packs" for 0.21, and then anyone can share and test and we can vote for the best "shortcut preference pack" to be the default.

What is important is to try to stick to desktop software standards as much as possible. For example F2 is used to rename, Ctrl is typically used together with a letter to do a command (copy, paste, print, cut), Shift is a modifier key that modifies the function of the pressed key etc..

I also agree with abdullah that it's better to have a shortcut for each command (two point rectangle, center rectangle, rounded center etc) and not shortcuts that modifies the tool widget. The M key (or equivalent shortcut) already does that. And if i press the shortcut for "rounded corner center rectangle" i would expect the tool widget to show up with those settings preloaded.


My thought regarding toolbars.
If the old commands to launch tools is not removed from the code, could the old toolbar be hidden by default, and renamed to "Legacy Sketcher geometries" or something similar, and the new toolbar gets the current name "Sketcher geometries"?

If so, those that do not wish to use the new tool settings widget could just collapse it in the combo view, disable the new toolbar and enable the legacy one. Then the gui and workflow would not change at all. Is that an option?
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Sketcher Tool settings : testers welcome!

Post by abdullah »

Thanks for the feedback.
cadcam wrote: Sat Apr 23, 2022 1:43 am 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
Isn't this what is coded in the testing branch? In the group of rectangle and polygon, when I select polygon then this is appears shown, when I select rectangle, rectangle appears...
cadcam wrote: Sat Apr 23, 2022 1:43 am b) Ability to show user defined short-cuts adjacent to pull down**
Toolbar icons show the short-cut. Unfortunately (as it is the case in master), the dropped down alternatives do not show the short-cut. This should be fixed (also in master).
cadcam wrote: Sat Apr 23, 2022 1:43 am c) Informative tool tips
Tool tips appear.
cadcam wrote: Sat Apr 23, 2022 1:43 am
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
I am not sure I follow.

As for a way to search for new functions, I am not sure you mean a user will look in the toolbar (and in the dropped down icons that appear when the small arrow next to a toolbar icon is clicked), or if you mean going to the menu (Sketch=>"Sketcher Geometries"). I do understand that clicking that hitting 'M' is not practical as a discovery option. I appears to me you want to have all the construction methods also in the toolbar (in the drop down). I am not sure I got it right.

I tend to think that if somebody wants to do a circle, and finds nothing more appropriate in the bar, a circle will be chosen. Then, that somebody will likely look into that widget that just appeared for the option he or she is looking for, so if the user wants a 3 point rim, he will select it with the mouse in the combobox. Then, if he knows that 'M' operates on that combobox and the user wants to use the keyboard, next time 'M' will be used.

That said, it is of course possible to have icons in the toolbar as drop-down for construction methods. But then, drop-downs will be longer.

I think this is an important aspect, i.e. whether we want to debloat the toolbars or bloat them further. I am sure there will be many opposed opinions. Please folks, do not be shy. Give it a run to the testing branch and let us know if you do not feel comfortable with, for example, not having a dedicated drop-down icon for constructing a rectangle by center. Letting us know that the widget is not enough to compensate for its removal. We need to make an informed decision. Feedback is all that we got.
cadcam wrote: Sat Apr 23, 2022 1:43 am 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
Some lessons already learnt from the feedback:
1. I have understood from several feedbacks that 'M' to navigate through combobox and checkboxes is a "no go". This will go in the next testing branch. 'M' will only navigate the construction mode (in rectangle, iterate from center construction and diagonal construction).
2. The tool will also generally not remember how it was used last time. So if the user clicks a rectangle (or uses the regular rectangle shortcut, "G,R"), a regular rectangle it is.

Toolbars have always been customizable. The only key that is currently not customizable (hardcoded) is 'M'. This is a little bit tricky to change ATM. But i have heard the feedback of enabling other functions to take over it, such as a mouse button. This can be a further improvement.

So:
- If icons are to be provided for construction methods in the toolbar, then they need to be assigned a shortcut (or at least a user will be able to). 'M' will continue to work after the tool is activated, to switch between construction methods.
- If icons are not necessary and the UI is simplified, then 'M' after the command will effectively change the construction mode. We can provide additional commands for "options" (such as round corner rectangle) with its own shortcut.
cadcam wrote: Sat Apr 23, 2022 1:43 am 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.......
Duly noted with appreciation.
cadcam wrote: Sat Apr 23, 2022 1:43 am 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?
It is somehow the text string next to the cursor not something in this direction? When I create a line, if I block the x coordinate of the first point to 20mm, the text reflects, when I move the cursor, that x is fixed.

There are advantages to having a floating widget. However, it may get in the middle of using the tool too. It may clutter the view, it is unclear whether a user moves the mouse to enter the widget or to get to an entity in the 3D view... I have given it a thought and did not come up with a good implementation.

I may be possible to change the text string (or add text strings if for any reason they are not there), to help the user.
cadcam wrote: Sat Apr 23, 2022 1:43 am 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
......
Oh... this is a fully new feature on its own. It will not be part of the current effort though. Feel free to create an issue with a feature request.
cadcam wrote: Sat Apr 23, 2022 1:43 am 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?
Ok, so it is not only me that misses the across-flats hexagon (e.g. for making nut inserts in 3d printed objects)... ;)

However, is this applicable for any polygon? What is across-flats in a pentagon?

Do not misunderstand me, I would really like to have something like this for hexagons. I see how to do it when sides are an even number, as there are always two parallel sides. But when sides are an odd number... should it be an apothem instead?

Any further input here?
cadcam wrote: Sat Apr 23, 2022 1:43 am 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]
This is a new feature on its own. It is actually mostly Part Design. The Sketcher can support that feature by adding to the geometry a geometry extension, which acts as an attribute with metadata. If you are interested write an issue for a feature request.
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Sketcher Tool settings : testers welcome!

Post by abdullah »

Haavard wrote: Sat Apr 23, 2022 10:38 am My thought regarding shortcuts.

What is important is to try to stick to desktop software standards as much as possible. For example F2 is used to rename, Ctrl is typically used together with a letter to do a command (copy, paste, print, cut), Shift is a modifier key that modifies the function of the pressed key etc..
While I agree in general terms, during the execution of a tool, I think the keys can be reused in the context that they are being used for a tool. There is one condition for this reuse: that their general meaning is meaningless during tool execution (F2, Ctrl and Shift, in so far as they are not used for sketcher shortcuts, meet this criteria). There is also a strong argument for the reuse. We need keys to interact with the tool. If we try to make the widget as most non-intrusive as possible, and we reserve letters for sketcher shortcuts (except 'M'), then there are no so many keys common to different keyboards used by different computers in most common languages left... Ctrl and shift are precious here.
Haavard wrote: Sat Apr 23, 2022 10:38 am I also agree with abdullah that it's better to have a shortcut for each command (two point rectangle, center rectangle, rounded center etc) and not shortcuts that modifies the tool widget. The M key (or equivalent shortcut) already does that. And if i press the shortcut for "rounded corner center rectangle" i would expect the tool widget to show up with those settings preloaded.
I keep evolving my position with the feedback.

I have hold the position that "options" (not construction methods) should have a shortcut (when meaningful). "options" (generally checkboxes in the widget) is anything that is not a construction method (the top most combobox). The construction method should operate with the 'M'. This means that "rectangle", "rounded rectangle", "frame" and possibly "rounded frame" should have a shortcut. Then, adding a 'M' at the end will allow to switch between diagonal and center construction methods.

With the latest feedback, I am undecided on whether to keep that previous position, or to give up the UI simplification and enable users to have commands for (almost) every combination, including construction methods. I have mentioned the pros and cons above. It is not without pros and cons. I keep listening to ideas.
Haavard wrote: Sat Apr 23, 2022 10:38 am My thought regarding toolbars.
If the old commands to launch tools is not removed from the code, could the old toolbar be hidden by default, and renamed to "Legacy Sketcher geometries" or something similar, and the new toolbar gets the current name "Sketcher geometries"?

If so, those that do not wish to use the new tool settings widget could just collapse it in the combo view, disable the new toolbar and enable the legacy one. Then the gui and workflow would not change at all. Is that an option?
It is an option. I tend to think it is a very bad option. First, it would reflect our incapacity to find synergies and we have been quite good at that in the past. Second, it will segment how we work. We are not talking about some customisable shortcuts. We are talking about a different UI. Third, it means more code to maintain.

I would like to arrive to a situation where everybody wants to see the widget. If not possible, I am ready to provide a preference so that it does not appear at all, or appears collapsed. The widget has a lot of potential. Eventually I forecast that every single user will want it, at least for one tool.

The number of commands should not be a problem. We should have as many commands as wanted by a reasonable user wanting the most commands. Enabling to provide custom shortcuts for specific workflows is important. These commands should generally be present in the menu (not necessarily in the toolbar). All commands need not have a shortcut by default. For example, if using the 'M' modifier at the end is acceptable to change construction method, there may be commands without a shortcut. If a specific user needs to have one of those with a one letter shortcut because it is vital of his/her workflow, then it should be possible to have it so configured.

The toolbar is a contentious topic. However, I think a common default toolbar is very important. Of course, it is always possible to customize (or even run "preference packs"). Still, I value the idea of a default FreeCAD toolbar. Many users do not run customisations. I do not. Newbies usually do not use customisations either, which I guess, it is an advantage for getting help. However, I and the newbies, we do deserve a great toolbar. A great default toolbar should meet the requirements of most users and flatten the learning curve for newbies. We are experimenting with and discussing ideas/concepts, such as "UI simplification", "discoverability of the tools", "UI space management". We might well end up with the same toolbar we had before starting this... but only if we cannot find a better one. I must admit that I am not extraordinarily happy with the polygon tool hiding the rectangle tool due to the current grouping. I understand this gives me extra space in the toolbar. I can certainly live with it. Still, I wonder, if it is the right call. It is quite often used. On the other side, I seldom use the polygon tools, so maybe I would not be put in a situation of having to drop the toolbar icon to get the rectangle tool often. So it may be fine. It is indeed difficult to decide (for me). I have seen no strong complains about this, and that surprises me... Hey folks, what do you think we should do?
cadcam
Posts: 273
Joined: Thu Apr 02, 2020 10:39 am

Re: Sketcher Tool settings : testers welcome!

Post by cadcam »

@Abdullah

Thank you for taking so much time responding to my questions which were perhaps
a little obtuse. Below hopefully some more feedback
Isn't this what is coded in the testing branch?
I was reacting to Paddles demo video
in which I thought he suggested potentially removing the pull-down menu
This should be fixed (also in master).
Agreed!, the only way around, for a none recompiling user, seems to be to wrap the command with a macro with the shortcut in the name.
c) Informative tool tips
Tool tips appear.
agreed, but sometime perhaps also showing how to use the function
would be useful. see more info below
I am not sure I follow.
Again related to the perceived hint that the drop down menus might be removed.
If they were, I assumed the user would have to select the group on the menu
bar, then move across to the widget window and tab/M through the possibilities
to find the correct one. Being able to drag the mouse along the menu bar,
with the drop downs appearing, showing all options, seems a much easier method. With good icons the
user can easily find the one they need and also be prompted to investigate the
functionality of others them may have forgotten/not used before. Especially if
mousing over brings up a informative i.e. >just name, tool tip.
It may be too much to have a large block of info immediately on mouse over, but perhaps plan for a potential future function where initially the function name is shown and then 0.x sec later the use info is added.
But then, drop-downs will be longer.
Not too worried about this, Most users are experienced in absorbing list information and thus can easily run their eye down a series of
related icons to pick the most appropriate. They may even be prompted to use a more appropriate method than the one they are expecting. The eye is amazingly good at picking things like that out of the periphery of vision.
Again may need a master change but being able to cascade another level of pullout
menu might be useful as FC grows. Having similar functions spread across WBs can make finding the most appropriate quite difficult, being able to add perhaps less used functions to the same menu may prompt a user to investigate/try them
M' to navigate through combo box and checkboxes is a "no go"
Agreed, I would guess most people are more used to using TAB in other packages.

customizable (hardcoded) is 'M'
Interesting, in my experimental workbench, [see old version https://www.youtube.com/watch?v=ZrThO5LY1M8]
modifying the line in sketcher is now mapped to L (ine)
I can't remember how I have done that, but given my abilities, it can't have been difficult!
It is somehow the text string next to the cursor not something in this direction?
I some ways I prefer to see the full constraint dimension being shown
or the option to swap between - constraint, floating dimension widget,
nothing.
As noted this saves the user having to refocus all the time, and also comes
from sitting with clients, students etc while adjusting a model and continually having to
give feedback about dimensions. Seeing dimensions appear locally and live as
items are dragged can be very powerful and save a lot of explanation!

[As an aside and I know some people would hate the it so it should be optional, but having a similar function, layout, style when adjusting dimensions in 3D, e.g. pad lenght, pocket depth.
might be nice. Can be very useful when scoping out a design ]
Oh... this is a fully new feature on its own. It will not be part of the current effort though. Feel free to create an issue with a feature request.
Can do, but wondered if it should be included at the base of the polygon icon/widget list of geometries, e.g special most complicated polygons
Across-flats
Agreed primarily related to even sided polygons. But I quite often place an side of a
polygon on an existing line so perhaps give the dimension option perpendicular
to an edge (AF for even polygons). I think apothem on its own might would be a
confusion, but perhaps as an option, e.g. 'diameter', Perpendicular width/AF,
apothem, with the system keeping the last used option as current default.
Hole This is a new feature on its own.
Certainly can put in a feature request if other people think it has some legs.

BW
Haavard
Posts: 217
Joined: Wed Feb 17, 2021 10:48 pm

Re: Sketcher Tool settings : testers welcome!

Post by Haavard »

ppd wrote: Wed Apr 20, 2022 6:30 pm The build: https://github.com/ppd/freecad-ppd/runs ... focus=true

This should appear in about two hours in edge/paddle-widget-testing

It can be installed via

Code: Select all

snap install freecad-ppd --channel edge/paddle-widget-testing
or, if the snap is already installed, switched to by running

Code: Select all

snap refresh freecad-ppd --channel edge/paddle-widget-testing
I tested the snap build last night on Ubuntu 22.04 in a VM, and it works great!

I might have found some more bugs in the tool widget:
Since Auto Constraint is enabled by default, there seems to be a bug in the line tool.
It appears as if the tool widget applies a horizontal constraint if angle is set to 0 or 180, and a vertical constraint if angle is 90 or 270.
However, i think the auto constraint also adds this constraint, so you end up with two:
Peek 2022-04-24 horizontal.gif
Peek 2022-04-24 horizontal.gif (366.94 KiB) Viewed 1434 times


Another detail with the line tool, in mode "2 points":
- There is a small string error, all four says "x/y of 2. point"
- If both points have the same x coordinate, should the tool perhaps only constrain one of the points with a horisontal dimension, and let autoconstraint apply the vertical constraint? And the same for Y/horizontal.
Peek 2022-04-24 two points horizontal.gif
Peek 2022-04-24 two points horizontal.gif (490.23 KiB) Viewed 1434 times
openBrain
Veteran
Posts: 9034
Joined: Fri Nov 09, 2018 5:38 pm
Contact:

Re: Sketcher Tool settings : testers welcome!

Post by openBrain »

abdullah wrote: Sat Apr 23, 2022 8:12 am
openBrain wrote:...
Could I have an honest expert feedback from you?
Honest yes, expert maybe. :) I was offline for a week and need some days to recover daily things.
I'll then compile and give a feedback. ;)
User avatar
paddle
Veteran
Posts: 1390
Joined: Mon Feb 03, 2020 4:47 pm

Re: Sketcher Tool settings : testers welcome!

Post by paddle »

abdullah wrote: Sat Apr 23, 2022 8:00 am 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.
It's true, but I think in most cases there will be only 1 or 2 checkboxes. So there shouldn't be this issue of counting checkboxes. And I think having the same shortcuts for the checkboxes between all tool will be much easier for users to learn. If each tool implement checkboxes with different shortcuts depending on the context (let's say F for frame for instance). Then that will be too much learning.
abdullah wrote: Sat Apr 23, 2022 8:00 am 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.
Oh that makes sens. Then all the snap modes should be put into VP. Because it would also make sens to snap to objects when dragging no?
How does snap to grid behaves when you drag a curve and not a point?
abdullah wrote: Sat Apr 23, 2022 8:00 am 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.

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.
Snapping and autoconstraint shouldn't be incompatible. Snapping only override onSketchPos. So there're no reason for any conflicts with autoconstraints.

The avantage of snapping + autoconstraint vs only autoconstraint is that the geometry are directly created where they should and there is not the akward geometry jump that the solver does when it apply the auto constraint. This jump may move previous geometry which may not be wanted.

Beside the snapping is required for rectangular array, circular array, offset, scale and so on. Because it let you create the geometries precisely where you want.
In current rectangular array the absense of snap is a problem because you can't get a clean array. I mean when you try to make an horizontal array, you actually don't get a horizontal array because the point you selected has not exactly the same Y coordinate as the starting point.
Last edited by paddle on Mon Apr 25, 2022 1:04 pm, edited 1 time in total.
User avatar
paddle
Veteran
Posts: 1390
Joined: Mon Feb 03, 2020 4:47 pm

Re: Sketcher Tool settings : testers welcome!

Post by paddle »

abdullah wrote: Sat Apr 23, 2022 9:28 pm The toolbar is a contentious topic. However, I think a common default toolbar is very important. Of course, it is always possible to customize (or even run "preference packs"). Still, I value the idea of a default FreeCAD toolbar. Many users do not run customisations. I do not. Newbies usually do not use customisations either, which I guess, it is an advantage for getting help. However, I and the newbies, we do deserve a great toolbar. A great default toolbar should meet the requirements of most users and flatten the learning curve for newbies. We are experimenting with and discussing ideas/concepts, such as "UI simplification", "discoverability of the tools", "UI space management". We might well end up with the same toolbar we had before starting this... but only if we cannot find a better one. I must admit that I am not extraordinarily happy with the polygon tool hiding the rectangle tool due to the current grouping. I understand this gives me extra space in the toolbar. I can certainly live with it. Still, I wonder, if it is the right call. It is quite often used. On the other side, I seldom use the polygon tools, so maybe I would not be put in a situation of having to drop the toolbar icon to get the rectangle tool often. So it may be fine. It is indeed difficult to decide (for me). I have seen no strong complains about this, and that surprises me... Hey folks, what do you think we should do?
The tool bar doesn't seem to be so contentious actually. I posted a video to probe user's opinion.
So far the video has 297 view. The poll got 65 answers
Yes : 50 (76%)
No : 4 (6%)
Both Ok : 11 (17%)

Regarding polygon tool being with rectangle, my idea behind that was that we could have all the 'compounded shapes' (ie shapes made of several edges) in this dropdown. So I was thinking that slot and arc-slot could also be in there.
So there would be :
- Rectangle
- Polygon
- Slot
- ArcSlot

Then I was thinking that we could have more of such complex shapes to offer. Like L U H shapes, basic extrusion shapes, gear shapes...
Post Reply