@freedman
I'm sympathetic to the idea, in part it is already done that way - some confusion might be in that an abundance of commands are possible to use at most times. Some of course requires a selection first to work, whereas they could work so that if nothing is selected and the command is invoked - a hint of what to do could come up - in a lot of cases this hint is actually there, but it is in the report view, which I do not think is part of the window layout for a fresh install.
One can also notice that several new users needs a hint to understand that the toolbars in the default window layout are often compressed, so they need to be expanded for all buttons to show. It could be an idea to simply change the default toolbar layout so that a typical screen/window size does not have collapsed toolbars (like using one more row for the toolbars).
One could wonder how many new users that are actually aware of the "what's this" button, i.e. the shortcut to the correct place in the wiki.
Considering that of the 2-3 buttons I clicked just to confirm that it was working, one of them had a terrible layout with overlapping text and pictures, and another one was blank - one could suspect that not too many are actually using this feature (for myself I tend to just do the wiki directly, but if the layout was tip-top on the built-in, I think I would in general prefer that one).
Making one of those hooks for enabling/disabling icons in the toolbar is not complicated, and I do not think a specific text file is needed as such, a python dict should be text like enough.
The tricky things start when one would map out all different states (think "is something selected", "what is selected" etc) and their exceptions/conditions in order to make such a list that is truly useful - there will be a lot of things to check to find out how a button should be treated, that logic will need to be nested and divided into different categories.
the fruity way is to guide the path, the other way is to give a slap on the fingers afterwards in form of an info/error message, which hand on the heart can be as effective (at least after a couple of times), but for sure probably nicer for the user with the guiding from the start. The worst way is of course if the program is totally on strike and shares no info before you find that specific magic of buttons or selections that runs a command successfully.
the enabling/disabling of tool bar buttons is not the hard part, here is a hook that will do it.
Code: Select all
from PySide.QtGui import QToolBar, QToolButton
mw = Gui.getMainWindow()
control = {"What's This?": False}
for tb in mw.findChildren(QToolBar):
for btn in tb.findChildren(QToolButton):
print(btn.text(), btn.isEnabled())
if btn.text() in control:
print('should I do something now?')
if not control.get(btn.text()):
btn.setDisabled(True)
print('it is now changed')
Python dicts can easily contain nested structures, like dicts or lists, so any good ideas of how a mapping of what is enabled/disabled could look like?
For the record, I imagine that making info/error messages after the fact is by far the easiest, it comes quite naturally with the coding, it is not hard to put a print statement inside an if statement to inform the user of that particular condition/state, making the same in a dict is basically repeating/reproducing the logic already existing in the code.
Now with all that said, having something like this would probably be great for one set of users, and less great for another set of users.
I put myself into the latter set, simply for the reason that I do not have much trouble to guess what commands are usable and not under which conditions, this is sprung out of a bit of basic knowledge of math and geometry. Simple things like connect 2 points makes a line, to sweep one needs a profile and a path to drag that profile along. If one does not have a decent understanding of some of those basic behaviours in generating different geometrical shapes, it might not be enabled/disabled icons that is the real hurdle, it might just be the understanding of what the basic steps for constructing different geometries and how the tools of the trade (extrude/revolve/sweep/loft) work that is the true hurdle to get over.
(maybe it would be a good idea to make a wiki page for these type of basics for new comers - just throwing it out there...)
most bang for the buck is probably to work on how to guide the individual workflows (for each button or construct), like "how to make it self explanatory in the gui when making a revolve", what is needed? a sketch/closed profile and an axis to revolve around. Is the text there today in the task dialogues good enough, should there be a help button in the task dialogue? If so, should that button be a preference setting for the ones that does not want to see them?
In general I think there are 2 "extreme" categories of learning, one that is going by the philosophy of "click and let's see what happens, there is always undo, either it works or not", another one is "will not click a single button unless I already know what is going to happen and what I need to do to avoid errors". The later one will read a complete book (or several books) without even starting the program.
fc somehow needs to cater for both of these extremes, while at the same time onboarding users that actually do not know the underlying basics that is needed to successfully use a 3d parametric cad-system.
