ickby wrote:What is the hassle with the current implementation and using the "getNextSolid" functions? I think a extra propertie is an rather ugly solution, I would opt for your second method too.
There are two reasons:
First one is about the meaning of the Tip and intention of the body class: as I see it and as sad in the comment to BodyBase the body aggregates some modeling features and provides to outside only one of them, the Tip... For PartDesign It's really confusing IMHO to provide to outside something other but solid...
I've run into some problems implementing the BaseFeature, e.g. for consistency either the getPrevSolid should be able to return the link to it or the tip should be allowed to point to it... but with the first strategy the code became really messed up...
To be noted, I've already nearly done with both, but haven't committed yet... cleaning up some bugs in Gui now...
ickby wrote:Why would a user change the Tip? Is this not a internal property where the (normal) user has no real use for?
IMHO, no... I see at least one use case personally I will appreciate: if the user wants to see what the whole part will look like if he will switch to some previous feature...
Also because of that I proposed to mark it in the tree view...
ickby wrote:I can't look it up now, but does the viewprovider function "getIcon" not return a QIcon, which is a non-scaled Icon?
Yes, the viewprovider's getIcon() a QIcon as non-scaled Icon, and because AFAIK the overlaying of icons is done in raster (without getting deep into QIcon), we shouldn't do it in a viewprovider, if I understand it right...
ickby wrote:For utility stuff I suppose you mean Workbench.cpp? What would be the intend to move it? But I don't see any reason why not.
yes, I'm talking about getBody(), getPart(), migration stuff, body setting up etc which is currently in the Workbench.cpp... I don't yet decided where to move it... may be a separate file CommandUtils.cpp or something like that...