"Recent documents" not shared between 2.10 and other programs

[ofnuts]

In Gimp 2.8, I could export a file, and find it in the "recent" documents in Firefox, for instance. With the 2.10 flatpak, this is no longer possible.

Investigation:

• Export file from 2.8
• Export file from 2.10
• Gimp 2.10 > File > Open: the Recently used list of the file selector shows only the file exported by 2.10
• Gimp 2.8 > File > Open: the Recently used list of the file selector shows only the file exported by 2.8

I find the 2.8 export listed in ~/.local/share/recently-used.xbel and the 2.10 one listed in .var/app/org.gimp.GIMP/data/recently-used.xbel

As a workaround, I tried using a soft link (ln -s ~/.local/share/recently-used.xbel .var/app/org.gimp.GIMP/data/recently-used.xbel), but this doesn't work, it seems the file is erased/recreated and this removes the link.

[TingPing]

That is expected really. Once GIMP moves to GTK3 with GtkFileChooserNative things would behave as expected.

[ofnuts]

When Gimp with GTK3 is out most of us will hopefully have moved to more recent Linux versions and won't need flatpak :) And I don't see what would be so different with GTK3, isn't the problem caused by the container-like execution of the code?

…

On 06/03/18 16:34, TingPing wrote: That is expected really. Once GIMP moves to GTK3 with GtkFileChooserNative things would behave as expected. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKVdvPYDeu8YfF4F7Of9wjyJ3j2UMjhaks5t4_QQgaJpZM4UYCD4>.

[TingPing]

When Gimp with GTK3 is out most of us will hopefully have moved to more recent Linux versions and won't need flatpak :)

Hah I wish, No everybody will still be on Ubuntu 18.04 in 2045.

And I don't see what would be so different with GTK3

It supports the Flatpak portal.

[Jehan]

@TingPing The main problem is that I don't think we will want to use GtkFileChooserNative. For one, we are using the extra widget concept (gtk_file_chooser_set_extra_widget()) and this is not an optional usage. Actually I have plans to go even further as there are many interesting features we need to implement regarding advanced export. We are also using GtkFileFilter-s. These features are not supported with the portal.

Now I could imagine how we could reimplement our file choosers with GtkFileChooserNative (basically we'd have to implement our own custom widget which would implement the advanced features and would in turn call GtkFileChooserNative for path choosing). Yet the idea doesn't enchant me. That is very cumbersome (one more step for people when exporting images), make dev/maintenance bigger (own widget creation instead of simply reusing a generic widget) and makes testing much heavier (I can foresee the bug reports coming for Windows and macOS and our impossibility to easily reproduce!).

Also last we mentioned this on IRC, Mitch was absolutely not liking the idea of using native file choosers.

Bottom line: not sure at all the problem will ever get fixed even in GIMP 3. It would be much nicer that the GTK+ file chooser could support the flatpak portal for file choosing without going for this native GUI thing.

[TingPing]

You can still use file filters, but yes that is disappointing.

[brunvonlope]

Seems that @Jehan changed his mind regarding native file choosers: https://gitlab.gnome.org/GNOME/gimp/-/issues/1830#note_1913943

[Jehan]

I change my mind on a lot of things, but this is not one of these (even though I can see how it may look that way with above comment). It's rather that the design which I had in my head (and which I mention in my comment) evolved and got refined with time. I believe the export process may even be a lot better in some ways eventually. But it's not an easy project. So that's for after GIMP 3.

[brunvonlope]

So, I understood Issue 1830 wrong. I concluded that you was planing to have native file choosers.

[Jehan]

We are. That's what I meant. But we just can't just replace it simply and be done. It needs proper redesign not to lose features (and we'll take the opportunity to improve the whole export abilities much further, which is something I've been planned to work on for years).

[brunvonlope]

we just can't just replace it simply and be done.

I know. I was just making a update on this issue regarding the move to native dialogs (with the proper adaptations) 🙂