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