uwestoehr wrote: ↑Sun Jan 09, 2022 11:25 pm
If it is that unsatisfactory, why was this never changed?
do you really need to ask this? How many hundreds of unsatisfactory UX/UI or features we have that have been left there for ages? Reason is simple, nobody stepped up to change it. How often do we even see people working to improve Part wb? I personally would rather work on PD and even the stuff I found unsatisfactory there have turned out hard for me to successfully improve (I've been sitting for more than a year on incomplete and now conflicting code to get variable radius fillets on PD in a satisfactory state)
As it is you need for every drafted pad a loft, meaning two sketches, adjust them etc.
unrelated to the current discussion really but: wouldn't it be enough to make a pad an then a draft feature? not half as complicated I think.
And when you read this thread, you noticed that support for nested structures is in development but this will affect 2 workbenches and requires some deep code work.
and as I said, I'm very grateful for this, my deepest thanks to you for all the work you are doing as I'm seeing improvements all the time while lurking here.
Please join the team to code this.
Oh I would love to, Iv'e been dying to get coding for months now but I'm so chronically short on time right now (at least with codingworthy brain capacity if you understand me)
This should for good reasons done in 2 further steps, one for Part, one for PartDesign.
Wouldn't then a better approach be to improve in Part first then you can copy paste it as is into PD? I'm not an absolutist so I wouldn't really complain if you merge this into master but understand that silently ignoring wires is terrible UX, at the bare minimum there should be a warning of not supporting inner wires when the user tries to pad a profile that has them. (forgive me if this is already the case since right now I'm just running off of what has been commented here).
On the other hand isn't the purpose of making PRs to get feedback and polish a feature before merging? Why do the improvements that may come from the feedback need to come in a second PR? What happens if the version that doesn't support inner wires is released as stable and then we have a version that deals with inner wires but an unnecessary mode that ignores inner wires would have to be kept for backwards compatibility. (I know this is not critical but why go looking for that kind of trouble?)