Re: [Gimp-developer] What would be a better set of default resources?
Hi, On Thu, 2009-07-23 at 22:07 +0200, Martin Nordholts wrote: So, we can only add resources and tags that have never shipped with a previous version of GIMP to the migrated user dir. Finding this set of resources and tags is just a matter of maintaining data sets with resources and tags shipped with each version of GIMP and some hacking/scripting. That would be error-prone, unreliable, a nightmare to maintain and extremely ugly from a software design point of view. How can you even consider this? I admit this is not trivial, but it is my opinion superior to using tags the way you describe and treat system resources in a special way. You yourself ask for treating system resources specially since you just admitted that we need to maintain data sets only for the purpose of migrating to future versions. It would be much cleaner if we just marked a system resource as deleted instead of copying it in the first place and then deleting it. Whether this is actually done using tags or in a different way is another question. But since we have tags now, it seems like the best solution to use this system. After all that is what it was designed for. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Improved brush editing interface mock-up
I think this is a very good idea -- moving the 'different ways of painting' into brushes so that we don't need Paintbrush, Pencil, Airbrush but just one : 'Paintbrush'. I use GIMP mainly for pixel art, and I find that I really want the paintbrush/pencil/airbrush tool distinction to go away, so I can just select 1px hard edge brush and not care about tool, and be assured that I paint with hard edges and will therefore not smudge the picture. Mypaint (http://mypaint.intilinux.org) does it like you suggest and it works very well -- especially the way that you can toggle erasing, I think that is a very useful improvement to workflow. It's true that 'much more could be added' -- MyPaint gives an extreme amount of brush settings, but it is not punishing to the user because you do not need to negotiate these options most of the time (nor do they occupy any screen space usually). I would like to see the possibility to make specific brushes for erasing or anti-erasing. My experience with MyPaint suggests that this is a very simple and effective way to do erasing. One issue I have found in MyPaint is that of committing changes -- say I select the 1px brush, and change the spacing to 50%. should that be automatically saved to disk, or discarded at the end of the session? (MyPaint opts to discard these changes at the end of the session. I think GIMP should visually indicate 'dirty' brushes and give the option to save changes) MyPaint also makes Opacity into a property of brushes. My experience is that this often makes it much easier to quickly get to work. I am very interested to see more. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
On 07/24/2009 09:06 AM, Sven Neumann wrote: Hi, On Thu, 2009-07-23 at 22:07 +0200, Martin Nordholts wrote: So, we can only add resources and tags that have never shipped with a previous version of GIMP to the migrated user dir. Finding this set of resources and tags is just a matter of maintaining data sets with resources and tags shipped with each version of GIMP and some hacking/scripting. That would be error-prone, unreliable, a nightmare to maintain and extremely ugly from a software design point of view. How can you even consider this? It would be much cleaner if we just marked a system resource as deleted instead of copying it in the first place and then deleting it. Whether this is actually done using tags or in a different way is another question. But since we have tags now, it seems like the best solution to use this system. After all that is what it was designed for. Whatever approach we take will require some dedicated code for managing system/default resources. My conclusion is that being forced to deal with this at migration time is less messy and keeps problems more local than spreading special treatment of system resources and tags throughout the rest of the system. Let's look at where we would need to have special treatment of tags and resources if we take your approach. Below, I will use the term system resource and read-only resource interchangeably since the problem we are trying to solve is not strictly limited to system resources, but the awkwardness of read-only resources in general. * We would have to treat deletion of normal resource and read-only resources differently * We would have to treat editing of normal resources and read-only resources differently * When editing a read-only resource we would have to mark the read-only resource as deleted to give the user the impression that it was the read-only resource he edited * In the above case, we would have to transfer tags from the read-only resource to the copied resource * When presenting the tag cloud we would have to make sure the tag we use to represent deletion is not shown as we can only show tags assigned by the user or the resource package designer * When exporting tags, we would have to make sure not to export deleted resources and/or the tag that represents deletion, i.e. it is not just a matter of dumping a subset of tags.xml If we use my approach, we would have none of the above special casing, and we would also get rid of these issues: * A user would have all his resources in one place, his user dir, instead of spread across the system * We can get rid of code that already now treats read-only resources as special (i.e. presents a brush as read-only in the brush editor) * Long-term, we might even get rid of some low-level programmer adapted Preferences namely the Folders page and sub pages To me, your approach is at least 10 times more messy and I don't understand why you would want to introduce all this special treatments and hacks in GIMP. I'm sure the above list of issues is not even complete as there surely are issues I have not thought about. Also, you keep saying that the original intent for tags was to allow deletion of system resources. This might be true, but are you really meaning that the tagging system that eventually evolved is suitable for this? It does not seem like it since you now admit yourself that using tags to mark system resources as deleted might not be the best idea. If you still think your approach is a good idea, I suggest that we both write patches that implement our own ideas. We can than more easily make comparisons of what approach is the least messy. BR, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Improved brush editing interface mock-up
- Leave the old tool selection concept to the new taggable brush selection window With a new generic brush system in most of the brush behavior is described by the brush settings, it's possible to leave the old tool selection concept to the new (and possibly even more improved) taggable brush presets window. What do you mean here? I think we need at least these paint tools: Paint (this would be able to do all of what Pencil, Paintbrush, and Airbrush do currently, and perhaps also Eraser), Ink (this does not use 'brushes'), Clone (also Heal?) , Perspective Clone , Blur/Sharpen, Dodge/Burn, Smudge. Do you really have a proposition to unify all of those, or do I misunderstand you? David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Improved brush editing interface mock-up
David Gowers wrote: What do you mean here? I think we need at least these paint tools: Paint (this would be able to do all of what Pencil, Paintbrush, and Airbrush do currently, and perhaps also Eraser), Ink (this does not use 'brushes'), Clone (also Heal?) , Perspective Clone , Blur/Sharpen, Dodge/Burn, Smudge. Do you really have a proposition to unify all of those, or do I misunderstand you? Yes, my proposition is to unify all of those. The idea is that 'brushes' would become something different than what it is now, more related to the physical proprieties of the tool used (= brush preset) than their meaning in the computer graphics world. Brushes in the 'brush' setting window would be of different, selectable types, like for example: - Brushless - Behavior as with the current ink tool - Parametric - Vector brushes with adjustable settings affecting their shape, possibly of many different types (and not only circular) - From clipboard - Bitmap brush - From file - Load a brush in bitmap/SVG format (future versions) - From path - Vector brush from a user defined path (future versions) Paint, eraser, smudge, clone, blur/sharpen, dodge/burn, clone, would be simply different brush modes selectable in the brush editing window, possibly in addition to others. Some would be mutually exclusive (since their effect would cancel one each other, some would stack. With my idea this way a brush can have different shapes, different physical behaviors, and different modes of operation. Of course, there would be plenty of built-in presets (since the amount of different options would be overwhelming for the average user) selectable from the brush preset Window. A few basic settings (size, opacity, spacing/rate and dynamics will remain easily selectable within the standard tool settings window. There are some usability details to be still clarified, but this is my general idea. Anyway, I agree that it would be similar in many ways than how MyPaint works (I swear I have never heard of this great application before!). (By the way, I think maybe it's better to explain this idea a bit a time while discussing with other users instead writing a long slab of text like I initially intended?) -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] cant save image with new comment
Hi, I added a comment to a png image and pressed Save. I was averted to the fact it failed by the fact it was too quick (a fairly large file). On repeating the save to see what happened I caught a glimpse of a subliminally fast message at the bottom off the screen. I repeated again to have time to read it. Basically it told me it was not saving because there were no changes. I see several problems here: 1/ the most obvious is that there was a change but because it was to the comment and not the image it was not picked up. 2/ there is no way to save save it anyway, trust me! 3/ the noticability here is way too small, had it not been for the fact I knew it had not had time to save the file I would have missed and sent my file without the copyright notice I believed I had just added and saved. possible remedies: 1/ make sure whatever code detects changes looks at all aspects of the file not just the image bitmap. 2/3/ if Gimp is going to disobey orders it had better say so loud and clear and give me an over-ride option. Either I'm making a mistake and need to know or gimp is making a mistake ... and I need to know. This presumably is supposed to avoid possibly lengthy save operations that are not needed. This IMHO is wrong thinking. If I made a slip, be it on my head, I'll have to wait a few seconds and pay more attention in the future. No harm done. It is also possible I have several image open and that I am not saving the image I think I'm saving. Again I need to know. I probably failed to save image I intended. This is all compounded by the obscurity of the message. Eye focus is in the middle of the screen and the message was too quick and away from my centre of attention. I believe this should be a Cancel/Save anyway message box. I know there is a trend to reduce this sort of thing but saving an unchanged image is not part of normal work flow and so it's occurance itself indicates a user error that needs to be flagged, not ignored rather quietly. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] cant save image with new comment
On 07/24/2009 11:48 AM, gg wrote: Hi, I added a comment to a png image and pressed Save. I was averted to the fact it failed by the fact it was too quick (a fairly large file). On repeating the save to see what happened I caught a glimpse of a subliminally fast message at the bottom off the screen. I repeated again to have time to read it. Basically it told me it was not saving because there were no changes. As a workaround for now, you can set (trust-dirty-flag no) in your gimprc. GIMP will then always save the image. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] nodockables
Hi, using gimp 2.6.6 I pulled the tool options dlg off the toolbox. Now it won't dock back in. the space says you can drop dockable dialogs here but nothing happens when I do. I remain with two independant windows. I was explaining to someone over the phone , theirs went back , mine didn't. I'm wondering if this is a WM issue. I'm using xfce4 /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] nodockables
On 07/24/2009 11:55 AM, gg wrote: Hi, using gimp 2.6.6 I pulled the tool options dlg off the toolbox. Now it won't dock back in. the space says you can drop dockable dialogs here but nothing happens when I do. I remain with two independant windows. I was explaining to someone over the phone , theirs went back , mine didn't. I'm wondering if this is a WM issue. I'm using xfce4 This isn't really gimp-developer material, but gimp-user material. Anway, you are not dragging the WM window title bar, right? You should be dragging the dockable title itself (which is within the window). Yes I know, this sucks, but that's what we have right now. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resource ?
Is too difficult browsing brushes notice that there are 4 quite different types of of brushes mixed The brushes are clearly marked: notice the red and blue triangles in the bottom-right corners brush thumbnails? Red triangles indicate image tubes or animated brushes. Blue triangles are procedural--made via the brush editor. The ones that lack triangles are single pixmaps. Also the pluses indicate a larger or animated thumbnail is available by clicking and holding on a thumbnail. As for coloured brushes, all of the ones I've seen are coloured in the thumbnail, so they should be obvious. i know but only initiates notice , most new users not (Except for the colored brushes, their difference is more visible and obvious) A default option to see brushes listed for type will solve (see such option will make clearer that are different types ) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
Hi, On Fri, 2009-07-24 at 10:33 +0200, Martin Nordholts wrote: Whatever approach we take will require some dedicated code for managing system/default resources. My conclusion is that being forced to deal with this at migration time is less messy and keeps problems more local than spreading special treatment of system resources and tags throughout the rest of the system. What is the migration time? You would have to deal with this on each and every start of GIMP. System resources may have changed, due to a minor or micro GIMP update or because the system maintainer added or removed resource files. This cannot be handled easily if we follow your approach and the result is a total mess. Let's look at where we would need to have special treatment of tags and resources if we take your approach. Below, I will use the term system resource and read-only resource interchangeably since the problem we are trying to solve is not strictly limited to system resources, but the awkwardness of read-only resources in general. * We would have to treat deletion of normal resource and read-only resources differently Why? We can hide normal resources as well. Perhaps it even makes sense to allow the user to decide whether to delete or only mark as hidden. I'll leave it up to the UI team to decide that. * We would have to treat editing of normal resources and read-only resources differently Sure, but that is rather simple. Just make a copy and auto-hide the read-only resource. * When editing a read-only resource we would have to mark the read-only resource as deleted to give the user the impression that it was the read-only resource he edited See above. You are using your arguments multiple times. * In the above case, we would have to transfer tags from the read-only resource to the copied resource * When presenting the tag cloud we would have to make sure the tag we use to represent deletion is not shown as we can only show tags assigned by the user or the resource package designer Yes. How is it difficult to not list tags that are associated to objects that have the tag gimp:hidden associated with them. Doesn't the current code even already allow that? We did definitely talk about this when the tag system was designed. * When exporting tags, we would have to make sure not to export deleted resources and/or the tag that represents deletion, i.e. it is not just a matter of dumping a subset of tags.xml Easy enough to skip resources that have the gimp:hidden tag. If we use my approach, we would have none of the above special casing, and we would also get rid of these issues: * A user would have all his resources in one place, his user dir, instead of spread across the system * We can get rid of code that already now treats read-only resources as special (i.e. presents a brush as read-only in the brush editor) * Long-term, we might even get rid of some low-level programmer adapted Preferences namely the Folders page and sub pages To me, your approach is at least 10 times more messy and I don't understand why you would want to introduce all this special treatments and hacks in GIMP. I'm sure the above list of issues is not even complete as there surely are issues I have not thought about. Simply because it is absolutely unacceptable to copy system resources to the user directory for no good reason. I am not going to maintain a software that does this. I would not any longer be proud of the GNU Image Manipulation Program if it started to do such things (again). Also, you keep saying that the original intent for tags was to allow deletion of system resources. This might be true, but are you really meaning that the tagging system that eventually evolved is suitable for this? It does not seem like it since you now admit yourself that using tags to mark system resources as deleted might not be the best idea. I think it is the best idea. Someone might have a better idea and that's what I admit that it might not be the best. But it definitely is the best idea that is being discussed right now. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] cant save image with new comment
Hi, On Fri, 2009-07-24 at 11:48 +0200, gg wrote: I added a comment to a png image and pressed Save. I was averted to the fact it failed by the fact it was too quick (a fairly large file). On repeating the save to see what happened I caught a glimpse of a subliminally fast message at the bottom off the screen. I repeated again to have time to read it. Basically it told me it was not saving because there were no changes. That's simply a bug then. Changing an image parasite should mark it as dirty. Please file a bug-report for this. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Improved brush editing interface mock-up
David Gowers wrote: I considered that modes might be how you meant to implement it. That is definitely a large change in the way the user would use paint tools, we should get Peter Sikking's input here for sure. Most users wouldn't normally have to play with those details. There could be a standard set of brush presets grouped under various tags which would contain at least one version of each mode (by default for example a fuzzy and a standard circle variant, freely scalable). Here's a quick and dirty mock-up of what I have in mind: http://i29.tinypic.com/wikarn.png And we must make it visually clear that these are really properties of the brush, to avoid user confusion (A disclosure triangle would deal with this neatly) Yes, you're right. I haven't thought about this yet. Another thing is that we have actions named like tools-value-[12345]-(increase|decrease), etc which currently control some brush parameters (value-1 is opacity, usually). With your proposition, we should consider whether we need more actions so that the user can do more quick changes by keyboard (for example, I'd like to be able to toggle 'Apply Jitter' using a keyboard shortcut. And if 'Fade' (and fade length) were bindable to keyboard actions, they would be far more usable IMO. I think that anything that can be varied with pen tablet dynamics (I proposed that most numerically variable brush parameters would be) needs to have optional keyboard actions too. oh, that reminds me, I gave the wrong URL, the correct URL is: http://mypaint.intilinux.com Yes, I eventually figured it out and downloaded the Windows build. Definitely, it will get developed more, that way :) True! -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
On 07/24/2009 12:28 PM, Sven Neumann wrote: Hi, On Fri, 2009-07-24 at 10:33 +0200, Martin Nordholts wrote: Whatever approach we take will require some dedicated code for managing system/default resources. My conclusion is that being forced to deal with this at migration time is less messy and keeps problems more local than spreading special treatment of system resources and tags throughout the rest of the system. What is the migration time? You would have to deal with this on each and every start of GIMP. System resources may have changed, due to a minor or micro GIMP update or because the system maintainer added or removed resource files. This cannot be handled easily if we follow your approach and the result is a total mess. We don't need to handle this. We don't need to adapt GIMP to a typical multi-user environment found at universities for example because those are not our target audience. Handling this at user dir migration to a new version is fine. * We would have to treat editing of normal resources and read-only resources differently Sure, but that is rather simple. Just make a copy and auto-hide the read-only resource. * When editing a read-only resource we would have to mark the read-only resource as deleted to give the user the impression that it was the read-only resource he edited See above. You are using your arguments multiple times. These are not arguments, they are example of where we need to add special cases. The more of these, the bigger the mess. That the special cases all stem from the same design approach is not relevant. * In the above case, we would have to transfer tags from the read-only resource to the copied resource * When presenting the tag cloud we would have to make sure the tag we use to represent deletion is not shown as we can only show tags assigned by the user or the resource package designer Yes. How is it difficult to not list tags that are associated to objects that have the tag gimp:hidden associated with them. Doesn't the current code even already allow that? We did definitely talk about this when the tag system was designed. This is not about difficulty in implementation, it is about avoiding a mess of special cases, both UI wise and coding wise. Also, you keep saying that the original intent for tags was to allow deletion of system resources. This might be true, but are you really meaning that the tagging system that eventually evolved is suitable for this? It does not seem like it since you now admit yourself that using tags to mark system resources as deleted might not be the best idea. I think it is the best idea. Someone might have a better idea and that's what I admit that it might not be the best. But it definitely is the best idea that is being discussed right now. As convinced you are that your approach is better than mine, I'm equally convinced my approach is better then yours. I take it you accept the challenge to write and compare actual code? Before we start though I'd love some input from the UI team on this topic. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
On 07/24/2009 01:10 PM, Martin Nordholts wrote: As convinced you are that your approach is better than mine, I'm equally convinced my approach is better then yours. I would like to add that if the ongoing brush dynamics and tool options redesign discussions end with a solution where editing of actual brush files is not necessary, then this whole discussion is obsolete. But as long as that file writability matters for resources, then what we have now is broken and needs to be fixed somehow. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
On Fri, Jul 24, 2009 at 2:31 PM, Martin Nordholts ense...@gmail.com wrote: On 07/24/2009 01:10 PM, Martin Nordholts wrote: As convinced you are that your approach is better than mine, I'm equally convinced my approach is better then yours. I would like to add that if the ongoing brush dynamics and tool options redesign discussions end with a solution where editing of actual brush files is not necessary, then this whole discussion is obsolete. But as long as that file writability matters for resources, then what we have now is broken and needs to be fixed somehow. Actually, this is the key point of this discussion and IMHO the RIGHT WAY(TM) to solve this. Editing resources during use should not require write access. Saving the changes should. Use tweaking should be a different level action than actual editing. Its extremely annoying if use level tweaking messes up your resource. If there's quiet auto saving, that should go away. Edit action should be available for writable ones and Duplicate edit(possibly a quiet one) for non-writable ones and should be different from tweaks you can save in tool presets. Both solutions on the table suck now. Copying system resources to the user would create two copies, on a single user system. in a system with A LOT of users, like a large family, say 5 users, would multiply the resources 5 times and say the head of the family likes to install resources system wide so the family can just use them... Or a better case. Small business has a set of corporate resources they want to be available to all the users of the terminal server. Those resources can be quite big. Copying them is a bad idea. Using tags to hide system brushes does not simply solve the problem of editing not writable resources.Hiding an edited system resource is pointless. However, using a Hide operation for any brush allowing user to organize his/her brushes and only offering delete for writable ones does solve the organization problem. If mass hide is possible, the issue of getting them out of the way is solved. I think the time would be better spent making the resource tweaking independent from the writabillity of the resource than on either of those proposals(Tag to hide resources will be needed anyway if we want to auto-hide obsolete resources, so getting that done would be needed anyway). --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
hi, from a long-term perspective, i expect resources to be shared easily 'on the cloud', with each resource item identified by a GUID. Then, the read-only system files are just a local cache of some of the available resources on the internet. Also from this perspective, it becomes strange to hide resources - it's rather that a subset of seamingly infinite resources gets pulled into the user's workspace. The mechanism to proliferate updated resources would be the same as searching for new resources -- initiated by the user. A hint could be shown that a certain new brush is _intended_ to replace an old one, but the replacement should not be done automagically. After all, these are actually two different resource items. Martin Nordholts schrieb: I would like to add that if the ongoing brush dynamics and tool options redesign discussions end with a solution where editing of actual brush files is not necessary, then this whole discussion is obsolete. But as long as that file writability matters for resources, then what we have now is broken and needs to be fixed somehow. if tweaked resources are to be shared, too, then it doesn't make a difference other than that potentially two files have to be shared in case adjustments are separated from the brush data. hope i'm not too far off ;) peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
hi, On Fri, Jul 24, 2009 at 2:59 PM, Alexia Deathalexiade...@gmail.com wrote: Actually, this is the key point of this discussion and IMHO the RIGHT WAY(TM) to solve this. Editing resources during use should not require write access. Saving the changes should. Use tweaking should be a different level action than actual editing. Its extremely annoying if use level tweaking messes up your resource. If there's quiet auto saving, that should go away. Edit action should be available for writable ones and Duplicate edit(possibly a quiet one) for non-writable ones and should be different from tweaks you can save in tool presets. Let me extend your idea a bit. Every time selecting a resource, a copy of it could be created (in memory, not on physical file). User could edit resource in any way she likes without affecting originally selected resources. GIMP could actually maintain a current-session-brush, current-session-pattern, etc.: when finishing session save currently selected resources (one for each resource type). When starting session only one resource for each type would need to be loaded in synchronously. All other resources could be loaded in background (improve startup time). ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
