I just added a new feature to extensions. They can now define a “menu
path” – to show up in any menu, create a menu or submenu, etc. You
define this with a string, separated by “>” characters, e.g.
“Tools>Compute>Molecular Mechanics”.
I tried to add some good documentation in extension.h and gave an
example with the Ghemical extension showing up as a submenu. (I also
discovered that to use this properly, the strings need to match the
menu exactly, e.g. “&Tools”.
This should really help organize extensions, since we don’t have to
have all actions in one menu.
At the same time, I’d like to suggest to get rid of the "Settings"
menu. The toolbars and docks are better under “View.” The view menu
already reflects the full screen and background color, so this seems
like a natural fit.
Then the global Avogadro settings can go under “Edit.” Of course I
don’t know if this completely violates the KDE usability guidelines.
I just think the current “Settings” menu isn’t very useful.
Cheers,
-Geoff
On May 25, 2007, at 1:09 PM, Donald Ephraim Curtis wrote:
I think about “View” as directly relating to the “View” of the
molecule,
not the view of the overall application.
I’m not sure other users will see that. In many programs I use,
there’s something like a “View” menu and it also reflects viewing
docks, toolbars, etc. Certainly on the Mac, that’s a common interface
technique.
by the new KDE interface documentation (like you said below). And i
feel
like we don’t necissarily need to follow all their rules and
guidelines
but it’s a good starting point.
Phooey. There’s some benefit to having essentially the same interface
across all platforms (it makes it easy for tutorials and writing lab
notes for students). OTOH, we may have some real problems since KDE,
Windows, and Mac all have different interface conventions.
(I have given passing thought to eventually having a true Mac
frontend using Objective-C, which would make it easier to interface
to libraries like QuickTime. Too far in the future.)
the menuPath() function, but I believe the next step would be to allow
each QAction to give it’s own menu path.
Dunno. I think I’d want to see this in action before I know how it
would feel. I get your point about having settings in the Settings
menu, but I wonder if users would be confused why all the Molecular
Mechanics commands aren’t together. Classification is always
difficult since some things can be in multiple categories. 
I’m just happy because I can now have a “Select” menu and add a few
extensions like “Invert Selection.”
Cheers,
-Geoff
(Fri, May 25, 2007 at 10:13:36AM -0400) Geoffrey Hutchison geoff.hutchison@gmail.com:
I just added a new feature to extensions. They can now define a “menu
path” – to show up in any menu, create a menu or submenu, etc. You
define this with a string, separated by “>” characters, e.g.
“Tools>Compute>Molecular Mechanics”.
I tried to add some good documentation in extension.h and gave an
example with the Ghemical extension showing up as a submenu. (I also
discovered that to use this properly, the strings need to match the
menu exactly, e.g. “&Tools”.
This should really help organize extensions, since we don’t have to
have all actions in one menu.
At the same time, I’d like to suggest to get rid of the “Settings”
menu. The toolbars and docks are better under “View.” The view menu
already reflects the full screen and background color, so this seems
like a natural fit.
I think about “View” as directly relating to the “View” of the molecule,
not the view of the overall application. When toggling docks / toolbars
you’re changing the settings of the application. This is also specified
by the new KDE interface documentation (like you said below). And i feel
like we don’t necissarily need to follow all their rules and guidelines
but it’s a good starting point.
http://wiki.openusability.org/guidelines/index.php/Guidelines:Menus
Then the global Avogadro settings can go under “Edit.” Of course I
don’t know if this completely violates the KDE usability guidelines.
I just think the current “Settings” menu isn’t very useful.
It will get more useful as we develop it more. I like what you did with
the menuPath() function, but I believe the next step would be to allow
each QAction to give it’s own menu path. We can either subclass QAction
we can just embed the menuPath it in the name of the action, which is
the easiest option. This way settings for say the Ghemical plugin can
be placed in the &Settings>Optimization Settings item.
Cheers,
-Geoff
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options