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