issues with the new Std UserEditMode

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!
Post Reply
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

issues with the new Std UserEditMode

Post by uwestoehr »

I tested out the new
https://wiki.freecadweb.org/Std_UserEditMode
feature.

As I understood it, I can for example set the edit mode to Color and when I then double-click on an object, the color dialog appears.

This doesn't work for me:
- create a body and add an additive box to it (using PartDesign)
- set the edit mode to Color and double-click on the box
result: the box is opened in normal edit mode

Another example:
- create a body
- set the edit mode to Transform and double-click on the body
result: the transform dialog is not shown

It seems that only PartDesign is affected. For Part the feature works. openBrain, could you please have a look?

openBrain wrote: .
openBrain
Veteran
Posts: 9034
Joined: Fri Nov 09, 2018 5:38 pm
Contact:

Re: issues with the new Std UserEditMode

Post by openBrain »

Will have a look.
For the 2nd example (Body), I think there isn't much to do as double click is caught by the class to be used as "Make active" whatever is the edit mode. We can eventually discuss to change this, but need to find an agreement on new behavior.
For 1st example (and in general), notice that the PR just changed the way the 'Edit' of the classes is called, but not the classes themselves. However IIRC we discussed with @wmayer in another thread of some special handling of editing in some classes (to handle transactions) and maybe that breaks user edit mode.
Also remember that user edit mode didn't add any new abilities to objects, it just supports edit modes that were already implemented.
In case someone else want to have a look, from a code point of view, user edit mode will ATM work only if edition is called with 'FCMD_SET_EDIT' macro.
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

Re: issues with the new Std UserEditMode

Post by uwestoehr »

openBrain wrote: Tue Oct 26, 2021 5:08 am For the 2nd example (Body), I think there isn't much to do as double click is caught by the class to be used as "Make active" whatever is the edit mode.
I see. Since Bodies are a main object, maybe there should be a note in the Wiki, that Bodies are not affected by UserEditMode.

openBrain wrote: Tue Oct 26, 2021 5:08 am Also remember that user edit mode didn't add any new abilities to objects, it just supports edit modes that were already implemented.
I reported this case since the PartDesign primitives have the same coloring feature than the Part primitives. Therefore when using UserEditMode with Color mode on a Part primitive should give the same result than with a PartDesign primitive.
openBrain
Veteran
Posts: 9034
Joined: Fri Nov 09, 2018 5:38 pm
Contact:

Re: issues with the new Std UserEditMode

Post by openBrain »

uwestoehr wrote: Tue Oct 26, 2021 11:19 am I reported this case since the PartDesign primitives have the same coloring feature than the Part primitives. Therefore when using UserEditMode with Color mode on a Part primitive should give the same result than with a PartDesign primitive.
You were right to report in any case.
OK, I had a deeper look and ... it's a mess. PartDesign ViewProviders are implemented in much different & inconsistent ways that will make working on it pretty difficult. There also are things that I can figure out the purpose, so I can't ATM be sure of a solution proposal.

Regarding inconsistencies, you can see them first from the editing behavior (in following lines 'Box' is a PartDesign additive cube primitive) :
* If you double click a PartDesign feature inside a non-active Body, the latter will become active for example with Loft or Sweep, but not with Pad or Box
* If you have a Box inside a non-active Body and copy then paste it (will paste out of the Body), then finally double-click on it, it will reject editing but the Body will become active if the document has a single Body, not if 2 or more
* If you save the file above and reopen it, you won't be warned about the lamous document structure if you edit the Box. But if you edit for example a Loft that is also there, it will prompt you to propose structure migration

You can also see them in the undo stack management :
* If you edit a Pad or Box, you'll see a transaction called 'Edit OBJECTNAME' but if you edit a Loft for example, you'll just see a laconic 'Edit', because on the latter case non Command is open but it's generated only by the AutoTransaction system

Enough boring details for now. Now the things I can't figure out. Will ping @wmayer and @abdullah because I think they have a good knowledge of that, but anybody feel free to answer :
abdullah wrote:
wmayer wrote:
Some questions you may be able to answer that can help me figure out some things :

1) Is that possible to disable AutoTransaction with some parameter switch or other ?

2) I can't understand what exactly means the doc string of FCMD_SET_EDIT. Could you clarify what makes it special to "Edit the object using the active document" allowing "in-place editing". What special behavior/capability it brings compared to other editing methods ?

3) On these lines of Utils.cpp, 'setEdit' makes different cases whether the edited feature is inside the active or a non-active Body. Roughly, it will respectively generate "DOCUMENT.setEdit('BODY', 0, '.FEATURE')" or "DOCUMENT.setEdit('BODY.FEATURE', 0, '')". As far as I could test, I see no functional difference between both. Would you know why these 2 cases are processed differently ?

4) On the same block, the last line uses 'Gui::cmdGuiDocument' to run the edit command. Do you see reasons why it could harmful to use 'FCMD_SET_EDIT' instead ?

Thanks.
openBrain
Veteran
Posts: 9034
Joined: Fri Nov 09, 2018 5:38 pm
Contact:

Re: issues with the new Std UserEditMode

Post by openBrain »

uwestoehr wrote: Mon Oct 25, 2021 8:06 pm It seems that only PartDesign is affected. For Part the feature works. openBrain, could you please have a look?
https://github.com/FreeCAD/FreeCAD/pull/5201

This highlights/reveals some issues on PartDesign object but these aren't regression caused by the PR. Will open dedicated topic(s).
Last edited by openBrain on Fri Nov 26, 2021 8:37 am, edited 1 time in total.
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

Re: issues with the new Std UserEditMode

Post by uwestoehr »

openBrain wrote: Thu Nov 25, 2021 2:25 pm https://github.com/FreeCAD/FreeCAD/pull/5201

This highlights/reveals some issues on PartDesign object but these aren't regression caused by the PR. Will open dedicated topic(s).
Tanks. However can you please split the PR in two PRs, one for the GUI part and one for the PD fix? This is easier to backport and also better to keep the overview.
openBrain
Veteran
Posts: 9034
Joined: Fri Nov 09, 2018 5:38 pm
Contact:

Re: issues with the new Std UserEditMode

Post by openBrain »

uwestoehr wrote: Thu Nov 25, 2021 8:11 pm Tanks. However can you please split the PR in two PRs, one for the GUI part and one for the PD fix? This is easier to backport and also better to keep the overview.
I closed the PR because I mixed things up. Will submit again appropriately on tomorrow. ;)
openBrain
Veteran
Posts: 9034
Joined: Fri Nov 09, 2018 5:38 pm
Contact:

Re: issues with the new Std UserEditMode

Post by openBrain »

uwestoehr wrote: Thu Nov 25, 2021 8:11 pm Tanks. However can you please split the PR in two PRs, one for the GUI part and one for the PD fix? This is easier to backport and also better to keep the overview.
https://github.com/FreeCAD/FreeCAD/pull/5204
Post Reply