I’m strongly against combined buttons. They offer nearly nothing useful (all three reasons in czinehuba’s post could told as ‘lets have some room for possible future features’) only burden to find where the heck author hidden that feature i want to use? And why here not there? It could be as an option for people who really like that of course.
Such discussion in my opinion should not be part of FC development at all. Or any other application. It should be concern only for Qt or another user gui developers. FC should only export available features and provide default icons/design for start, and anything else left for user to define. If buttons are combined or not, in what group, in menu or on toolbar or something else - all of that should be done in a common gui library, without coding it into FC itself.
What i am missing here in the discussion, is that are not just dumb “buttons”. These are separate objects with own tasks, different properties, python bindings, … and damn much more. This means, when you want to merge it, you have to rewrite PartDesign almost 100%. You also need to support then old tasks and python bindings (else you would break old files, scripts and addon WBs), which would change, because it will break pretty everything. That is a few man full time job to do that, bedsides all intricacies.
To think, that is just a button and task widget mix, is far from any reality.
I like a Catia-like solution having positive and negative bodies that can be combined taking this state into account (the former adds geometry the latted subtracts), a body can be added ignoring its state (negative ones are treated as positive, too), or it can be removed ignoring its state, too (positive ones also subtract geometry).
The geometry/shape is the same, with just one more boolean property “is negative” to control the “combine” operation.
Both body types could be created with the same tool and this could have two separate buttons and dialogs or a combined one with a toggle.
In such a case I’d prefer a combined button/dialog. (But we don’t want to copy other software… )
What i am missing here in the discussion, is that are not just dumb “buttons”. These are separate objects with own tasks, different properties, python bindings, … and damn much more. This means, when you want to merge it, you have to rewrite PartDesign almost 100%. You also need to support then old tasks and python bindings (else you would break old files, scripts and addon WBs), which would change, because it will break pretty everything. That is a few man full time job to do that, bedsides all intricacies.
Yeah, I also think this is not as simple as it seems. While I initially liked the idea the main I am against it now. The main problem as I see it is: if only the GUI part is changed to support combined actions then there will be significant disconnect between PD actions and resulting items in the model treeview. So this dissonance will certainly not help with overall UX. E.g. one created a negative pad, but this results as a cut in model treeview.
In order to to do this properly one would also have to change the display in the model treeview. This might be doable. The downside is that we will have both approaches shown on the web (blogs, tutorials, …) And this fracture would hurt FC even more. Based on my experience it was really hard getting up to speed on FC using web resources if the web resources were not explicit which FC version was used.
I think that this would be doable as a thin overlay over current FC data model. So there would be still be the issue that UI elements have changed but underlying data model and python code would remain as it is. So there would still be some dissonance present, but only advanced users and developers would be affected by this. And as developers are a rare breed I’d rather not do this
So you are simply ignoring my answer to the question of the thread:
I think all extrusion tools, additive or subtractive, could could be replaced with a single sweep tool using several buttons to launch the tool with different combinations of options and respectively activated widgets in the Task dialog. They all distribute a profile along a spine.
Sweep uses any 2D or 3D curve as a spine.
Extrude/Pad uses a straight line.
Rotate could use a (circular) arc as a spine instead of an axis and angle (optionally).
It could be similar to the rectangle tools in sketcher now; you can use any button to start the creation of a rectangle and then change options to choose a different creation method before you finish the command.
The more I think about it the more I like the idea of a combined tool with “preset options launch buttons” (and keybord short cuts included) which can be hidden. Combining yellow and red buttons is a step in that direction.
Separate tools should be the default option until the combined tools are properly described in the wiki and then we may reconsider the default option, based on practical experience we have gained in the meantime.
I just want to mention that quite similar attempts are made recently within the Sketcher Workbench where new combined tools for constraining will bring huge improvements. Looking forward to 0.22!
By the way. From the video I’ve seen the icon in Sketcher for the combined vertical AND horizontal constraints as a combination of the former 2 separated icons now looks exactly like a PLUS (+). Maybe if they move the lines a little bit out of the center, this confusion could be avoided. Like so:
FreeCAD_Sketcher.png
If anyone could communicate this to the right person?
This could be a completely different tool, a user should customize his toolbars (or some “sane defaults” could be created) to have whatever he like most.
At OCCT level there is probably one function that could be used to do that, that has many options and flags to be set, so probably the tool to be really a “swiss arm knife” should have many buttons and settings, if not it will be another “made by my taste” tool, that recently have appeared in FreeCAD.
Sadly this approach is biased by “usual workflows” that could or could not be representative of the way most FreeCAD users are using.
What is lacks in all these sort of discussion is the “whole view” If you see around there are many requirements, and probably an Arch WB users has “different workflow” from a PartDesign WB user, or a Part WB user, despite each user could produce a good model.
Said that note as example how much users are trying to “push FreeCAD forward”, you could count them probably on the finger of two hands, some of them are old users that could be wrong but have been here to see many “good starts” with innovative things that could be end in a mess.
How much these experts know about what happens behind the curtains of the UI is highly questionable, the fact that a CAD software could do something is heavily dependand on the CAD kernel, and there are not many Open Source CAD kernels around (a recent Cinese effort is concentrating on improving OCCT as it is the only decent “non mesh” Open Source CAD kernel around, this probably is worth something.)
What do you ask? See no question. And when even, as said, these are two different things, even when its source (Body) is the same. Body/Feature building (OP question) vs. Body interaction (what i wanted to note, that is already implemented). Anyway.
Here it is: Combine yellow and red buttons into one tool?
And, yes it is a sensible suggestion to combine tools that do the same. Additive cylinder and Subtractive cylinder create the same cylinder by default, and it would be nice to have only one Cylinder tool with a toggle switch to simply change the cylinder from additive to subtractive.
Agreed. Where is the thread about the whole view? Maybe it can help to make more on point suggestions.
Are there some natural use cases where this would be used?
In every case when you now use either the yellow or the red symbol.
If these two symbols are combined, the meaning is more like ‘apply my sketch in a cylindrical manner’.
In case your sketch overlaps significantly with an existing body it would be set to subtractive by default.
In case there is no overlap or maybe just a relatively small one, the tool would be set to additive.
In case the auto-detection does the opposite of what you want, you simply can swap it to the other by a checkbox.
In early stages of modelling you might want to change the direction of mating geometry of two parts could be helpful to just toggle additive and subtractive adjust some fillets farther down in the tree and the main part is done.
Example: A thingy having an integrated pin for a pulley. The pin seems to be too weak and should be replaced by a separate bolt. Now just switch the additive cylinder of the pin to subtractive adapt some properties and you are ready to fit the bolt.
I know, in such a simple case removing and adding cylinders is no big deal, too…
But is there a “natural use case” for the options of sketcher’s rectangle tool(s)? Why should I want to switch from pointed corners to rounded after I have started the command? I have no idea, but I used it some times nevertheless and it didn’t hurt.
I like the concept of having one complex tool with a dialog that shows active options and hides unused ones along with buttons that launch the same tool but with different options enabled. If the dialog is too confusing hide it. If there are too many buttons build a toolbar with just one of them to launch the tool.
Regarding this topic: An additive/subtractive toggle in the dialogs doesn’t take much space but (optionally) hide some buttons would clean up the tool bar.
Auto-detction included is even better than a toggle alone.
What is your problem? You don’t like it or don’t want to use it, that’s fine. I would like to try such an implementation and decide afterwards if it fits my workflow better than the current one.
If it is too complicated to implement leave it as it is, the are more important things to do. If it’s just a few lines of code and someone has spare time to code it, why not try it? (the toggle to start with - auto-detection seems a bit too much now)
First it must at least stand simple theoretical tasks, before you invest 4000h+ to make a workflow that probably do not work. Minimum example: a disk key in a shaft. When you make a “shape” with a full disk, what is the output? The slit of the key? Or a lump? How it will be determinate? And how to prevent, that in a parameter change it does not swap the boolean result? Now you do it with a normal key. What is now the result? And when the result it not the same as before (boolean is swapped), then why? Is it in any way comprehensible and logical?
As (CAD) technician you want with same determinate workflows reproducible results, no kind of automagic random swapped stuff, else every parameter change or maintenance of a part will be absolute unintuitive and an act of randomness.
)
