On Tue, 24 Feb 2009 01:11:19 +0300 "Nickolay V. Shmyrev" <[email protected]> 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 _______________________________________________ Evince-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evince-list
