Re: [gthumb-list] FileData: the untold story

["Dr. Michael J. Chudobiak" <mjc avtechpulse com>]

Jef Driesen wrote:
> If there a reason for the existence of all those different
> representations, other than historical ones? I think it would be a lot
> easier (thus less bugs) to keep only one representations, and generate
> the others on-the-fly when necessary. Or is the caching of the
> alternative representations necessary for performance?

I want to drop path and name once the gio migration is complete. Sorry, 
I should have mentioned that!

utf8_path and local_path are the key fields that must stay, as you say.

utf8_name is just a const pointer into utf8_path, so it's no big deal.

uri is handy for thumbnailing functions. I would like to keep it, just 
because I would probably forget to do the conversion otherwise. Maybe it 
could be renamed to thumb_uri or something, to discourage misuse of it.


> I think the ones we should keep are the fd->utf8_path and fd->local_path
> fields. Or maybe even better is to use GFile's everywhere? That would
> have the benefit that we could pass it directly to all GIO functions.

Yes, we can easily add the gfile to the FileData struct if we find it 
useful and elegant (is that what you meant?). Native use of gfiles is 
the way of the future, but there is still a lot of filename handling 
required in gThumb.


> Note that the filename encoding issue is quite complicated. Filenames as
> stored in the filesystem are just byte strings (with or without a
> particular charset encoding), while for display we always need UTF-8
> string. But the conversion is not always lossless, so you need to keep
> both of them.

I think if we use utf8_path with gfile functions, and local_path with 
non-gfile functions, we're covered. Or am I wrong?

- Mike