App::Part question

[jriegel]

* Undo can not circumvented, if the programmer do not open a transaction the changes will appended to the open one or a anonymous transaction will be created automatic.
* QPoint: you need it to determine the hit Item in the tree, then you need it... And for opening a context menu (see last point)
* ViewProviderDocumentObject is the first regarded to the whole document stuff. ViewProvider is a base class for other use cases the document and tree.
* On dragg and drop you have often different modes determined by the mouse buttons and/or keys. E.g. Windows Explorer. Dragging with right mouse button open context menu. Left button with Shift do copy, with Ctr. do move....

[Fat-Zer]

* Undo can not circumvented, if the programmer do not open a transaction the changes will appended to the open one or a anonymous transaction will be created automatic.

yes it's minor, but in this case transaction won't receive a special name... and in general it's not good to call both API's, but this one is easy to overcome...

* ViewProviderDocumentObject is the first regarded to the whole document stuff. ViewProvider is a base class for other use cases the document and tree.

may be so, just to be sure, will this allow to process drops to a Document entry in the tree?

* QPoint: you need it to determine the hit Item in the tree, then you need it... And for opening a context menu (see last point)

To determine the hit item in the tree is the job of the TreeView... It's pased to a vp via this (for drop)
Context menu is a good one, but IMHO it's better to leave it to vp's to determine it via the mouse position... also now it seems the point is in the widget's coordinates rather than the global one...

* On dragg and drop you have often different modes determined by the mouse buttons and/or keys. E.g. Windows Explorer. Dragging with right mouse button open context menu. Left button with Shift do copy, with Ctr. do move....

ok, agree to this one...

[jriegel]

Ok, leave the QPoint out of the interface, I will maybe add later a 3D point for drops in the 3dView on special geometry (represented by a ViewProviderGeometricObject) which have to be handled differently anyway...

Use ViewProvider or VPDocumentObject as you wish.

[Fat-Zer]

I'm ready enough to merge with other people workarounds...
https://github.com/Fat-Zer/FreeCAD_sf_m ... aseFeature
Branch name: AMM-bodyBaseFeature

Major changes:

• Parts are now DocumentGroup subclass with chain of intermediate classes with specific responsibility
• Body have it's own origin now
• Datum view providers reviewed and reworked

Unfinished so far:

• Workflow selection.
• Migration

What is pending to be done:

• Forbid to create PartDesign features outside of bodies in the new workflow
• Body's View Provider should be improved in several ways.
• Fix drag & drop API see
• Some more code unification in Task dialog classes as well as in view providers
• Some changes to PartDesignGui::ViewProviderDatum
• Lots of bugfixes

Known issues:

• Crash when aborting a primitive or datum dialog
• When creating a part/body planes and axis are not added to their claimChild () list nor to 3d.

Postponed tasks for now:

• Rename App::Line → App::Axis
• Refactoring of PartDesign/Command.cpp

Unlisted bug reports will be appreciated...

ickby, I'm ready to merge/rebase/cherry-pick your workarounds since the rebase.
tanderson69, if any improvements in DAGView since the rebase, I'd like to cherry-pick them too.

[ickby]

Nice work, I think your changes make everything way more stream-lined and logical!

ickby, I'm ready to merge/rebase/cherry-pick your workarounds since the rebase

There are basicly two implementations:

1. a rough porting of Part workbench to the "Part" object (partially unfinished, I did not test the "Group" behaviour yet and there are no real checks if a tool is used with document objects from different parts)
2. A user interface for cross-group references, which allows the user to specify what kind of links he likes. I like this very much, It gives a feeling of what happens to the user and also gives ver much control.

As you have a higher quality standard and more time for the implementations you will msot likely find things to be not perfect, so feel free to adapt the code as wanted.

[Fat-Zer]

1. a rough porting of Part workbench to the "Part" object (partially unfinished, I did not test the "Group" behaviour yet and there are no real checks if a tool is used with document objects from different parts)

To be noted unless we will polish up Part's internal management, I'd suggest to remove command for it creation from the UI... it could be done after the merge and in the assembly branch...

2. A user interface for cross-group references, which allows the user to specify what kind of links he likes. I like this very much, It gives a feeling of what happens to the user and also gives ver much control.

this one is good news... I suppose there should be something like that but haven't found any signs of existence...


khhm... here is the place there you post link to your branch and tell what commit to start with... =)

[tanderson69]

tanderson69, if any improvements in DAGView since the rebase, I'd like to cherry-pick them too.

I think just this one. bce751a8806f31824c39f8ac404d7a974ffa0643

commit.png (18.93 KiB) Viewed 4510 times

[ickby]

The first things I think you have not yet in your branch are fixes, I think it startes here, but not sure exactly:
https://github.com/blobfish/FreeCAD_sf_ ... 3874fb6419

then cross-reference-code comes from
https://github.com/blobfish/FreeCAD_sf_ ... 699084f32d
to (and including):
https://github.com/blobfish/FreeCAD_sf_ ... 91e493f5f9

everything afterwards is Part handling.

[ickby]

Hello Fat-Zer,

how are things going? Did you make any progress on this work recently?

[Fat-Zer]

Hello Fat-Zer,

how are things going? Did you make any progress on this work recently?

was busy a bit last week... have done nearly nothing... will continue on Thursday or Friday...