Path Workbench Repairing an Operation Moved Out of the Job

[freman]

Anyone know where the comboview is defined. It's common to different WBs so I guess it's higher than Mod/Path but I can't find any pertinent .ui files.

Seems the place to start.

[Paula]

Anyone know where the comboview is defined. It's common to different WBs so I guess it's higher than Mod/Path but I can't find any pertinent .ui files.

Seems the place to start.

A quick look at the code suggests src/Gui/ComboView.cpp. You probably wouldn't use a .ui for things like that.

[freman]

many thanks, I was misleading myself with silly assumptions.

Tree.cpp :

Code: Select all

TreeWidget::TreeWidget(const char *name, QWidget* parent)
    : QTreeWidget(parent), SelectionObserver(true,0), contextItem(0)
    , searchObject(0), searchDoc(0), searchContextDoc(0)
    , editingItem(0), currentDocItem(0)
    , myName(name)
{
    Instances.insert(this);
    if(!_LastSelectedTreeWidget)
        _LastSelectedTreeWidget = this;

    this->setDragEnabled(true);
    this->setAcceptDrops(true);
    

Maybe that can be set false in Path WB.

I still think making it work would be the right thing to do.

[Paula]

Maybe that can be set false in Path WB.

I still think making it work would be the right thing to do.

It might not be as much fun as you imagine. Looking at the structure of a FreeCAD window on the screen, I think there's only going to be one TreeView object for each FreeCAD window and it'll also contain objects from the other workbenches you've used so it''ll also disable D&D there too. Really though I think you should be finding and fixing the actual bug(s) rather than considering dirty hacks like disabling D&D.

[freman]

Currently there is NO intended software path behind the drag and drop actions so disabling it in the UI is RIGHT thing to do, not a "dirty hack".

The result of a DnD in Path WB is totally arbitrary and unplanned and is having very destructive results. Obviously the correct solution is to disable it if possible.

The best solution would be to add the software so that a drag option did something useful like re-ordering Operations and that drop targets were checked to see whether a drop made sense and cleanly exit if not.

Part of the problem is that the report window is not showing the call stack when these errors occur, so it's going to take quite some picking to work back to where this broken execution path originates. I don't have the time to commit to that.

A short term solution is to stop this trashing people's work by disabling unsupported DnD actions.

[chrisb]

Currently there is NO intended software path behind the drag and drop actions so disabling it in the UI is RIGHT thing to do, not a "dirty hack".

The result of a DnD in Path WB is totally arbitrary and unplanned and is having very destructive results. Obviously the correct solution is to disable it if possible.

Of course it is the right way to disable it, nobody denies this. But currently the place where this should be done is - so my guess - far far away from anything Path related. That could make a quick fix a dirty hack, where it should better be be controlled by Path workbench itself, and not by something outside.

[freman]

this should be done is... far far away from anything Path related ... it should better be be controlled by Path workbench itself, and not by something outside.

Sorry, I'm not following what way you think this should go.

By pointing to the code in TreeView.cpp I was highlighting the existence of the relevant function, not suggesting a change was needed in that file.

One approach would be turn off DnD in the comboView when PathWB is activated and restore it afterwards.

If there are working instances of DnD in Path that are worth preserving, then there needs to be some checking of the drop mechanism to abort cleanly if the drag source or target is inside a job object.

Currently there are multiple things getting called in PathJob.py which assume a group object exists without testing for its existence. This probably means they are getting called needlessly and it needs to be walked up call stack to fix it, or disable DnD at some level.

[chrisb]

One approach would be turn off DnD in the comboView when PathWB is activated and restore it afterwards.

That doesn't help. You could drag the operations as shown in my example above independently from the active workbench.

[freman]

Ah, of course. So there needs to be some checking in the on-drop event.

Does DnD work correctly elsewhere in FC or this part of a broader issue?

[chrisb]

Does DnD work correctly elsewhere in FC or this part of a broader issue?

Both. It works correctly e.g. when dragging sketches in and out of bodies. It works correctly when dragging arbitrary things in and out of groups or Part containers.
It doesn't work in TechDraw.