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.

Gimp-developer mailing list

Reply via email to