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