[Sugar-devel] Making Read read everything [WAS: Re: FBReader]
Benjamin M. Schwartz
bmschwar at fas.harvard.edu
Tue Mar 17 18:28:34 EDT 2009
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sayamindu Dasgupta wrote:
> While the most elegant way to do this would be
> perhaps to have dynamic backends for Read, which would be loaded on
> demand, based on the format of the file being opened, this would be a
> non trivial exercise. (to begin with, for example, there are subtle
> differences with respect to pagination for different formats: eg,
> PDF/DJVU offers a very clear distinction between pages, while this can
> be quite flexible, or even non existent for a plain text file)
What you're saying is: both the user-interface and the rendering engine
need to change based on file type.
That's completely fine. There's nothing in the Activity system that
requires each Activity to have only a single GUI. It would be easy enough
to have Read start, look at the filetype, and then choose which GUI to use
(and let the GUI choose the backend).
The hard part is writing (and maintaining) all those separate GUIs. I
don't think it's worth it. Page-oriented documents (like PDF) can easily
be rendered in a continuous fashion; in fact, this is the default in Adobe
Acrobat Reader and Evince. Conversely, non-page-oriented formats can
easily be broken into pages, as is the default in ebook readers.
It seems to me that the best course of action, for long-term
sustainability, is to push support for these filetypes into evince
upstream, and also to improve our GUI in both page-flipping and
continuous-scrolling modes.
- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAknAJBIACgkQUJT6e6HFtqTljQCcCCsETCpdH+ehUSKws/QHlxfp
JZYAn17WDNyt9SkuHgXHVE1/hztjp005
=Lx36
-----END PGP SIGNATURE-----
More information about the Sugar-devel
mailing list