This is two things: a content selector to select items out of the various "siloed" apps (photos/documents/music/etc.), and a preview widget for content. Both can be embedded wherever needed, for example in the file chooser.
The basic form is
GtkWidget *gimme_content_selector (types = [ "photos", "documents"]); GList *gimme_selected_uris (ContentSelector *cs);
Internally, the various "siloed" apps need to provide their own custom UIs for a content selector. So, we need loadable GModules that implement a standard API for embedding.
Do siloed apps just register "I can provide photos" or "I can provide documents" based on well-known names for data types? Or do they register more specific things like "I can provide photos from Shotwell", and "I can provide music from Banshee" - which have both the generic names ("photos", "music") and the specific silo names ("Shotwell", "Banshee")?
The first option is prone to overengineering, since then what happens when you want to aggregate two providers of "photos", for example (and we can probably assume that users don't use more than one siloed provider for major data type, anyway). So, the second option is probably better and easier to implement.
To start with an API done right, look at the async patterns in GIO - in case the API needs to list a bunch of potentially slow things.
Interactive preview widget
GtkWidget *gimme_preview_for (uri);
A more fleshed out braindump of how this system could work can be found at the Preview page.
Non-interactive preview API
This may be as simple as modernizing the GnomeDesktopThumbnail API.
So, I've started to play a bit with writing a content chooser for a portal api for sandboxed apps. One thing I notice is that the content chooser is going to run behind the portal api, outside the sandbox. So, we can't just make it load code from other (possible sandboxed and untrusted) apps. My thought was that the alternatives in this scenario are to either just launch these content apps in a 'selection mode' (at the cost of having a separate window pop up over the content chooser, or invent some D-Bus api to get information about available content - reusing/extending the shell searchprovider API comes to mind... (Matthias)