App::Part question
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: App::Part question
* 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....
* 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....
Stop whining - start coding!
Re: App::Part question
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...jriegel wrote:* 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.
may be so, just to be sure, will this allow to process drops to a Document entry in the tree?jriegel wrote:* ViewProviderDocumentObject is the first regarded to the whole document stuff. ViewProvider is a base class for other use cases the document and tree.
To determine the hit item in the tree is the job of the TreeView... It's pased to a vp via this (for drop)jriegel wrote:* 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)
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...
ok, agree to this one...jriegel wrote:* 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....
Re: App::Part question
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.
Use ViewProvider or VPDocumentObject as you wish.
Stop whining - start coding!
Re: App::Part question
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:
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.
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
- Workflow selection.
- Migration
- 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
- 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.
- Rename App::Line → App::Axis
- Refactoring of PartDesign/Command.cpp
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.
Re: App::Part question
Nice work, I think your changes make everything way more stream-lined and logical!
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.
There are basicly two implementations:ickby, I'm ready to merge/rebase/cherry-pick your workarounds since the rebase
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.
Re: App::Part question
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...ickby wrote: 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)
this one is good news... I suppose there should be something like that but haven't found any signs of existence...ickby wrote: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.
khhm... here is the place there you post link to your branch and tell what commit to start with... =)
- tanderson69
- Veteran
- Posts: 1626
- Joined: Thu Feb 18, 2010 1:07 am
Re: App::Part question
Fat-Zer wrote:tanderson69, if any improvements in DAGView since the rebase, I'd like to cherry-pick them too.
I think just this one. bce751a8806f31824c39f8ac404d7a974ffa0643
Re: App::Part question
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.
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.
Re: App::Part question
Hello Fat-Zer,
how are things going? Did you make any progress on this work recently?
how are things going? Did you make any progress on this work recently?
Re: App::Part question
was busy a bit last week... have done nearly nothing... will continue on Thursday or Friday...ickby wrote:Hello Fat-Zer,
how are things going? Did you make any progress on this work recently?