Hi, On Fri, 2009-07-24 at 13:10 +0200, Martin Nordholts wrote: > > 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. Of course we need to keep such multi-user environments in mind, even if they are not our main target. And apart from that, you get the same situation if the user herself installs an extra data package for GIMP system-wide by means of the packet management system of her Linux distro. > >> * 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. Right, these are special cases and their number is important. Which is why I pointed out that you are using the same example multiple times only to increase the number of special cases. That is not a fair comparison, I am afraid. GIMP has done it the way you proposed in the past and copied system resources to the user directory. This was ugly and caused lots of grief. Eventually we got rid of this mess and now you are proposing to undo this work and to reintroduce this ugliness? That's very disappointing. Sven _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
