Re: RFC: GtkPreview library

Allan Day <allanpday gmail com> writes:

Matthias Clasen <matthias clasen gmail com> wrote:

Hey, thanks for starting this discussion!


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

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.

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.


gtk-devel-list mailing list
gtk-devel-list gnome org

Carlos Garcia Campos
PGP key:

Attachment: signature.asc
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]