On Feb 20, 2008 5:24 AM, Sven Neumann <sven@xxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxx > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
