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

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

> > utf8_name is just a const pointer into utf8_path, so it's no big deal.
>
> If we keep it, we also have make sure it remains correct at all time. If
> we generate it on-the-fly, that is not necessary. Although that might be
> more expensive depending on how often we need that piece of data.
>
> Note that much of these problems could be eliminated by making the
> contents of the struct private and providing accessor functions.

The utf8_path is never set directly, there is a set_path function for 
that, so utf8_name is always up to date.

However, if someone wants to restructure FileData using accessor 
functions, that would be great. But it's not a big priority at the moment.


> > 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.
>
> Is this the uri to the thumbnail file? E.g. the uri to a thumbnail
> located in ~/.thumbnails/.

No, it is just the form of the image filename that must be used when 
generating the hash-based filename of the thumbnail. Actually, we should 
probably be storing that instead... something to think about. gfile 
provides some thumbnail info, but I thought it only worked for "normal" 
thumbnail size (and not "large"). I forget the details.



> I think you are referring to the second case, while I'm more talking
> about the first one. But both cases needs to be dealt with. For instance
> if create a filename in ISO-8859-1 encoding, for instance with this command
>
> $G_FILENAME_ENCODING=ISO-8859-1 eog
>
> and choose save as with a filename with non-ascii characters. When
> trying to display this file in gthumb, it seems to work but with quite
> some warnings about invalid utf-8. With eog I only get one warning.

Could you file a bug report with a detailed example of some simple open, 
save, or close operation that doesn't work as expected in trunk? That 
would be helpful for nailing down these issues.


> BTW, eog is using GFile everywhere, and I think we should do that too.

That would be the longer-term plan, but the priority right now is to 
deliver something that doesn't rely on gnomevfs, I think.

Moving directly to gfile means changing a LOT of code, without any 
user-perceivable benefit. Which is fine, if someone wants to do the work.


- Mike