After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 794992 - Need API loading data from a GFile
Need API loading data from a GFile
Status: RESOLVED DUPLICATE of bug 732748
Product: gexiv2
Classification: Other
Component: interface
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Gexiv2 Maintainers
Gexiv2 Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-04-04 22:11 UTC by Jehan
Modified: 2018-04-05 15:01 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jehan 2018-04-04 22:11:22 UTC
In GIMP, we load GExiv2 metadata with: gexiv2_metadata_open_path()
This requires a path from the local encoding, and on Windows on particularly, the result of g_file_get_path() will fail to load for complex paths. And g_win32_locale_filename_from_utf8() is not right either, since Windows anyway uses wchar and whatnot.

We had the case on bug 794949, with a path such as "F:\都.png".

Anyway rather than trying to do something complicated, it would be much easier if GExiv2 were to support GIO which already does everything for you the right way. I guess a new API gexiv2_metadata_open_file() could just use an existing GFile.

And of course make the other API for saving or whatever is there in the library when interacting with files. :-)

Right now, this is quite annoying because we are not able to load metadata for these files (which otherwise load fine).
Comment 1 Debarshi Ray 2018-04-05 08:49:31 UTC
(In reply to Jehan from comment #0)
> In GIMP, we load GExiv2 metadata with: gexiv2_metadata_open_path()
> This requires a path from the local encoding, and on Windows on
> particularly, the result of g_file_get_path() will fail to load for complex
> paths. And g_win32_locale_filename_from_utf8() is not right either, since
> Windows anyway uses wchar and whatnot.
> 
> We had the case on bug 794949, with a path such as "F:\都.png".

If GFile isn't working properly on Windows, then I'd consider that to be a GFile or GLib/GIO bug.

> Anyway rather than trying to do something complicated, it would be much
> easier if GExiv2 were to support GIO which already does everything for you
> the right way. I guess a new API gexiv2_metadata_open_file() could just use
> an existing GFile.
> 
> And of course make the other API for saving or whatever is there in the
> library when interacting with files. :-)

Yeah. There's bug 732748, which is somewhat related.

