[Poll] Sketcher: Task panel rework.

[openBrain]

How about making the "Close" button in Sketcher panel optional ?

[paddle]

However, the biggest issue is that putting it in the toolbar separates the whole solver related actions from the solver information, which is something at least I wanted to avoid.

Then let's put the solver message in the Sketcher-edit-mode toolbar.
This way the settings button is next to the solver message. The 'exit sketch' is also in the same toolbar.

This way we have a 'powerful' sketcher toolbar. (Unlike the previous one we had with 'edit sketch' 'merge sketch' 'validate'...).

Having a real piloting sketcher toolbar like this would make sense as it would concentrate all the information without relying on the taskview which can be hidden.

The toolbar would be like :

sketcher toolbar.png (15.37 KiB) Viewed 1241 times

The only issue I see is that the solver message width depends context (and language). So it would be annoying if it resize all the time. So it would have to have a fixed length. And we could try to make solver message with approximately the same size.

[abdullah]

How about making the "Close" button in Sketcher panel optional ?

At the end, there appears to be two groups of users, those who want a minimal sketcher and do not care to have to move around to menus or parts of the toolbar to fetch (rarely for some of them) used options, and those who are not so minimalists and who still want to have all solver related functions close to the solver message.

Alternative Compromise 1
How about making the "close" button, the sketcher preferences quick access and some clear way to change the properties, not preferences, properties (auto-redundant, ...) optional, but activated by default?

This way the users that do not care about any of these can tick the "minimal taskview" preference mode and get an extra row freed in the panel, whereas those who actually care, can still have this functionality close to where it belongs.

Actually, this concept can later be developed further, we have people with 14 inches screens and people with 30+ inches gaming screens. It may be possible to provide more features directly available for the latter.

Alternative Compromise 2
In the alternative, we can remove also the update button from the solver message, and offer a minimal, always visible solver area. When this area is entered, the close button and a hidden panel within the taskbox appear, which allows to close the sketcher and select all the options we have now, when the area is left both disappear again. I am not a fan of the disappearing close button (could certainly become a fan of the panel), but it may work as a compromise.

[abdullah]

Then let's put the solver message in the Sketcher-edit-mode toolbar.

+1 for thinking outside the box.

-1 for actually putting the solver message in the toolbar. It does not fall under my definition of "tool", but it is rather edit mode context information.

Actually, we could start thinking of putting the solver message in a different place (around the 3D view or even floating inside the 3D view, not in the toolbar, elsewhere), if we would get rid of the constraint and element widgets. Then we could be done with the taskbar itself. However, I cannot currently conceive the Sketcher without these two widgets. When these two need to stay, then moving the solver message elsewhere has little to no appeal for me.

[openBrain]

Then let's put the solver message in the Sketcher-edit-mode toolbar.

My heartfelt thoughts go to those arranging toolbars vertically.

[abdullah]

@abdullah can you confirm if the update button is equivalent to hitting recompute or if it only triggers a recompute of the sketch?

Hitting the update button executes:
App.ActiveDocument.recompute()
which executes:
doCommand(App,"App.ActiveDocument.recompute()");

According to DocumentPyImp.cpp, this triggers a non-force-recompute of the active document.

Hitting the refresh button executes:
doCommand(Doc,"App.activeDocument().recompute(None,True,True)");

According to DocumentPyImp.cpp, this triggers a forced recompute of the whole document.

There is also an option of checking cyclic dependencies, which is different for those two, basically the first is recompute(None,False,False) and the second(None,True,True). I am not familiar with it:

Code: Select all

   /// Option bit flags used by getDepenencyList()
    enum DependencyOption {
        /// Return topological sorted list
        DepSort = 1,
        /// Do no include object linked by PropertyXLink, as it can handle external link
        DepNoXLinked = 2,
        /// Raise exception on cycles
        DepNoCycle = 4,
    };

So the first does not raise an exception on cycles, and the second does. Not sure what is the exact impact of that.

[pathfinder]

Then let's put the solver message in the Sketcher-edit-mode toolbar.

My heartfelt thoughts go to those arranging toolbars vertically.

+1

Something that wider screens encourage so much that I think it should be the new default.

[paddle]

My heartfelt thoughts go to those arranging toolbars vertically.

+1

Something that wider screens encourage so much that I think it should be the new default.

Indeed I didn't consider that. So not the toolbar then.

[paddle]

@abdullah I came up with a new proposition. We put the things where each of them make sense:

A - Auto update + auto remove redundant : We add a menu to update button directly. This way they cannot be closer to the solver message, and they are exactly where one would look for them.

B - Auto-constraint : In the upcoming new setting button in the constraint widget. It makes a lot of sense that a constraint setting would be there.

C - Avoid redundant auto-constraint : removed from everywhere. If we want to do that later, we can just add it to constraint widget setting button too for now.

D - Rendering order : In the Element widget setting button as a QActionWidget.

I think this would be the best solution because each option is where it make sense / where one would look for it.

Regarding removing the Close button, we can make that a separate discussion, perhaps with a poll as this is strictly a UI decision.

[openBrain]

A - Auto update + auto remove redundant : We add a menu to update button directly. This way they cannot be closer to the solver message, and they are exactly where one would look for them.

'Auto remove redundant' is linked to constraint, so IMO more logical to get it close to 'Auto-constraint'.

Regarding removing the Close button, we can make that a separate discussion, perhaps with a poll as this is strictly a UI decision.

To me just making this an option is the simplest solution.