Don't hesitate PM-ing me (or e-mailing, or whatever) if you have questions on that! I sometimes stop reading the forum.Fat-Zer wrote:Current code contains several bugs (mostly around PartDesign workbench) e.g. Datums attachment is heavily broken... but I haven't a lot focused on them, becouse it will likely be broken again soon...
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!
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: App::Part question
Re: App::Part question
hm... there are some other problems but just readability about that: e.g. the current way of passing context of the command as gazillion parameters to a common code function is inflexible and potentially error-prone... but if you like the current way I will be more gentle with the code... =)ickby wrote:Hehe, remember: just because it is not your style of programming does not automatically make it worse. I find the lambda stuff to be way clearer as any possible object orientated approach, as the code is located where it normally really is, this makes it way simpler to understand what happens! No need for extra functions! Bu twell, I'm one of the few template metaprogramming lovers
thanks for that... but I believe there won't be a lot of question till the bug fixing stage...DeepSOIC wrote:Don't hesitate PM-ing me (or e-mailing, or whatever) if you have questions on that! I sometimes stop reading the forum.
I've got a question about Line/Plane view providers... does somebody understand what the heck is going on in getElement()/getDetail()? what was the intention of returning a "Main"/SoLineDetail? especially the second one looks strange for the plain...
Code: Select all
std::string ViewProviderLine::getElement(const SoDetail* detail) const
{
if (detail) {
if (detail->getTypeId() == SoLineDetail::getClassTypeId()) {
const SoLineDetail* line_detail = static_cast<const SoLineDetail*>(detail);
int edge = line_detail->getLineIndex();
if (edge == 0)
{
return std::string("Main");
}
}
}
return std::string("");
}
SoDetail* ViewProviderLine::getDetail(const char* subelement) const
{
SoLineDetail* detail = 0;
std::string subelem(subelement);
int edge = -1;
if(subelem == "Main") edge = 0;
if(edge >= 0) {
detail = new SoLineDetail();
detail->setPartIndex(edge);
}
return detail;
}
Re: App::Part question
Other then the more complex types in FreeCAD, some of the simpler objects in the document can only be selected as a whole. There the string containing the subelement name is set to "Main", which means basically "there is no subelement selected use the whole thing".I've got a question about Line/Plane view providers... does somebody understand what the heck is going on in getElement()/getDetail()? what was the intention of returning a "Main"/SoLineDetail? especially the second one looks strange for the plain...
Stop whining - start coding!
Re: App::Part question
Yes, sure, but as I can see Main doesn't treated in a special way anywhere, so it just a subdetail with name "Main", like "Face2" on a cube...jriegel wrote: Other then the more complex types in FreeCAD, some of the simpler objects in the document can only be selected as a whole. There the string containing the subelement name is set to "Main", which means basically "there is no subelement selected use the whole thing".
If' so, what's the difference between "Main" and ""?
Why getElement() doesn't always returns Main or empty string?
Is it ok that getDetail () returns new SoLineDetail?
Is it ok that Plane's vp in getElement() also returns a SoLineDetail with index [0]?
What will happen if I select a Plane/Line with Text field?
I suspect it's possible to get rid of SoFCSelection node If I'll fix getElement() and getDetail() but I didn't managed how to do it...
Note that I'm still not into Coin a lot yet...
PS: jriegel, I'm updating your copyrights when I'm editing files Jürgen -> Juergen, because non-utf8-non-ascii symbols are sometimes getting broken, I hope you don't mind a lot about this?
Re: App::Part question
The Detail interface replace the usage of SoFCSelection node and gives you more control. Which kind of (Inventor) Detail shows what kind of string is completely on you. FreeCAD selection is only interested in an Subelement string. The rest is local to the viewProvider...
Sure, replace the name!
Sure, replace the name!
Stop whining - start coding!
Re: App::Part question
Ok, as I can see to handle Highlighting on selection and mouseover in "Detail interface" it must be supported by a coin-level SoNode-derived class (like e.g. SoBrepLineSet), so it doesn't seems like an option here... So we are stuck with SoFCSelection and I'm now ok with it... so I removed all "New" selection model stuff...jriegel wrote:The Detail interface replace the usage of SoFCSelection node and gives you more control. Which kind of (Inventor) Detail shows what kind of string is completely on you. FreeCAD selection is only interested in an Subelement string. The rest is local to the viewProvider...
Done. Took a bit more time than I supposed but now I better understand how coin-related things work... but is still need a review...Fat-Zer wrote:Relatively small enhancements/code unifications to Plane/Line view providers.
As a bonus OriginFeatures are now colorable and may be [semi]transparent...
moved down and may be canceled...ickby wrote:Rename App::Line → App::Axis
jriegel, while you are around, could you remember what was the intention of introduction of the new API? Anything specific or just general enhancement? Have you gonna to add the corresponding API for drag? Is it essential to have the QPoint &pos in the call (I don't see how it could be interpreted in the receiver)... Also I'm unsure if there any sense in Qt::MouseButtons mouseBts during the drop...Fat-Zer wrote:Fix drag & drop API: currently for drop there are two type of API: "old one" with canDropObjects ()/dropObject () and the "new" (unfinished and/or broken) with allowDrop/drop, the second one is more flexible, but unfinished and used only in the assembly...
Re: App::Part question
In the early year we have a selection node before each and every face, line and point. You can imagine this is very efficient. So Werner (I think) came up with the new interface. We used it only on the mass data types so far (BRep, Mesh, FEM-mheses). On objects with less then hundred sub-elements its probably not worth the work.jriegel, while you are around, could you remember what was the intention of introduction of the new API? Anything specific or just general enhancement? Have you gonna to add the corresponding API for drag? Is it essential to have the QPoint &pos in the call (I don't see how it could be interpreted in the receiver)... Also I'm unsure if there any sense in Qt::MouseButtons mouseBts during the drop...
For a drag target its important to know the position of the drop and the mouse button and keys pressed. Imagine you drag a Screw out of a catalog view and drop it on a 3D object. There you maybe want to check of you hit a hole-feature and do the right positioning. Especially in Assembly I want to use drag-and-drop much more.
Stop whining - start coding!
Re: App::Part question
Don't quite understood what you mean... the current situation is next... There are 2 API'sjriegel wrote:For a drag target its important to know the position of the drop and the mouse button and keys pressed. Imagine you drag a Screw out of a catalog view and drop it on a 3D object. There you maybe want to check of you hit a hole-feature and do the right positioning. Especially in Assembly I want to use drag-and-drop much more.
1. The old one from the ViewProvider:
canDragObjects/canDragObject/dragObject/canDropObjects/canDropObject/dropObject
it's excessive, a bit ugly, doesn't support key modifiers objects can be interpreted only one by one, objects don't know if they are getting dragged etc... so I see arguments for changing it
2. The new one started by you in ViewProviderDocumentObject a year and a half ago according to log...
Code: Select all
virtual bool allowDrop(const std::vector<const App::DocumentObject*> &objList,Qt::KeyboardModifiers keys,Qt::MouseButtons mouseBts,const QPoint &pos);
virtual void drop(const std::vector<const App::DocumentObject*> &objList,Qt::KeyboardModifiers keys,Qt::MouseButtons mouseBts,const QPoint &pos);
So I don't see why a VP should need a point in the Tree view on which dropp accrued... also I don't see how it is possible to press different mouse button while drag and drop...
Also I'm intrested if there were any specific issue you were dealing with when you done this...
Re: App::Part question
Ah, I see..
The old interface is used mainly by the Group objects in FreeCAD. The new mimic will be broader but, as you saw already, needs more love. I stopped it till I get more of the basic Assembly stuff done to really use it..
The old interface is used mainly by the Group objects in FreeCAD. The new mimic will be broader but, as you saw already, needs more love. I stopped it till I get more of the basic Assembly stuff done to really use it..
Stop whining - start coding!
Re: App::Part question
Also note that currently both of modes are slightly broken: the old one doesn't open a new command, so it taints the undo stack and if a view provider implements both (like DocumentObjectGroup) it calls both of them, so I'm wondering how to fix them best (at least for now)...jriegel wrote:Ah, I see..
The old interface is used mainly by the Group objects in FreeCAD. The new mimic will be broader but, as you saw already, needs more love. I stopped it till I get more of the basic Assembly stuff done to really use it..
So it would help to decide what to do about that if you could remember answers to some more questions:
Is there any sense of passing QPoint to the drop?
Why you added them to ViewProviderDocumentObject rather than to the ViewProvider?
Is it really helpful to pass mouse buttons?