I think that supporting GInputStream and GOutputStream is more generic and/or powerful because once you have that, GFile support follows automatically. The limitation of GFile is that it requires the backing storage to be either native or have a GVfs backend, which isn't always powerful. For example, if I want to access an image from Google Photos, I get a stream from libgdata but no GFile.
Comment 2 Debarshi Ray 2018-04-05 08:51:38 UTC
(In reply to Debarshi Ray from comment #1)
> The limitation of GFile is that it requires the backing
> storage to be either native or have a GVfs backend, which isn't always
> powerful.

s/powerful/possible/
Comment 3 Jehan 2018-04-05 09:09:39 UTC
(In reply to Debarshi Ray from comment #1)
> (In reply to Jehan from comment #0)
> > In GIMP, we load GExiv2 metadata with: gexiv2_metadata_open_path()
> > This requires a path from the local encoding, and on Windows on
> > particularly, the result of g_file_get_path() will fail to load for complex
> > paths. And g_win32_locale_filename_from_utf8() is not right either, since
> > Windows anyway uses wchar and whatnot.
> > 
> > We had the case on bug 794949, with a path such as "F:\都.png".
> 
> If GFile isn't working properly on Windows, then I'd consider that to be a
> GFile or GLib/GIO bug.

Yeah that's was also my initial resolution path. But Mitch persuaded me that having GExiv2 support GIO would be a much better resolution since it makes life a lot easier.

This said, clearly there could also be another bug report for g_win32_locale_filename_from_utf8(). This path is on the system (it is a path for a file currently existing), so unless I miss something, it should clearly be encodable in the local encoding!

> > Anyway rather than trying to do something complicated, it would be much
> > easier if GExiv2 were to support GIO which already does everything for you
> > the right way. I guess a new API gexiv2_metadata_open_file() could just use
> > an existing GFile.
> > 
> > And of course make the other API for saving or whatever is there in the
> > library when interacting with files. :-)
> 
> Yeah. There's bug 732748, which is somewhat related.
> 
> I think that supporting GInputStream and GOutputStream is more generic
> and/or powerful because once you have that, GFile support follows
> automatically. The limitation of GFile is that it requires the backing
> storage to be either native or have a GVfs backend, which isn't always
> powerful. For example, if I want to access an image from Google Photos, I
> get a stream from libgdata but no GFile.

If you say so. We have a GFile, but since we can get GInputStream and GOutputStream out of this GFile, an API based on these would work too, I guess.
And as you say, maybe in the future it could mean we could directly read from more sources.
As long as it works for us!
Comment 4 Debarshi Ray 2018-04-05 13:57:55 UTC
(In reply to Jehan from comment #3)
> (In reply to Debarshi Ray from comment #1)
> > (In reply to Jehan from comment #0)
> > > In GIMP, we load GExiv2 metadata with: gexiv2_metadata_open_path()
> > > This requires a path from the local encoding, and on Windows on
> > > particularly, the result of g_file_get_path() will fail to load for complex
> > > paths. And g_win32_locale_filename_from_utf8() is not right either, since
> > > Windows anyway uses wchar and whatnot.
> > > 
> > > We had the case on bug 794949, with a path such as "F:\都.png".
> > 
> > If GFile isn't working properly on Windows, then I'd consider that to be a
> > GFile or GLib/GIO bug.
> 
> Yeah that's was also my initial resolution path. But Mitch persuaded me that
> having GExiv2 support GIO would be a much better resolution since it makes
> life a lot easier.

Yes, but those are different things.

If GFile is not giving a valid path on Windows, then that needs to be fixed (or worked around) anyway. GFile is just a higher level wrapper around paths and URIs. It's not like Windows or Linux system calls have native support for GFile. :)

I am not very familiar with Windows, so I can't immediately suggest a fix for this particular problem, but given how widely GFile is used it seems best to address this in GLib as opposed to working around it in GExiv2. Feel free to file a bug/issue against GLib and CC me, if you want to.

Support for GIO can mean support for: (a) GCancellable (b) GFile (c) GIO streams (d) GIO-like async APIs, etc.. Those are nice things and I want them too, but won't fix the issue of GFile not returning a valid path on Windows. :)

Mitch filed bug 732748 for GIO stream support, which I think is the most interesting and difficult to implement.

I'd say that (b) is a bit misleading because one can claim GFile support by feeding g_file_get_path to the existing GExiv2 API. An application can trivially do that.

(d) can be convenient, but an app can implement it with g_task_run_in_thread, so not that big a deal.

Cancellation is interesting because an app can't implement it on it's own, and GCancellable is pervasively used all over the GNOME platform.

Incidentally, support for GIO streams will automatically enable all of the above and much more.

> This said, clearly there could also be another bug report for
> g_win32_locale_filename_from_utf8(). This path is on the system (it is a
> path for a file currently existing), so unless I miss something, it should
> clearly be encodable in the local encoding!

Yes, probably. I don't know Windows that well.

> If you say so. We have a GFile, but since we can get GInputStream and
> GOutputStream out of this GFile, an API based on these would work too, I
> guess. And as you say, maybe in the future it could mean we could directly
> read from more sources.

So, some streams are backed by a GFile (eg., GFileInputStream and GFileOutputStream), others are not (eg., GMemoryInputStream, GMemoryOutputStream, the streams from libgdata, etc.).

Currently, all the code that I know about (ie., GIMP, GNOME Photos, Tracker, Nautilus, etc.) end up using a GFile anyway. However, it is still very useful to be able to use a GFileOutputStream with GExiv2.

When GNOME Photos needs to export an image to a file, it ends up with a GeglBuffer containing the processed pixels and a GFileOutputStream obtained from g_file_create or g_file_replace. It encodes the GeglBuffer as a JPEG or PNG to the GFileOutputStream, and then uses GExiv2 to copy the metadata over. If GExiv2 supported GIO streams, then I could rewind the GFileOutputStream and feed it to GExiv2. Since that's not possible, I have to carry both the stream and the GFile around in my code, so that once I done encoding to the stream, I can use the GFile's path to copy the metadata. That's why even though it is ultimately using a file, support for GIO streams is quite useful.

I believe GIMP has similar use-cases, which is why Mitch filed bug 732748
Comment 5 Jehan 2018-04-05 15:01:56 UTC
> If GFile is not giving a valid path on Windows, then that needs to be fixed (or worked around) anyway.

As far as we know (and also from what we could see from traces), the path returned by GFile was valid, simply it is UTF-8, which is expected from what I was told (apparently all paths are UTF-8 only on Windows for glib, this is the expected behavior). There is no bug here AFAIK.

The only issue was with g_win32_locale_filename_from_utf8() which failed to convert the filename, for which I will open a bug report (complementary to the current report).

For the rest, yes I understand and agree. And actually reading now bug 732748, it looks simply like a duplicate of the current bug. So I'll just close as duplicate. I guess Mitch forgot he opened this other one years ago.

*** This bug has been marked as a duplicate of bug 732748 ***