Re: [Gimp-developer] changes in script-fu in 2.3.14
I have a rough draft of some of the differences between SIOD-fu. It is not yet comprehensive but perhaps it might be useful as a starting point. http://flashingtwelve.brickfilms.com/GIMP/Scripts/Script-fu-2/Reference/SIODdifferences-0.1.txt On Tue, 2007-01-30 at 12:53 -0800, Akkana Peck wrote: If someone can make a quick comprehensive list, I'd be happy to help with getting it into a more readable form, if that's the issue. I don't know enough about the changes to make the list myself: I know what I've done to convert a few small scripts, but we need someone with more general knowledge than that. It is amazing what you can accomplish if you do not care who gets the credit. -- Harry S. Truman ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Drawing zones
Sorry, no. I don't see the benefit over switching between layers. #1: A selection does not overlap its inverse. #2: There is no need to keep track of which layers are associated with each other (and for switching between layers, presumably they would need to be adjacent in the layerstack). #3: Switching between drawing zones (i.e., inverting the selection) uses the same keystroke/action regardless of which zone is active. (For layers, the user would have to remember whether to activate the layer above or below.) #4: The Layers window is not cluttered with zone layers. Lets try another description: Drawing zones would be like 2 or more non-overlapping selections that are active at the same time. Which one is applied to a drawing operation is determined by where the mouse/pen-down happens. If the only difference is whether a mouse-click is used on the canvas or a keystroke/menu/widget action is used to invert the selection, I suspect you shall have a difficult time convincing the GIMP developers to add your concept of a drawing zone to the core and have it honored by all the paint tools. It is amazing what you can accomplish if you do not care who gets the credit. -- Harry S. Truman ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
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. http://bugzilla.gnome.org/show_bug.cgi?id=358816 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 and 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 gives 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
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
gg wrote: I also find as a user that menus often go too deep. One sub-menu is acceptable , two starts to get unwieldy. Eg. I ofter copy a selection and Paste As New , this is three levels deep. I'd like to see this at the same level as Cut: Cut | Paste | Paste as New. I crated a hot-key as a work around but as others have said , I would rather keep my eyes on the screen except for typing numbers etc. Is there a reason you don't use tear-off menus? Having small sub-menus actually enhances this utility. Another improvement would to clean up some menus. The Blur menu seems to contain several, largely equivalent filters. Two would suffice and could be incorporated into Enhance. Which two would suffice? Personally, I find all of them useful and I wouldn't recommend combining filters that use different algorithms into one interface -- not only would this complicate maintenance and development but menu grouping is a great indicator of a command's function. I also created a bug about making sure sub-menus did not jump from one side to the other. This is appalling from a usability point of view but the comment did not get a very positive response. If your proposal were accepted, there would be reports submitted complaining that all the submenus appear on the left when there might be only one that's overly-long. My preference is to minimize the number of times that my eyes have to jump from the far right of menu text to the far left of sub-menu (much less appalling to just continue reading left to right). Some real basics like flip and rotating an image to straighten it up should be on the image menu. Erm, they are. Some anomolies could be looked at, I can free-rotate a layer but not an image. Erm, you can. Colors | Retinex ?? What's that supposed to tell the user? It tells me that it performs an operation called Retinex on the image. If I did not know what the word Retinex meant then, just like any other word with which I was unfamiliar, I would look it up. If Retinex is an inaccurate description of the processing taking place, a change in name might be called for but otherwise I would submit that the purpose of the GIMP is not to serve as a dictionary of graphics terms. It is amazing what you can accomplish if you do not care who gets the credit. -- Harry S. Truman ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-Fu procedure blurb review
we still need the Script-Fu blurbs reviewed for GIMP 2.4. http://bugzilla.gnome.org/show_bug.cgi?id=351283 Might you perhaps find time to finish this task anytime soon? I have submitted a patch which hopefully will be close to what you are expecting. It is amazing what you can accomplish if you do not care who gets the credit. -- Harry S. Truman ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Switch to Tiny-Fu, end of Script-Fu maintenance?
Unless anyone objects, I would like to commit a trivial patch tomorrow that disables Script-Fu by default in configure.in. It will still be possible to use the old interpreter by using --enable-script-fu explicitely, but otherwise Script-Fu should be considered as obsolete. I should like to try out Tiny-fu on its own but I have been unable to compile the GIMP without Script-fu. I have performed an uninstall, make clean, and configured with the --disable-script-fu but SIOD is still installed. Could you shed any light on what I am doing wrong? It is amazing what you can accomplish if you do not care who gets the credit. -- Harry S. Truman ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] undoo history and automatic script creation
Am I missing something about why this is hard to do, or has it just never been a priority to provide record to script capability? If my understanding is correct, the UNDO history does not record the actions you take, merely the result of those actions (by saving the portions of the image that were modified. The difficulty of providing a record to script functionality (AKA macro recorder) is that you would have to maintain a record of the specific actions taken (otherwise your recorded script would not work on a different image). A macro recorder would basically have to be a different implementation than the UNDO history. I imagine certain simple actions (such as changing the opacity of a layer, select-none, etc) are already recorded in the UNDO history as actions and you might examine how those are handled if you are interested in implementing a macro recorder. It is amazing what you can accomplish if you do not care who gets the credit. -- Harry S. Truman ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] undoo history and automatic script creation
On a related note to this thread, I was wondering if there was any way to have a script perform an Undo or to go back a few steps in the Undo history. I have a script which chops a layer up into multiple pieces and the result is a layer that is centered relative to the original layer. In many situations, it would be desirable to have the generated layer aligned to the corners of the original layer. I had considered performing the additional alignment steps and then the user could perform UNDOs until he achieved the alignment he desired, but this would make it very tedious (and unintuitive) to perform an actual UNDO. However, if I could perform the four alignments in the script and subsequently set the UNDO history back to the centered result, then the user could perform REDOs to attain his alignment while retaining the intuitive, one-step UNDO (or alternately, just continue with his editing). I am unaware of any PDB function that would permit and would be interested in any input as to how this might be accomplished -- including which code in the core I might avail if I were to create such a PDB function. It is amazing what you can accomplish if you do not care who gets the credit. -- Harry S. Truman ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI improvements (was: Moving selection contents with the move tool?)
The space bar feature is still present (as an option) and it has always been implemented by switching to the Move tool temporarily. Sven Indeed, you are correct. I must have switched the affect: option of the Move tool during my experimentation and failed to restore it. These are plug-ins (color2alpha, semiflatten, threshold_alpha) or tools (Rotate tool). Plug-ins automatically honor the selection, And being able to make such a blanket statement should simplify things for the user. Unfortunately, without a way of differentiating between a plug-in or a core function in the menu system that knowledge is of no benefit to the user. Nonetheless, of more importance than the Layer menu, it would be of great benefit to the user interface to be able to make such a general statement about tools (i.e., tools automatically honor the selection). Since there is only one tool that violates this at the current time, it would seem most reasonable to make that tool conform; especially since Move operations bear such a connection and similarity to Transform operations. The current Affect: options of the Move Tool and all of the transform tools have the same tool hints: Transform Layer, Transform Selection, and Transform Path. There is nothing in the user interface to suggest that the Move Tool does not honor selections while the other tools do. It seems to me that adding a Transform Selection Contents mode to the Move tool and a Transform Layer mode to the transform tools would provide an extremely desirable commonality while correcting an obvious inconsistency. It is amazing what you can accomplish if you do not care who gets the credit. -- Harry S. Truman ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI improvements (was: Moving selection contents with the move tool?)
All tools in the current toolbox honor the selection EXCEPT the Move Tool -- though in some cases the selection is not reasonably applicable (eyedropper, zoom, measure, and crop) and in cases of the selection tools, there are modes which modify how selections are treated. To a large extent, all operations in the Layers menu do not honor selections. The notable exceptions are: Transparency-Color To Alpha Transparency-Semi-flatten Transparency-Threshold Alpha Transform-Arbitrary Rotate I would submit that the exceptions listed would best be eradicated: that a general policy be maintained that the default behavior of all functions under the Layer Menu operate on drawables while disregarding any selection and that the default behavior of all tools in the Toolbox honor selections (unless directed otherwise). In order to prosecute such a policy, I would propose the following changes to the current (development) interface: 1) Move the offending Transparency functions to the new Colors menu. 2) Have the Arbitrary Rotate MENU function ignore the selection, operate on the drawable, and not generate a floated layer. 3) Modify the Move Tool so that it operates precisely like the transform tools, honoring the selection and operating on its contents. (This means that a dialog would be presented, numeric offsets possibly enterred, and OK pressed to generate a floated layer). 4) Add a modified mode to ALL of the transform tools (plus/including the new Move Tool) which makes them ignore the selection, operate on the drawable, and not generate a floated layer. Ideally, if the tool is activated in this mode (perhaps CTRL+ALT being held down while the mouse is initially clicked), there should be no dialog presented and the operation take place when the mouse button is released (if the mode is activated after the tool is executed then pressing OK would be required). 5) Restore the option to use the space bar to move the current layer without any dialog being presented. This could readily be implemented by executing the Move Tool in the ignore selection mode. It is amazing what you can accomplish if you do not care who gets the credit. -- Harry S. Truman ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Moving selection contents with the move tool?
On 9/28/06, Michael Natterer [EMAIL PROTECTED] wrote: In Current CVS, you have to press alt+shift or alt+control to actually move the pixels with a selection tool. Nobody does that accidentially, and it's a powerful tool for power users. I see no reason to remove it. A feature being useful doesn't justify its misplacement in the command structure. Maybe that is stating things a bit harshly but selection operations should be limited to operating on selections. I am a great fan of overloading commands but there needs to be some basic and comprehensible limits to what groups of commands do, otherwise they cease to be groups. How is it any more of a power tool to hold ALT+CTRL while a Selection Tool is active versus pressing another key (such as M) to activate a Move Tool? Especially since the result is a floating selection for which selecting will no longer be of any use (you can either Anchor or continue to Move). And if moving the selection contents is such a useful tool to have at one's disposal (with which I would heartily agree), why is it an almost hidden auxiliary function of the Selection Tool -- with no equivalent elsewhere in the toolbox? OFF-TOPIC: A screenshot of the Move Tool double option window is available at http://flashingtwelve.brickfilms.com/GIMP/Screenshots/Move.png That was compiled from Monday's CVS. I will try rebuilding this weekend. It is amazing what you can accomplish if you do not care who gets the credit. -- Harry S. Truman ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
