> gg wrote:
> I assume a "tear-off" menu is the context menu I get from a right-mouse
> click. I dont see the gain here, it's actually one click more than using
> the edit menu.
> If I misunderstood, could you explain what a tear-off is?
The menus that you obtain with a right-click have a dotted line across
the top. If you click on that dotted line, a menu window is created with
just that sub-menu. By right-clicking on "Edit" and selecting the dotted
line at the top of the "Edit->Paste As" sub-menu, you will create a menu
dialog that will make the "Paste As New Image" command just a
mouse-click away at all times.
Such tear-offs lose their utility if commands are all clumped together
on a top-level menu. For this reason, I question the wisdom of the GNOME
HIG discouraging nesting of menus (or at least the idea that three
levels is excessive, especially if the menu bar is itself to be
considered a menu).
Your comments on the enhancements and blurs has some merit, I just think
it is important to recognize the development and maintenance process of
the GIMP when making such decision. The different blur methodologies are
different plug-ins and it seems you are suggesting that they be combined
into a generic blur which permits the user to choose different options.
Several difficulties would arise with this consolidation which are best
summarized as discarding the benefits of the entire plug-in approach to
the GIMP's development (division of labor, isolation of bugs,
incremental improvements, the project's "bus factor").
In general, I think the greatest benefit to the GIMP's progression would
be for there to be more of a focus on organizing and simplifying things
from developer's standpoint. There is much more to be gained by
facillitating the task of potential contributors working on innovative
techniques and algorithms than there is from increasing the GIMP's
userbase. "Usability" should not be entirely ignored, but nor should it
come at the cost of "develop-ability".
> my complaint was exactly that , that from one submenu to another the
> submenu can come up left or right which is visually distruptive.
Reading the text of a menu item leaves your eyes at the end of the text.
If the sub-menu appears to the right, your eyes do not have to "jump" at
all -- they are already positioned at the start of the sub-menu's text
(this is a Good Thing).
If the sub-menu appears to the left of the menu, your eyes must "jump"
from the right (end) of the menu text and find the left (start) of the
sub-menu (this is a Bad Thing).
Your suggestion could be viewed as a preference for the consistency of
all Things behaving Badly in the same manner over only having Bad Things
occur when the Good Thing is not feasible. I am not saying that your
suggestion is entirely without merit but you should not be so "apalled"
that others do not share your preference.
> There are no rotate operations on the image menu, all are in a submenu.
I guess we will have to agree to disagree on submenus. I think that the
taxonomic information that is imparted to the commands is valuable
enough to justify the inconvenience of descending into them.
> >> Some anomolies could be looked at, I can free-rotate a layer but not an
> >> image.
> > Erm, you can.
> Can you please clarify what you mean. I look at the Image | Transform
> I only get the simple 90deg and flip options.
> Where do you see rotate image?
You are correct in that it is not on the Image menu and also that
consistency in the menus' appearances might hold some benefit. However,
my own preference would be that consistency in a menu's commands
behavior is more vital.
A week or two ago, I suggested that Arbitrary Rotation be removed from
the Layer menu because it *behaves* anomalously to the other commands on
that menu (it honors the selection while most of the other Layer
commands ignore the selection and operate on the entire layer). Without
such commonality of behavior, the user is forced to memorize (or use
trial-and-error) which commands on the Layers menu honor the selection.
IMO, this the main reason for grouping tools, operations, and commands
into separate categories and should be more rigorously "enforced".
> I would suggest "Enhance contrast" makes more sense as an entry in the
> color menu than an obscure name of the algorithm used. The hint then
> the extra info about what method is applied.
Your suggestion isn't entirely invalid, I just feel that you are being
somewhat solipsistic in wanting to draw the line of what is an "obscure"
term in the field of graphics arts. Perhaps *you* are unfamiliar with
the term (at this point in time) but would you suggest that if *you*
were unfamiliar with the CMYK colorspace (or even RGB, as many newcomers
to the field are), the GIMP developers should cater their terminology to
the limitations of your vocabulary. At what point is the line drawn? My
own preference is to tend towards the wishes of the developer of the
command (Fabien Pelisson), out of respect for his contribution.
"It is amazing what you can accomplish if you do
not care who gets the credit." -- Harry S. Truman
Gimp-developer mailing list