App::Part question

Discussion about the development of the Assembly workbench.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: App::Part question

Post by DeepSOIC »

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...
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
Posts: 176
Joined: Thu Oct 30, 2014 10:38 pm

Re: App::Part question

Post by Fat-Zer »

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 :)
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... =)
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.
thanks for that... but I believe there won't be a lot of question till the bug fixing stage...

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;
}
User avatar
jriegel
Founder
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: App::Part question

Post by jriegel »

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...
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".
Stop whining - start coding!
Fat-Zer
Posts: 176
Joined: Thu Oct 30, 2014 10:38 pm

Re: App::Part question

Post by Fat-Zer »

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".
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...
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?
User avatar
jriegel
Founder
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: App::Part question

Post by jriegel »

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!
Stop whining - start coding!
Fat-Zer
Posts: 176
Joined: Thu Oct 30, 2014 10:38 pm

Re: App::Part question

Post by Fat-Zer »

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...
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...
Fat-Zer wrote:Relatively small enhancements/code unifications to Plane/Line view providers.
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...
As a bonus OriginFeatures are now colorable and may be [semi]transparent...
ickby wrote:Rename App::Line → App::Axis
moved down and may be canceled...
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...
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...
User avatar
jriegel
Founder
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: App::Part question

Post by jriegel »

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...
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.

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!
Fat-Zer
Posts: 176
Joined: Thu Oct 30, 2014 10:38 pm

Re: App::Part question

Post by Fat-Zer »

jriegel 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.
Don't quite understood what you mean... the current situation is next... There are 2 API's
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);
It's obviously wasn't finished: no drag methods, allowDrop () doesn't getting called at all and other draw backs...
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...
User avatar
jriegel
Founder
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: App::Part question

Post by jriegel »

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..
Stop whining - start coding!
Fat-Zer
Posts: 176
Joined: Thu Oct 30, 2014 10:38 pm

Re: App::Part question

Post by Fat-Zer »

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..
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)...
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?
Post Reply