About context menus and select tool

We seem to have multiple of these right click menu’s. I believe
Avogadro’s design goal was to avoid countless menu’s for doing the
same thing. This is why I never added a right click menu although it
might be useful in some cases. The “traditional Avogadro” way would
be to add a new tool with a settings panel. In the settings panel you
select the color and then you click the atom. For the
ChangeAtomRadius tool, a simple click & drag could be used to change
the radius.

Do you prefer countless tools as alternative for countless menus? one
for radius, other for color, another for label. What about other
possible properties?

I think context menu is the best place for setting of per-object
properties. Look, for example, on professional software like Diamond by
Crystal Impact. Maybe it’s not the best example of usability, but IMO
context menu of reasonable length will be more usable than bunch of
tools.

The select rotate tool is not really a place where I would expect to
find these menus.

Select tool is the best place to have such menu, because it gives a
possibility to set properties for selected groups of primitives

Some thoughts:

  1. it’s OK to move right-click menu in separate tool for advanced
    users. But increasing number of tools significantly increases
    usage complexity
  2. IMO it’s not a good idea to separate object setting between many
    tools
  3. we can add a possibility for plugins to add new items into context
    menu so whole menu will be created by plugins which could be disabled
    if desired


Regards,
Konstantin

On Sunday 13 June 2010 10:50:00 Konstantin Tokarev wrote:

We seem to have multiple of these right click menu’s. I believe
Avogadro’s design goal was to avoid countless menu’s for doing the
same thing. This is why I never added a right click menu although it
might be useful in some cases. The “traditional Avogadro” way would
be to add a new tool with a settings panel. In the settings panel you
select the color and then you click the atom. For the
ChangeAtomRadius tool, a simple click & drag could be used to change
the radius.

Do you prefer countless tools as alternative for countless menus? one
for radius, other for color, another for label. What about other
possible properties?

Who are you quoting? Where from? Is there some context a hyperlink or
something might have provided for those wishing to follow the conversation? I
will provide one below,

http://gold.cryos.net:8080/#change,6

We made a design decision early on to avoid the use of context menus
throughout Avogadro. Tim Vandermeersch (whom I believe you partially quoted
without attribution above and below) was making that point.

Tim specifically said in his conclusions in that same comment, "I think these
menu’s should move to their own tool. Can be a tool combining some of these
menu’s. How about a tool with a single menu with submenu’s? We could name it
the expert tool or something. Most of these actions are for advanced users."
This seems to be at odds with your “Do you prefer countless tools as
alternative for countless menus?”, the answer would be no, we prefer focused
tools.

I think context menu is the best place for setting of per-object
properties. Look, for example, on professional software like Diamond by
Crystal Impact. Maybe it’s not the best example of usability, but IMO
context menu of reasonable length will be more usable than bunch of
tools.

This seems to be the dialog that Tim was hoping to open up. Rather than you
doing what you think is best, him doing what he thinks is best and me doing
what I think is best we discuss some overall design features. We might adjust
our previous design decisions, and have chatted about the use of context menus
in Avogadro before. Their overuse tends to make software very difficult to use,
we didn’t just exclude context menus because we couldn’t figure out how to add
them until you arrived…

The select rotate tool is not really a place where I would expect to
find these menus.

Select tool is the best place to have such menu, because it gives a
possibility to set properties for selected groups of primitives

I agree with Tim - you are duplicating features already present in the draw
tool such as cycling through bond orders. You failed to hand undo/redo in this
code while adding a second way to do something. This can lead to an overly
complex GUI that confuses users. If we do want to duplicate features in
multiple tools we should consider why, and if it is justified.

I split out many of the features originally implemented in the navigate tool
because many tools want to perform navigation as a secondary action. I can see
some justification for selecting many atoms and/or bonds and performing some
batch actions, but also wonder if this is best kept in an advanced tool for
users that want a big context menu.

I don’t think the patch as submitted should be merged. This was one of the
aims of using Gerrit, to allow us to consider a little more carefully what
actually goes into Avogadro master. I have already spent a significant amount
of time fixing things things up in master due to changes that should never have
made it in. We have received quite a few compliments on the Avogadro GUI, and
that is because we have put a lot of thought into it. Maybe not everything is
optimal, but I am not willing to see everything possible thrown in just
because it can be. You can write something like Kalzium’s compound viewer
(alternative simplified KDE GUI) if you want to go crazy with context menus.

If you are going to switch from one medium to another it is good form to link
to the other medium if possible, and attribute the comments you are quoting so
we have some idea of who said what and the original context.

Thanks,

Marcus

Do you prefer countless tools as alternative for countless menus? one
for radius, other for color, another for label. What about other
possible properties?

First off, this list is critical. We do want to have polite, useful discussions about features. It’s what we’ve always done, and the results are good so far. The beauty of open source and open communities is that you can get 5-6 intelligent people making suggestions on improving things.

One alternative which neither of you has discussed is what a variety of Mac software does, and what Spartan the commercial software does. Add a context-aware inspector or properties window. Select an atom (or atoms) and the window shows editable properties of the selection. Tim pointed out a similar idea with the project tree diagram.

