Re: [PATCH] Move custom icons when copying metadata

Am Montag, den 26.09.2005, 12:28 +0200 schrieb Alexander Larsson:
> You're mixing g_free/xmlFree in:
> +               property = xmlGetProp (destination_file_node, NAUTILUS_METADATA_KEY_CUSTOM_ICON);
> +               if (property != NULL && g_str_has_prefix (property, source_file_uri)) {
> +                       p = property;
> +
> +                       property = g_strconcat (destination_file_uri,
> +                                               property + strlen (source_file_uri),
> +                                               NULL);
> +                       xmlSetProp (destination_file_node, NAUTILUS_METADATA_KEY_CUSTOM_ICON, property);
> +
> +                       xmlFree (p);
> +               }
> +
> +               xmlFree (property);
> I recommend using p for the g_strconcat result instead and then
> g_free(p).

Maybe sb. could explain me what the influence of char signedness is in
practice, and in what conditions I can safely "mix" xmlChar and
(g)chars? I supposed I'm not supposed to mix them at all - hence the
namespacing? What if the numeric value of an xmLChar is greater than the
value a char is able to take and I pass it to g_strconcat?

> Its sort of strange that the metafile system special-cases a specific
> key entry like this. It would make more sense to e.g. store the custom
> icon with a relative filename. That would work for more cases than the
> prefix of the uri being identical too. For instance when there are
> symlinks etc involved.

Yup, I've had something like that on plate already. However, it didn't
seem trivial to make a relative out of two full URIs. Also, I wanted to
fix this in a way that does not force users to re-pick icons for their
existing folders.

Christian Neumair <chris gnome-de org>

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]