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@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
