On Mon, 2011-05-16 at 11:39 +0100, Bastien Nocera wrote: > On Sun, 2011-05-15 at 21:50 +0200, Olav Vitters wrote:
> > > > 1. Evince is supposed to be a generic document viewer. Is there any > > overlap with Sushi? > > I would guess that Sushi should use evince libraries to implement > viewing for such documents. Yeah, it indeed already uses EvDocument and EvView to render PDF documents. > > 2. What about the file associations? You might want to easily view > > things, or actually work with the file (change it). How would this be > > handled? What would happen by default on a double click? > > Sushi doesn't handle "double-click" associations, it would only handle > the "preview" shortcut. It's not meant to replace the full applications. Yes; Sushi would never register itself as default application for any file type. This means double clicking a file would never open Sushi - you need an explicit different operation to trigger it (in Nautilus right now it triggers when pressing the spacebar). > There's 2 problems I'd like to see listed here, one is that Sushi should > use the mime-types exported by the "full" viewers (such that the video > or audio parts would use the same mime-types as Totem, same for evince), > the second is that the look and feel should also be shared with those > applications, to avoid clashing styles. Right now this is implemented for most of the viewers in git master: - for images we load at runtime the mimetypes supported by the GdkPixbuf loader - for PDF/PS/... documents we load at runtime the list of supported Evince backends - for audio and video I copy-pasted the mimetype list supported by Totem As for the look and feel, can you be more precise? Are you saying e.g. Sushi should not use a custom/dark theme if the application counterpart doesn't? The UI chrome for Sushi is *very* minimal - basically the only clickable elements are an OSD-toolbar that automatically fades out after no motion events are received in a timeout, and the close button, so it's hard to make it look like a full-fledged application (and it's not what the previewer is aiming for, too). Cheers, Cosimo _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list