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 <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
-- nautilus-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/nautilus-list
