Allan Day <allanp...@gmail.com> writes: > Matthias Clasen <matthias.cla...@gmail.com> wrote: >>> https://wiki.gnome.org/Projects/GTK%2B/Preview >> >> Hey, thanks for starting this discussion! > > Ditto! > >> I think the document would benefit from a section listing some >> expected use cases: where do we expect this preview to be used ? >> nautilus, filechooser - anything else ? Having that list will make it >> easier to judge whether the "embedding" api is suitable for all those >> cases. > > From a design point of view, nautilus and the file chooser (or future > incarnations of it) are the primary initial focus. Previewing could > also be interesting for the system sharing dialogs [1] (as a way to > check the identity of a content item, before it is shared). > > Theoretically, previewing would be interesting whenever an app wants > to provide a view of a content item - that could be useful for chat, > social messaging, mail, or download/transfer applications. However, I > haven't done any detailed work into how this would look. One question > in this area is whether applications would need to be able to change > the UI controls for the preview. > >> Also, it would be good to list some of the things that you expect to >> preview: documents, videos, music, images - anything else ? > > My understanding is that we would want to provide previews for as much > common content as possible. Things like contacts or presentations > could easily be added to the list.
And GTK+ print preview, since the current solution of launching evince-previewer is far from optimal. One important thing is that preview providers should be out of process, since unfortunately it's very easy to make things crash with buggy files (which are very common). That could be done by every provider, but if we force that at a higher level it would be much better. That would also ensure that preview providers don't block the UI main thread, assuming the communication with the provider processes will be always asynchronous unconditionally. >> Having >> that list will help to get a sense for the interactivity that will be >> required from the preview. > ... > > The UI present today in Sushi is a good reference point, and I would > expect similar controls to be provided by the new library. I have > promised UI designs for this. > > Allan > > [1] https://wiki.gnome.org/Design/OS/Sharing#Mockups > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462
signature.asc
Description: PGP signature
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
