Web lists-archives.com

Re: RFC: GtkPreview library




Allan Day <allanpday@xxxxxxxxx> writes:

> Matthias Clasen <matthias.clasen@xxxxxxxxx> 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@xxxxxxxxx
> 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

Attachment: signature.asc
Description: PGP signature

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-devel-list