Re: [Gimp-developer] Integrated Scripting (fwd)
To: Nathan Summers [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Integrated Scripting I've used plenty of applications where the Windows menu does double-duty, with the kinds of windows that can be opened, followed by a separator, followed by the current open windows. Come to think of it, I'd say the only apps that I've used that don't do it that way are ones were all the windows are the same kind, anyway. what windows/dialogs are shown or not shown but in this case it is not at all pratical. At least to me, the View menu is for stuff that affects this particular view of this particular image, not dialogs and windows unrelated to it. Some simpler applications use the View items globally so that if you turn off the View of the status bar the next window will not have a statusbar but already open windows will remain unaffected. (this is a simplification I'd like to seem more applications make use of, but it slightly reduceds flexibility so I have been reluctant to suggest it for the gimp) And we should actually consider to add a Windows menu that lists all open GIMP windows. Listing all the open window list might help reduce the requests for a tabbed interface to the gimp many of which seem to be due to difficulties in managing lots of open windows. That would be a nice feature to have, but I don't think it would be a complete substitution for tabs. I'm not a fan of tabs. All too often the task list and window management are being reinvented for every app. My comment was basically a bit of a pot shot at Tabbed interfaces (a lot of users want them everywhere because they work well in the web browser) and encouragement to anyone who might want to implement the feature because I do agree it is a useful feature. Later - Alan H. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Integrated Scripting
On Thu, 23 Jun 2005, Sven Neumann wrote: Date: Thu, 23 Jun 2005 00:14:55 +0200 From: Sven Neumann [EMAIL PROTECTED] To: Alan Horkan [EMAIL PROTECTED] Cc: The GNU Image Manipulation Program gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] Integrated Scripting Hi, Alan Horkan [EMAIL PROTECTED] writes: The thing is that there are plenty of exceptions to that rule. File|Dialogs being a big source of stuff that doesn't need an image, I'm irked that we have both Dialogs and Dialogues Sorry, would you mind to explain that? We only have a menu called Dialogs. Everything else is a translated menu entry. It is ugly little localisation issue that I wish was not an issue at all. I should probably take it up with the en-GB translation team but if the menu item used a word that was the same in both American and British English my problem would go away. Seeing the most recent version of the gimp with the word Dialogs localised to Dialogues looks really really weird and disturbing. I've always thought of Dialogs (American spelling) as the computer kind and Dialogues (British spelling) as the conversation kind. Software manufacturers so rarely bother to fully localise computer terminology I have grown to think of the American way of spelling things to refer to the computer terminology. I wish I could find other examples of using local spellings to have a subtely different meaning but off the top of my head I cannot think of any non computing related examples (analogue, dialogue, programme, favourites, etc) but maybe you can think of examples of German words that have ambiguous meanings depending on which German speaking country they come from. I hope that makes some sense. and I would like to see it replaced with a term that doesn't require extra localisation work and yes I wouldn't be averse to slapping the slightly inappropriate Windows label on it (benefit of consistency with other software) but Palettes or even Docks which actualy describes the type of dialogs might be better. Windows is usually used for a list of opened windows. Photoshop is a bit weird I admit but the Windows menu is where it puts the menu items to control what Palettes are shown. The list of Open Windows is also included in there somewhere, and also an option to save workspace which will make sure window positions are remembered and a few other bits and peices (like maybe Close All, but I dont have convenient access to Photoshop so I'm really not sure what is in there). So if we used that we would use a term that is consistently used in other applications for something completely different. In theory the View menu would be the place to put menu items to control what windows/dialogs are shown or not shown but in this case it is not at all pratical. It may not be consistent in the general sense but graphics applications do what is consistent with Photoshop for better or worse. The menus are being reorganised anyway and this would be one less thing for them to complain about, so if ever there was an appropriate time for me to mention it I think this is it. And we should actually consider to add a Windows menu that lists all open GIMP windows. Listing all the open window list might help reduce the requests for a tabbed interface to the gimp many of which seem to be due to difficulties in managing lots of open windows. Sincerely Alan Horkan Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org Alan's Diary http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Integrated Scripting
On 6/23/05, Alan Horkan [EMAIL PROTECTED] wrote: On Thu, 23 Jun 2005, Sven Neumann wrote: Alan Horkan [EMAIL PROTECTED] writes: and I would like to see it replaced with a term that doesn't require extra localisation work and yes I wouldn't be averse to slapping the slightly inappropriate Windows label on it (benefit of consistency with other software) but Palettes or even Docks which actualy describes the type of dialogs might be better. Windows is usually used for a list of opened windows. Photoshop is a bit weird I admit but the Windows menu is where it puts the menu items to control what Palettes are shown. The list of Open Windows is also included in there somewhere, and also an option to save workspace which will make sure window positions are remembered and a few other bits and peices (like maybe Close All, but I dont have convenient access to Photoshop so I'm really not sure what is in there). I've used plenty of applications where the Windows menu does double-duty, with the kinds of windows that can be opened, followed by a separator, followed by the current open windows. Come to think of it, I'd say the only apps that I've used that don't do it that way are ones were all the windows are the same kind, anyway. So if we used that we would use a term that is consistently used in other applications for something completely different. In theory the View menu would be the place to put menu items to control what windows/dialogs are shown or not shown but in this case it is not at all pratical. At least to me, the View menu is for stuff that affects this particular view of this particular image, not dialogs and windows unrelated to it. And we should actually consider to add a Windows menu that lists all open GIMP windows. Listing all the open window list might help reduce the requests for a tabbed interface to the gimp many of which seem to be due to difficulties in managing lots of open windows. That would be a nice feature to have, but I don't think it would be a complete substitution for tabs. Rockwalrus ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Integrated Scripting
Hi, Leon Brooks [EMAIL PROTECTED] writes: Could a language-related mini-icon (16x16 or smaller) against each menu entry help? The idea of the menu reorganization is to hide the language from the user because the user shouldn't have to care what language a filter is written in. Adding a language specific icon is contradicting this effort. There will always be the plug-in browser if someone wants to find out more about a plug-in / script. We should try to improve this browser instead of cluttering the menus with such icons. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Integrated Scripting
On 6/22/05, Sven Neumann [EMAIL PROTECTED] wrote: Hi, Leon Brooks [EMAIL PROTECTED] writes: Could a language-related mini-icon (16x16 or smaller) against each menu entry help? The idea of the menu reorganization is to hide the language from the user because the user shouldn't have to care what language a filter is written in. Adding a language specific icon is contradicting this effort. I can't speak for anyone else who is working on menu reorginization, but my personal goal is to restructure the menus so that it is easier to find things. Putting everything in the same categories regardless of implementation flows naturally from this desire, since you look for things by functionality, and because searching four menus in different locations is more cumbersome. It is important not to lose the forest for the trees. One result of moving functionality out of implementation-specific menus into a common group is that information about implementation is less prominant, but it would be a serious mistake to conclude from that that this side effect is a goal. There will always be the plug-in browser if someone wants to find out more about a plug-in / script. I'm not going to say that there isn't a place for the plug-in browser, but this is not the place for it. There are very legitimate reasons that everyday users need to be aware of how a menu item is implemented. Some of these reasons are differences we can paper over or eliminate, such as the fact that repeat repeats the last non-core menu item ran, not the last run menu item. Some issues, such as knowing which bindings need to be installed to run your favorite script, cannot. There are several more examples I could list for both categories, but I will be brief, since you are intellegent enough to come up with them by yourself. Since there are good reasons that users should be familiar with how each menu item is implemented, it needs to be information that is well presented. Having such information unobtrusively placed in the UI is the only way this can be achieved. It is simply not reasonable to bury this information in the plug-in browser, where the user has to wade through irrelevant and likely-to-be uninteresting information for every single menu entry. For menu items that pop up dialogs, some ui element in the dialog would be a good location; perl-fu already does this. However, there are some plug-ins, like Gradient Map, that don't show a dialog, so unless you want to show a dialog like this: --[Gradient Map]- | Gradient Map is written in C. | | Since it's a plug-in you can | | use the repeat command to | | run it again. | |---| | [Ok] | - the most reasonable place to stick that info is in an icon in the menu. Futhermore, the fact that this particular suggestion -- icons by the menu items -- has been made by and most likely independantly thought up by several people should be enough in of itself to show that there is some merit to it. We should try to improve this browser instead of cluttering the menus with such icons. I don't think that adding such icons would be so bad, since after all, there are icons in other spots in the menus already. Even if doing so did make the menus a bit less attractive, the added useful information would more than balance it out. Our goal is to have a program that is useful and usable, not one that makes the centerfold of Awesome-Looking Programs Monthly. (Of course, it would be excellent if the editors of said magazine used GIMP to edit their content, and we don't want them to barf too much over looking at it in the meantime.) Rockwalrus ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Integrated Scripting
Sven Neumann wrote: Good idea, but please move the two new menus out of the toolbox. I'd like the toolbox menu to go away completely. If we can get rid of Xtns, we are almost there. FWIW, I have two plugins that plonk themselves in the Xtns menu, so if it goes, they'll need somewhere to live. Both of them create dialogs that are not attached to any particular image. * DBP (David's Batch Processor) - loads its own list of files, and processes them all. * File Sequencer - allows the user to select any loaded image, and if the filename contains a number, save the current image and load the next (or previously) numbered image into the same window with a single button press. -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Integrated Scripting
Alan Horkan wrote: Great topic. Personally I'd love to see the Script-Fu and Python entries go away, for the same reason as in the Filters menu: the user shouldn't have to know. I don't have a problem with that either. But as someone pointed out, we need a place to put the menu entries that allow a user or developer to start a language specific server, start the language specific console mode, as well as refresh the list of scripts. Right. If it were up to me, I'd split Xtns into two menus: 1. Development (or something similar): all the entries that have to do with mechanics of the languages (including C). It would look like: Mozilla uses a De_bug menu which is hidden in release builds and something similar (like Developement as you suggested) might be a good approach as these tools are mostly used for development and debugging of scripts. Using a menu only available in a development release may be ok for items only useful during true development. Putting menu items useful for developing/debugging scripts in a release only build would prevent would cause problems for those users who decide to write their own scripts. Just remember how some users when asking how to do something are told that GIMP doesn't have a menu item for what they want to do but they could create a script. Hiding the menu entries might be appropriate once we have implemented a macro recording ability sometime in the future. Python-Fu does not require a Refresh. Does Tiny-Fu require manual refresh? I am not sure what you mean by require manual refresh. Script-Fu and Tiny-Fu both allow you to refresh the scripts. This only needs to be done if a new script is added and you want to use it right away without having to restart GIMP. Since Script-Fu and Tiny-Fu read all scripts in to memory, a refresh is needed if a script is altered. 2. All the things that actually make new images. I don't know what to call this menu. Xtns or Misc or Generate (because it generates One of the minor complaints about Xtns is it being an abbreviation. Another possibility might be to call it Extras. There was some suggestion on IRC that not all the items in the Xtns-Script-Fu submenus create new images. I haven't gone through them yet to look for counterexamples I would need to review the list but the first one that comes to mind are the entries under Make Brush. -- Cheers! Kevin. (http://www.interlog.com/~kcozens/) Owner of Elecraft K2 #2172|What are we going to do today, Borg? E-mail:kcozens at interlog dot com|Same thing we always do, Pinkutus: Packet:[EMAIL PROTECTED]| Try to assimilate the world! #include disclaimer/favourite | -Pinkutus the Borg ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Integrated Scripting
Sven Neumann wrote: The idea of the menu reorganization is to hide the language from the user because the user shouldn't have to care what language a filter is written in. Adding a language specific icon is contradicting this effort. There will always be the plug-in browser if someone wants to find out more about a plug-in / script. We should try to improve this browser instead of cluttering the menus with such icons. A better browser would be useful. Most users won't (and shouldn't) care, or even need to know, whether a given menu item is a core function, a compiled plug-in, or a script. On the other hand, it is nice to know that a given menu item is implemented via a script since a user who generally likes what that script does but wants to tweak it or see how it does what it does can easily track down the script file. Some mechanism to map menu entries to information about the entries (including implementation details such as the scripting language used) would be useful. By knowing something was a insert language here script it should make it easier to find the file to fix/modify/inspect it. -- Cheers! Kevin. (http://www.interlog.com/~kcozens/) Owner of Elecraft K2 #2172|What are we going to do today, Borg? E-mail:kcozens at interlog dot com|Same thing we always do, Pinkutus: Packet:[EMAIL PROTECTED]| Try to assimilate the world! #include disclaimer/favourite | -Pinkutus the Borg ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Integrated Scripting
now that marc and sven have had their fun and we have all been allowed an example of how the perlized obfiscuates script-foneys with equal yet different levels of artificial intelligence; are there opinions of ways to rearrange the Xtns portion of the menu system? questions i have are these: what of the history of Xtns? it seems to be steeped in mystery and mis-use people rearranging the menus now do not seem to see that Xtns makes its own image and do not need to start with an image; even though the logic is very clear to some. is there a sane way to include a script from each of the languages? examples: font-mapping, yinyang drawing; all the scripts have one. some of the scripting languages have an example that shows how to use the script; however the result of using it is ugly. suggestions: identify these example scripts. include a menu entry for each of the gimp script powertools: the browsers the consoles the servers help browsers potentially helpful non-gimp urls what are other useful Xtns submenues: gimp-perl installs helpful menus to the Xtns menu: Render Animation script-fu uses useful subsubmenus of: Utils Misc my own instance of gimp, i have made submenus: Color PhotoGalleries i personally would not mind keeping Kevi1 busy with changes to Tiny-fu for a while, however, i am uncomfortable with the limited view i have had of the menu reorganization. my completely unresearched opinion was formed while seeing that it is being handled by people who have not actually experienced the whole gimp eh, experience. i also would be one of these people. i can at least see that by the time i started to use gimp, everything that appeared in Xtns were plug-ins that did not need an image to start with. fixing the problem with different types of scripts that do the same job in Xtns where it is much more of a problem will help everyone with the Image menu which has a few instances of this but not as many. thanks carol() ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Integrated Scripting
On Tue, Jun 21, 2005 at 07:18:25PM -0400, Nathan Summers wrote: On 6/21/05, Carol Spears [EMAIL PROTECTED] wrote: include a menu entry for each of the gimp script powertools: the browsers the consoles the servers I see little reason why these shouldn't be a subcategory of the other dialogs. The name Development was suggested. the word Development was frightening to me. i stayed a respectful distance away from it for probably too long. scripting gimp is easy and somewhat empowering to me (only on my computer so far, it would be nice to see some reflection of this feeling in my real life). i found that there was a similar situation involving the file named HACKING in the cvs source. this file contained helpful and perhaps necessary information, however there seemed to be a gender related bias towards looking at it. and equally frightening name Personalization is also not a good word, but it comes closer to what scripting gimp is like for me. actually, the thing that is wrong with this name is that it overlaps with the meaning of Preferences. Authoring misses both marks, while perhaps hitting a couple of marcs at the same time. Diving? Dive In is probably more to the point of what actually happens when you are of the mind to make gimp work a certain way and tackle this need with scripting. Development as a word should be used (both ways) more respectfully than is fun, or educational, or attractive to the larger group of people who can use this stuff and grasp how to use it. potentially helpful non-gimp urls That opens another can of worms, but to be brief, I like the idea of having such urls either being redirects from the gimp website, or dynamically updated every gimp startup. the best argument i heard against non-gimp urls being made available as the gimp urls are now is maintenance. can of worms is another interesting argument against this. i find the python library reference extremely useful when i am scripting. i dont need to get it through gimp though. both the perl and script-fu urls i have looked at scare the beegeebies out of me. i personally would not mind keeping Kevi1 busy with changes to Tiny-fu for a while Kevi? is certainly not the only one qualifed to change the locations the scripts register under. It's actually a trivial change for anyone. no, but he has been willing. the not trivial portion of the change is the number of scripts that will need it. , however, i am uncomfortable with the limited view i have had of the menu reorganization. my completely unresearched opinion was formed while seeing that it is being handled by people who have not actually experienced the whole gimp eh, experience. i also would be one of these people. Well, no one has experienced all of the gimp experience. That's what good old fashioned kibitzing is for. inspite of the very very not fun life changes that seemed to be triggered when i worked on another wiki, part of the reason for this thread was so that i could take the opinions of the developers who know what is going on, who might have something left to lose by volunteering at the gimp wiki. unless there is a reason that everyone should lose their life, their stuff and their little little place they carved out for themselves. i can at least see that by the time i started to use gimp, everything that appeared in Xtns were plug-ins that did not need an image to start with. Not technically true, as script-fu scripts are implemented through an extension, not a plug-in, but this only reinforces the point that no one knows/cares about the distinction. well, it is nice to start weird and perhaps not so well maintained scripts from somewhere not File. it is not a necessity, however, i know the lack of maintenance feeling i get is only gotten from when i use anything in Xtns. scripts that do not run nicely with the defaults (script-fu fontmap was like that (i have too many fonts installed)) and scripts that will cough up a DEPRECATED warning: i feel better when this happens from Xtns-- and not from File-- fixing the problem with different types of scripts that do the same job in Xtns where it is much more of a problem will help everyone with the Image menu which has a few instances of this but not as many. My suggestion is that Xtns menu items that create images should be called something like File|New Generated Image and that the rest should be merged with the other dialogs, ether as File|Dialogs or as a new toplevel Dialogs menu item. if new users are the concern, i have found that one of the biggest problem that people who are new to computer graphics has is the lack of understanding about what size image you need to have for the different jobs that graphics are being used for. meaning, they want to print their little 125x75pixel icon of bart simpson (for example) as a photograph. my idea was to
Re: [Gimp-developer] Integrated Scripting
Nathan Summers writes: On 6/21/05, Carol Spears [EMAIL PROTECTED] wrote: different levels of artificial intelligence; are there opinions of ways to rearrange the Xtns portion of the menu system? Great topic. Personally I'd love to see the Script-Fu and Python entries go away, for the same reason as in the Filters menu: the user shouldn't have to know. people rearranging the menus now do not seem to see that Xtns makes its own image and do not need to start with an image; even though the logic is very clear to some. The thing is that there are plenty of exceptions to that rule. File|Dialogs being a big source of stuff that doesn't need an image, File-Dialogs doesn't make a new image. I'm with Carol, most of the stuff in Xtns makes a new image, and should be grouped together accordingly. for example. I know that the reason for the difference is that the Dialogs are implemented by the core, but why should I care? You shouldn't. include a menu entry for each of the gimp script powertools: the browsers the consoles the servers I see little reason why these shouldn't be a subcategory of the other dialogs. The name Development was suggested. Right. If it were up to me, I'd split Xtns into two menus: 1. Development (or something similar): all the entries that have to do with mechanics of the languages (including C). It would look like: Module Manager Plug-in Browser Procedure Browser Unit Editor Script-Fu Console... Refresh Script-Fu Start Script-Fu Server... Python-Fu Console... Python-Fu Browser... 2. All the things that actually make new images. I don't know what to call this menu. Xtns or Misc or Generate (because it generates new images) or Create or New Images or ?? This would include all the submenus that are currently under Script-Fu, without any reference to the word Script-Fu. Any Python scripts (or C plugins or anything else) that gets added would merge into these menus too. There was some suggestion on IRC that not all the items in the Xtns-Script-Fu submenus create new images. I haven't gone through them yet to look for counterexamples; if there are some, maybe they should go somewhere else. Likewise, if there are items in Filters which create a new image rather than working on the current one (I don't know of any) then they should move here. I'd lean toward making both these menus top-level menus in the toolbox window (so there would be four menus, not three), but that would cause space issues in verbose languages and large fonts, so alternately, I'd make Development a submenu (probably of File or File-Dialogs, not of Xtns/Generate/whatever, since the Development items do not create an image). It's more important that the New Image Creating stuff be easy to access than that Development is, because anyone developing scripts for gimp knows enough to use tear-offs, or set up key bindings, or somehow make it easier to get to the language tools. Kevi? is certainly not the only one qualifed to change the locations the scripts register under. It's actually a trivial change for anyone. I'd be happy to do the work if we reach consensus on what should be done. Well, no one has experienced all of the gimp experience. That's what good old fashioned kibitzing is for. That's also what discussion on mailing lists, bugzilla and IRC are for. We still won't encompass the whole gimp experience, but at least by doing things in the open we'll have a chance of hearing from a range of people. My suggestion is that Xtns menu items that create images should be called something like File|New Generated Image and that the rest should be merged with the other dialogs, ether as File|Dialogs or as a new toplevel Dialogs menu item. I'd argue for that menu being a toplevel menu, so users are more likely to explore it. There are some cool scripts in there. There's some reorganization that could usefully be done inside that menu as well. Buttons only has two items, Misc only has Sphere, Utils only has two items. How about moving those five items up to be directly visible in the Generate/Create menu? So it would look like this: Logos Make Brush Patterns Web Page Themes --- Custom Gradient... Font Map... Round Button... Simple Bevelled Button... Sphere... Thoughts? ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Integrated Scripting
On Tue, Jun 21, 2005 at 05:38:36PM -0700, Akkana Peck wrote: Nathan Summers writes: On 6/21/05, Carol Spears [EMAIL PROTECTED] wrote: different levels of artificial intelligence; are there opinions of ways to rearrange the Xtns portion of the menu system? Great topic. Personally I'd love to see the Script-Fu and Python entries go away, for the same reason as in the Filters menu: the user shouldn't have to know. the one situation that i found this condition of gimp to be effective for was to quickly figure out what was installed and what wasnt when helping people to debug scripts or install necessary scripts. that usefulness is gone now. people rearranging the menus now do not seem to see that Xtns makes its own image and do not need to start with an image; even though the logic is very clear to some. The thing is that there are plenty of exceptions to that rule. File|Dialogs being a big source of stuff that doesn't need an image, File-Dialogs doesn't make a new image. I'm with Carol, most of the stuff in Xtns makes a new image, and should be grouped together accordingly. thanks for agreeing! include a menu entry for each of the gimp script powertools: the browsers the consoles the servers I see little reason why these shouldn't be a subcategory of the other dialogs. The name Development was suggested. Right. If it were up to me, I'd split Xtns into two menus: 1. Development (or something similar): all the entries that have to do with mechanics of the languages (including C). It would look like: Module Manager Plug-in Browser Procedure Browser Unit Editor Script-Fu Console... Refresh Script-Fu Start Script-Fu Server... Python-Fu Console... Python-Fu Browser... perhaps Scripting with submenus like that with the addition of: Perl Server Perl Console Perl Browser with the assumption that a perl console and browser can be written. 2. All the things that actually make new images. I don't know what to call this menu. Xtns or Misc or Generate (because it generates new images) or Create or New Images or ?? This would include all the submenus that are currently under Script-Fu, without any reference to the word Script-Fu. Any Python scripts (or C plugins or anything else) that gets added would merge into these menus too. i still find the idea of Utility very appealing. especially when considering where some scripts i wrote should go. silly scripts that generate web pages which will report what resources your gimp has access to. and plans i have for scripts that can apply parasites to groups of images. i also think that grouping the other plug-ins that make new images by resolution somehow would be most helpful to new users and not so well-educated older users and converts. use politically correct words for this like screen and other words that define the media that images are used on. Web Page Themes actually does do exactly as promised. instead of Create or New Images, the menu entry that gimp-perl installs that is called Render seems fitting. and Animation which i am using for my python animation scripts. it has been nice to have this menu there for this, i cannot imagine a better place to put it and do not want to search through Create or Render to find them. most of them are more like Alter Stacks. I'd lean toward making both these menus top-level menus in the toolbox window (so there would be four menus, not three), but that would cause space issues in verbose languages and large fonts, so alternately, I'd make Development a submenu (probably of File or File-Dialogs, not of Xtns/Generate/whatever, since the Development items do not create an image). It's more important that the New Image Creating stuff be easy to access than that Development is, because anyone developing scripts for gimp knows enough to use tear-offs, or set up key bindings, or somehow make it easier to get to the language tools. i do not mind moving the scripting stuff. i admit, i have grown fond of Xtns and cringe when i think of this name changing. i can see how difficult it must be to translate, however. Kevi? is certainly not the only one qualifed to change the locations the scripts register under. It's actually a trivial change for anyone. I'd be happy to do the work if we reach consensus on what should be done. i feel the same way, especially about the consensus part. if it means agreement the way it is being used here. Well, no one has experienced all of the gimp experience. That's what good old fashioned kibitzing is for. That's also what discussion on mailing lists, bugzilla and IRC are for. We still won't encompass the whole gimp experience, but at least by doing things in the open we'll have a chance of hearing from a range of people. My suggestion is that
Re: [Gimp-developer] Integrated Scripting
On Wednesday 22 June 2005 11:36, Carol Spears wrote: On Tue, Jun 21, 2005 at 05:38:36PM -0700, Akkana Peck wrote: Nathan Summers writes: Personally I'd love to see the Script-Fu and Python entries go away, for the same reason as in the Filters menu: the user shouldn't have to know. True, but... the one situation that i found this condition of gimp to be effective for was to quickly figure out what was installed and what wasnt when helping people to debug scripts or install necessary scripts. that usefulness is gone now. Could a language-related mini-icon (16x16 or smaller) against each menu entry help? Cheers; Leon -- http://cyberknights.com.au/ Modern tools; traditional dedication http://plug.linux.org.au/ Member, Perth Linux User Group http://slpwa.asn.au/Member, Linux Professionals WA http://osia.net.au/ Member, Open Source Industry Australia http://linux.org.au/Member, Linux Australia ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