I generally dislike contextual menus because they aren’t easily “discoverable.” I have a hard time convincing students or “basic users” to right click. So I’d rather have a few more tools, menu commands, or dock windows which are easily discoverable. It’s fine if the functionality in the context menu is available elsewhere (i.e., the context menu is a convenience for some users) but it shouldn’t be the only way to do things. That’s my $0.02.

My concern about sticking a lot of functionality into the select tool is that it doesn’t really fit with the general idea of the tool – select things. That’s why I suggested an “annotation” tool to change labels of atoms, bonds, residues, arbitrary points in space… maybe it can even add arrows or lines to the scene. This has been a general “to do” for quite some time, and I think it should be easy given your code.

As far as custom colors, radius, etc., I’d suggest we consider whether this should go in a general properties/inspector window or the project tree. I can probably make a mock-up in Designer if there’s interest.

-Geoff

Hi,

On Sun, Jun 13, 2010 at 8:29 PM, Geoffrey Hutchison
geoff.hutchison@gmail.com wrote:

Do you prefer countless tools as alternative for countless menus? one
for radius, other for color, another for label. What about other
possible properties?

First off, this list is critical. We do want to have polite, useful discussions about features. It’s what we’ve always done, and the results are good so far. The beauty of open source and open communities is that you can get 5-6 intelligent people making suggestions on improving things.

One alternative which neither of you has discussed is what a variety of Mac software does, and what Spartan the commercial software does. Add a context-aware inspector or properties window. Select an atom (or atoms) and the window shows editable properties of the selection. Tim pointed out a similar idea with the project tree diagram.

I generally dislike contextual menus because they aren’t easily “discoverable.” I have a hard time convincing students or “basic users” to right click. So I’d rather have a few more tools, menu commands, or dock windows which are easily discoverable. It’s fine if the functionality in the context menu is available elsewhere (i.e., the context menu is a convenience for some users) but it shouldn’t be the only way to do things. That’s my $0.02.

My concern about sticking a lot of functionality into the select tool is that it doesn’t really fit with the general idea of the tool – select things. That’s why I suggested an “annotation” tool to change labels of atoms, bonds, residues, arbitrary points in space… maybe it can even add arrows or lines to the scene. This has been a general “to do” for quite some time, and I think it should be easy given your code.

As far as custom colors, radius, etc., I’d suggest we consider whether this should go in a general properties/inspector window or the project tree. I can probably make a mock-up in Designer if there’s interest.

I like the properties window idea. However, I personally don’t have
anything against right-click menu’s as long as they are part of a
greater whole or concept. All I wanted to so is open this up for
discussion. Some of the features you added are great and we should
keep them. It wouldn’t be the first time we redo some gui parts, it’s
just part of the process. If it makes sense to combine the menu’s with
selecting primitives, the select behavior could always be used as
starting point for the new tool.

Tim

-Geoff

ThinkGeek and WIRED’s GeekDad team up for the Ultimate
GeekDad Father’s Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

On Mon, Jun 14, 2010 at 3:14 PM, Tim Vandermeersch
tim.vandermeersch@gmail.com wrote:

Hi,

On Sun, Jun 13, 2010 at 8:29 PM, Geoffrey Hutchison
geoff.hutchison@gmail.com wrote:

Do you prefer countless tools as alternative for countless menus? one
for radius, other for color, another for label. What about other
possible properties?

First off, this list is critical. We do want to have polite, useful discussions about features. It’s what we’ve always done, and the results are good so far. The beauty of open source and open communities is that you can get 5-6 intelligent people making suggestions on improving things.

One alternative which neither of you has discussed is what a variety of Mac software does, and what Spartan the commercial software does. Add a context-aware inspector or properties window. Select an atom (or atoms) and the window shows editable properties of the selection. Tim pointed out a similar idea with the project tree diagram.

I generally dislike contextual menus because they aren’t easily “discoverable.” I have a hard time convincing students or “basic users” to right click. So I’d rather have a few more tools, menu commands, or dock windows which are easily discoverable. It’s fine if the functionality in the context menu is available elsewhere (i.e., the context menu is a convenience for some users) but it shouldn’t be the only way to do things. That’s my $0.02.

My concern about sticking a lot of functionality into the select tool is that it doesn’t really fit with the general idea of the tool – select things. That’s why I suggested an “annotation” tool to change labels of atoms, bonds, residues, arbitrary points in space… maybe it can even add arrows or lines to the scene. This has been a general “to do” for quite some time, and I think it should be easy given your code.

As far as custom colors, radius, etc., I’d suggest we consider whether this should go in a general properties/inspector window or the project tree. I can probably make a mock-up in Designer if there’s interest.

I like the properties window idea. However, I personally don’t have
anything against right-click menu’s as long as they are part of a
greater whole or concept. All I wanted to so is open this up for
discussion. Some of the features you added are great and we should
keep them. It wouldn’t be the first time we redo some gui parts, it’s
just part of the process. If it makes sense to combine the menu’s with
selecting primitives, the select behavior could always be used as
starting point for the new tool.

I also like Konstantin’s 3th idea too. If the context menus are only
provided in separate plugins, users can always enable/disbale them. I
still think redundant features should be avoided unless there is a
context menu or properties window that allows you to change everything
(or everything from the plugins a user has chosen).

Tim

-Geoff

ThinkGeek and WIRED’s GeekDad team up for the Ultimate
GeekDad Father’s Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel