On Feb 20, 2008 5:24 AM, Sven Neumann <[EMAIL PROTECTED]> wrote:
> Hi,
> On Tue, 2008-02-19 at 12:35 +0100, Daniel Hornung wrote:
> > > Well, perhaps not deprecated in the "don't use this API" sense. Their
> > > use is discouraged. And not by the GTK+ developers but by usability
> > > experts. Tearoff menus might sometimes be useful for the power-user but
> > > for almost all users and almost all use cases they are unnecessary
> > > clutter and make the menu more difficult to use.
> >
> > I have to object here, since I have never seen any user unintentionally use
> > tearoff menus.
> That is not the point. The point is that almost all of the time you
> don't need the tear-off functionality. But it's there, and it is slowing
> you down because you have to move the mouse a little further and your
> eye has to skip the extra visual clutter that it adds.
> > On the other hand I find them very useful, especially with
> > window manager features like window shading and unshade on mouse-over, I use
> > them in my everyday work, not only in GIMP but also in e.g. xmgrace.
> > Benefits I see are easy access to hidden parts of menus that are not used
> > often enough (on the long term average) to deserve a key shortcut (I might
> > need that special sub menu quite a few times only on this very special 
> > image)
> > or for trying out several entries, as was discussed enough earlier in this
> > thread.
> Exactly. This is why GIMP still has them enabled by default. Note that I
> didn't suggest to turn them off. With our deep menu hierarchy, tear-off
> menus are definitely very useful.
> Long term it would be nice if we could get rid of our insane menu
> hierarchies and at that point we should also consider to disable
> tear-off menus.

I think something that would help here is if we could bind keys to
menus. For example, the GIMP-GAP 'video' menu -- it would be more
practical to access this way. And in general, it would be pretty
effective for common tasks, if we could also do things like
defining a custom menu that includes

sel gauss blur
selection to path
path to selection
fill selection with FG

and then bind it to '2', so commonly done tasks were quicker to do and
required less thought. In my experience, it would be useful to be able
to define menus per:

gimp -- ie tasks that are done a lot independent of what the current image is
image -- common tasks for this specific ...image
drawable -- ... drawable
path -- ... path

I'll have a go at making a mockup. My basic idea for this simple sort
of menu editing is DnD based: open the 'gimp' custom menu, creating it
if it doesn't exist, then leave it open in a window like a tearoff,
and DnD menu items into it to add them, out of it to remove them, and
move them in the normal DnD way.

As a whole, I believe this would allow us to leave a lot more out of
the default menus, and have the removed items instead in something
like an actions treeview dockable (using a treeview would  hopefully
allow easy DnD of submenus)

> Sven
> _______________________________________________
> Gimp-developer mailing list
> Gimp-developer@lists.XCF.Berkeley.EDU
> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Gimp-developer mailing list

Reply via email to