GNOME Bugzilla – Bug 145145
updated camouflage script-fu
Last modified: 2009-07-16 08:40:56 UTC
see also bug 144491 find attached an updated version of the script-fu camouflage
Created attachment 29089 [details] version of the camouflage script (obselete, doesn't work within selection)
Could you please give a short description of the changes and the motivation behind them? Depending on that it should probably be considered for inclusion in 2.2.
http://www.mail-archive.com/gimp-developer%40lists.xcf.berkeley.edu/msg07370.html New File Dialog is poweful and flexible and makes it easy to create new images, it is better to have script work off the current image if possible. I have changed Camouflage and SwirlTile to work off the current image (they are added to the menu at Filters/Render/Patterns/ although I'd prefer if they weren't so deep but hopefully the menu reorganisation will allow the menu structure to be flatter) [but it belongs in the Filters menu because user care about what it does not programming language was used. this was discussed in bug 116145 ]
So you've moved the script from the xtns menu to the image menu. This adds an extra step (opening an image window) for someone who just wants to quickly create a pattern. Not that it isn't useful to have your modifications, but people already complained about having to open image windows for some functions in the past. Having the same script available from both locations is better than your curreent approach. Maybe you could figure out a way how to do this?
Is it really better to have the script in two places? I doubt that since our menus are already rather large. Adding more entries to them is not going to make it easier to locate the entry you are looking for. On the other hand people that know where the script is located now will have a hard time to locate it in the new location.
It is not about where the menu item is, the point is that the script works on the _current image_ whatever that may be. The old script could not work on the current image and if you already had an image you wanted to work on it was almost unusable, at best extremely awkard. With this version of the script it requires a slightly different approach to acheive the same results as the old version but it also makes it vastly easier to add a pattern to the current image. Getting the right size of new blank image you want is easier and more convenient by using the new image dialog. If you want a New image you can create it using the New Image dialog, which gives you much more better control over height and width and allows you to use templates. Creating a new image directly in a script is awkward and fiddly and really makes you appreciate the New Image dialog. Does it not make sense to create an image first and then apply a Filter or Effect to it? if the old script was about creating patterns rather than using them then I'm surprised it didn't take the next logical step and save the files and add them to the Patterns. I have work in progress to make the other patterns also work on the current image (already done) but I want to make sure they work on the current selection if there is one. I know the new menu location is not ideal (because it is too deep), but it is at least logical to put it with all the other Patterns, and in bug 116145 there seems to agreement that the Script-Fu and Filters menus could be merged. The change may be confusing but there were plans to restructure the menus anyway. Unfortunately since the Wiki died we have not been able to work on it. The Filters menu should be restructured so that the submenus are only one level deep, making everything not just the Patterns easier to find. From reading about usability and from my own use of software I know it can be confusing to have the same menu item in two different places (i keep expecting both File menus to be the same and contain an item for Prefernces strangely enough). As a last resort I could have it in two places to help keep things consistant with the old behaviour and easy to find for users familiar with the old way but I'm not convinced about the idea, improving the other pattern scripts to work within the current selection would be my priority. I think that having them in two places would do more harm than good in the long run, I always intend this script to replace the old one not duplicate it.
The new location might be better but I doubt that the small benefit of the changed script outweights the confusion that a moved script will certainly cause.
> the confusion that a moved script will certainly cause. does this mean I need to wait until post 2.2 (or) whenever the other menu reorganisation happens? (if so please push the milestne to Future) Although have not finished yet and I am unlikely to be finished in time for 2.2 I am working on the other patterns so that they can all be moved out of "Xtns,Script-Fu,Patterns" so because the change would be happening to ~5-6 scripts all at once it will be much clearer and less confusing.
I think if we need to either move all pattern scripts or none. Our schedule for 2.2 would give you another 8 weeks to port all scripts. If you think that is reasonable, then please open a bug report for this task and attach one or more diffs (please diffs, not complete scripts) with your changes. If someone thinks that moving the scripts is a bad idea, then better speak up now. Alan, if you want to be sure, perhaps raise that question on the mailing-list?
I've got all the pattern scripts working on the current image (I had that done already) I have Render Map, Land and Flat Land working with the current selection if there is one. Haven't got Truchet and Truchet 3D done yet and they are looking more difficult but I think I'll be able to get them done. Swirl is a bit odd and I'm not sure what it should do which makes fixing it more difficult. Why patches? Normally patches make sense but I've changed filenames, commented extensively, changed indentation, variable names, restructured things, fixed bugs improved speed where possible and lot of other little details (I've been playing with the scripts on and off for months) Patches will be significantly bigger than the files. If you still want patches them I dont mind provding patches too.
Well, usually, you change one aspect of a script and submit a patch for that single aspect. That allows the change to be reviewed easily and if it is committed, the change can be easily reverted if necessary. If you mix several changes you are making it a lot more difficult to review the change and thus make it a lot less likely that it will be accepted. Code cleanups should if possible be committed separately from real changes.
Finished so far: Pattern - Camouflage (updated to work within active selection or whole image) Pattern - Tempest (formerly known as Swirl Tile) Pattern - Flat Land Pattern - Land Pattern - Render Map Pattern - Swirly http://matrix.netsoc.tcd.ie/~horkana/dev/gnome/gimp/script-fu/script-fu.html I can attach them all individually (and to seperate reports) or I can tar gzip them if you prefer. All have differnt file names and differnt funtion names and can be used alongside the old versions if someone really wants that. Not Done yet: Truchet 3d-Truchet I have project work to do and am not sure I'll have time to work on Truchet over the next few weeks but I would really like for the other scripts to be included in time for Gimp 2.2. (part of the reason truchet is taking so long is that I've added another pattern using the truchet code and I need to clean it up).
I really don't know what to do about this. Actually I like the idea of moving the pattern scripts to the Filters->Render menu. But, as said before, we'd have to do that for all scripts. Perhaps some more people could tell us what they think about this plan. We would also need a volunteer who feels responsible for finishing this task for 2.2.
I think that between Alan, me, and whomever else we can recruit, we can get it done for sure.
Nathan, can you take this job then? You have CVS commit access and should be able to get this done with Alan. If you think this should be discussed on the mailing-list beforehand, perhaps that would be a good idea. I don't insist on it however.
Nathan, I have a version of Truchet that works on the current image. There are lots of problems with it, this explantion could be quite long. The problem is that this whole endevour started off as me customizing these scripts for my own use, not expecting the changes to be enough to go back into the gimp. I have made some experimental changes to both of the Truchet scripts that are difficult to unbreak, and as I was not using a Version Control System I cannot rollback to the last known good state. I wanted to remove the backfill on the Truchet so that it can be used as an overlay but I have been having problems with the new transparency of the new layer not being clear. I have also modified the Truchet scripts to create another pattern called "circle stars" (but I'm looking for a better name) which reuses Truchet to produce what looks like overlapping circles, the intersections of which form curved star shapes. Unfortunately for this to work properly requires the ability to choose differnt tiling alogorithms than just randomly alternating between the (which in turn potentially creates quite a few more pattern variations) I have not yet been able to cleanly integrate the two scripts, at the moment it involves uncommenting bits of code so that slightly different tiles are produce and a slightly differnt tiling pattern is used. These changes could be commented out and it would make no differnce to end users. Sven I believe I brought this to the list before at your requests when the task started. Some users wanted to keep versions of the scripts in the Toolbox, but I did not understand why exactly other than people liking things as they are. Some suggested that I should provide both Image and Toolbox version but that was exactly the kind of duplication. I deliberately gave the scripts new names so that users could keep the old versions of the scripts alonside the new ones if they really wanted. In future I could be convinced to provide wrappers of my scripts so that they could be used from the toolbox but that would definately be post 2.2 and I would not particularly want such wrapper scripts to be included in the gimp, duplication of menus items can be confusing for users. Is it somehow more useful to have things in the Toolbox if you are batch processing images from the command line? It is something I have been meaning to take a look at and see if I could create some simple scripts.
IMO the menu locations of all scripts need to be changed and it doesn't make sense to do only one or two scripts for 2.2. I suggest that this bug as well as bug #145146 is moved from the 2.2 milestone.
Let's look into this again when we have branched after 2.2.
The URLs referenced in the mailing list archive message of comment #3 and the URL in comment #12 are no longer valid. I don't think moving some of these scripts from the Xtns menu to an image window menu is the right thing to do. If having a script work on the current image instead of having it work on an image on disk would be useful the script should be updated to add a new menu entry. The existing method for running the script should be maintained. This would be similar to a number of the Logo scripts that can create a new image or work on an existing image.
Too many broken links, the old mailing list archive no longer works so here is an alternative link for that http://www.mail-archive.com/gimp-developer@lists.xcf.berkeley.edu/msg07370.html BOFH admins broke the other links despite my protests (and changing a long standing policy) but replacing "matrix" with "www" gives a working link: http://www.netsoc.tcd.ie/~horkana/dev/gnome/gimp/script-fu/script-fu.html Having the same/very similar menu item exist in two different places can be confusing. Part of why I rewrote these scripts was to avoid the hassle of switching between the image window and the toolbox. As I said above, I made a deliberate point of renaming all my scripts so users could add back the old scripts if they really wanted, but no one has made any suggestions why that might be desirable since creating a new image using the standard new image dialog first (or using an existing image) then putting a pattern on it is so much cleaner and easier.
Let's look at this again after 2.6. Perhaps it would be even useful to open a new report for this and merge this one and bug #145146 into it. The current summary is somewhat misleading.
I have now created a separate bug report for this, #bug 588755 – Port pattern generation scripts to work on the current image. Closing this as INVALID in lack of better resolutions. It's not a DUPLICATE to the new one and it's not OBSOLETE.