Re: [Gimp-developer] Re: Akanna Menu patch
On 6/12/05, Sven Neumann <[EMAIL PROTECTED]> wrote: > Nathan Summers <[EMAIL PROTECTED]> writes: > > >> Sorry, but GIMP also doesn't know what language the procedure is > >> written in. Such a framework would first have to be added and I don't > >> see it as particularily useful. > > > > It's a great solution for the real world problem of : > > > > "Run the Foo plugin." > > "I don't have the Foo plugin." > > "Oh crap, what package is it in?" > > I see that problem but the suggested solution doesn't help with it. > What the user really wants to know is how to get that particular > plug-in/script. Telling the user what language it is written in, is > not going to solve that problem. Given that in the Real World, the vast majority of the scripts people have installed came in the same package as the scripting language itself, this solves a major part of the problem. On the other hand, if we are adding a field-of-origin, it's trivial to make it specify not just language but a URL or somesuch for how to get it. Rockwalrus ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Akanna Menu patch
Hi, Nathan Summers <[EMAIL PROTECTED]> writes: >> Sorry, but GIMP also doesn't know what language the procedure is >> written in. Such a framework would first have to be added and I don't >> see it as particularily useful. > > It's a great solution for the real world problem of : > > "Run the Foo plugin." > "I don't have the Foo plugin." > "Oh crap, what package is it in?" I see that problem but the suggested solution doesn't help with it. What the user really wants to know is how to get that particular plug-in/script. Telling the user what language it is written in, is not going to solve that problem. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Akanna Menu patch
On 6/11/05, Sven Neumann <[EMAIL PROTECTED]> wrote: > > Sorry, but GIMP also doesn't know what language the procedure is > written in. Such a framework would first have to be added and I don't > see it as particularily useful. It's a great solution for the real world problem of : "Run the Foo plugin." "I don't have the Foo plugin." "Oh crap, what package is it in?" Rockwalrus ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Akanna Menu patch
Hi, Kevin Cozens <[EMAIL PROTECTED]> writes: > Most users will invoke items from the menu and won't care what carries > out the action (ie. plug-in, or script) so I don't feel the menus > should provide any such information. What would be useful is for the > Procedural Browser to include the menu path as is currently done in > the plug-in browser. The procedure browser is just that, a procedure browser. There is no point in adding a menu path there since a procedure doesn't necessarily have a menu path associated with it. This is functionality that the Menu Browser is supposed to offer. > To provide some indication as to the origin of a plug-in or script > listed in one of the browsers without cluttering the browser window it > could be done via a word (or two?) in brackets at the end of the line > which indcates the type of the entry. After Temporary Procedure or > GIMP Plug-in you could have (in brackets) Core, Perl, Python, > Script-Fu, or Tiny-Fu (for example). For plug-ins written in C adding > a word in brackets at the end could be skipped. It may only be useful > for items registered by scripting plug-ins. Sorry, but GIMP also doesn't know what language the procedure is written in. Such a framework would first have to be added and I don't see it as particularily useful. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[OT] RE: [Gimp-developer] Re: Akanna Menu patch
On Thu, 9 Jun 2005, Phil Lello wrote: > Date: Thu, 9 Jun 2005 00:48:29 +0100 > From: Phil Lello <[EMAIL PROTECTED]> > To: gimp-developer@lists.xcf.berkeley.edu > Subject: RE: [Gimp-developer] Re: Akanna Menu patch > And of course, not everyone has a right mouse button... or do new > Macs have more than one button? Rather than picking on Apple for choosing a single button mouse (which I actually like for reasons not worth going into again) point is not all pen and tablet devices have a convenient equivalent to right click which I think you will agree is more relevant to the gimp. - Alan ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] Re: Akanna Menu patch
> "Joao S. O. Bueno Calligaris" <[EMAIL PROTECTED]> writes: > > > I always saidthat tehere should be some way to identificate a menu > > entry. Not only there will be up to four (C, script-fu, Python-fu, > > tiny-fu) equivalent entries on a row, as you point out - > but I think > > one has the right to know how each menu entry got there. > > > > Today it already happens with stuff like 'filter all layers', > > installed with Gimp-GAP - one can't know where it came from. > > > > People suggested that an icon before menu entries would > cause to much > > hassle to the UI - and I agree. I suggested them that > right-clicking > > on a menu item would bring some information about it. (Like: the > > package where it came from, what language it is written in, > and maybe > > even accept a new shortcut for that item, without having to enable > > "dynamic shortcuts") > > Right-clicking menus is afaik not supported by GTK+ and it > would also be very hard to discover. I'd say the Plug-In > Browser should be rewritten, probably in the core, to become > a Menu Browser. It should be possible to bind it to a > function key that can be invoked with a menu-item focused (as > you can do with F1 to get help). Such a menu browser would > also help to locate menu entries and it could offer a way to > change the keyboard shortcut also. > And of course, not everyone has a right mouse button... or do new Macs have more than one button? ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Akanna Menu patch
Hi, "Joao S. O. Bueno Calligaris" <[EMAIL PROTECTED]> writes: > I always saidthat tehere should be some way to identificate a menu > entry. Not only there will be up to four (C, script-fu, Python-fu, > tiny-fu) equivalent entries on a row, as you point out - but I think > one has the right to know how each menu entry got there. > > Today it already happens with stuff like 'filter all layers', > installed with Gimp-GAP - one can't know where it came from. > > People suggested that an icon before menu entries would cause to much > hassle to the UI - and I agree. I suggested them that right-clicking > on a menu item would bring some information about it. (Like: the > package where it came from, what language it is written in, and maybe > even accept a new shortcut for that item, without having to enable > "dynamic shortcuts") Right-clicking menus is afaik not supported by GTK+ and it would also be very hard to discover. I'd say the Plug-In Browser should be rewritten, probably in the core, to become a Menu Browser. It should be possible to bind it to a function key that can be invoked with a menu-item focused (as you can do with F1 to get help). Such a menu browser would also help to locate menu entries and it could offer a way to change the keyboard shortcut also. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
