Re: One Remark To: Evince as universal "Viewer"

[Dennis Heuer <dh triple-media com>]

On Tue, 24 Feb 2009 01:11:19 +0300
"Nickolay V. Shmyrev" <nshmyrev yandex ru> wrote:
> Hi Dennis
> 
> I was excited about generic functionality apps long time ago. (another
> example I'd like to mention is a generic "convertor" so you can convert
> anything you can convert to anything else) but actually it's not so
> perfect idea for a several reasons:
> 
> 1. It's confusing for the user and not so easy for developer to maintain
> two different UI's for the same format.

i'm not shure how you count for *two* ui's. if we were talking about
commandline tools like expr i would understand the case. expr is for
comparing values and was extended to compare even string values. the
result is an ambivalent commandline that must be checked for in
scripts if using unknown input from the user. expr is really a dumm
exemplar of a *one size fits all* tool.

however, you seem to get my point wrong. i wasn't saying that evince
should also substitute my xine player. i already find supporting images
strange. the point i make is easy to argue for. a viewer is a viewer,
which is always only a nifty side-product because one could always
choose an editor for viewing files. however, people want nifty and fast
viewers because these are more handy or there is no editor at hand.
this said, viewers don't have to support forms, for example. it's nice
that evince can do, but this should better be done by a special viewer
for 'interactive' formats. yes, pdf is such a format but not in all
extends. this said, it can be treated by two different apps for two
different purposes. the only problem here is that there is no mime type
to classify pdf-form documents different.

however, a viewer is there so that you don't need an editor. it is not
there to view everything possible. this possiblilities have to be
classified, which means that there are viewers for vector formats,
viewers for media formats and viewers for interactive formats. it
doesn't matter if the document standard fits more categories. only the
file and what it was created for decides. a pdf-text document is
displayed by evince; a pdf-form document is treated by an interactive
viewer for such cases. there are *grey* documents crossing the borders
but the mime type should decide here, actually. it's left to the editor
to classify his document more correctly. as said, i know that this is
not proposed today but mime types weren't too two decades ago. this
shouldn't hold evince back from sticking to its use case and showing
*just everything that fits*, which includes oo.o documents in general
but excludes extra functionality of these documents.

possibly animation is fine for supporting flip charts etc, but i never
said that evince should allow editing embedded spreadsheets. displaying
them correctly would be nice but is an advanced feature for the future.
what i'd which here, though, is that evince informs the reader about
possible graphical incorrectnesses visually. this said, evince should
evolve with its formats. when i say that evince should also display oo.o
documents i only say that this is a long term goal of which those parts
have to be fulfilled first, which are most close to what evince is
already capable of. this is quite worthy already because oo.o-text
documents should already display fine. simple spreadsheets possibly
too. you understand what i mean?

the point that the user is confused by viewers is not valid from my
point of view. it might be valid for fully fresh desktop user's.
however, the wish for a specialized viewer comes from the user. it is
his natural demand he comes up with by himself over time.

and, if you read my text closely you know that i don't mean a general
plugin architecture like the browser or nautilus. don't know why people
want to read pdf's in those tools.

regards,
dennis