Okular moving
Friedrich W. H. Kossebau
friedrich.w.h at kossebau.de
Fri Nov 17 11:40:26 GMT 2006
Hi Tobias,
Am Freitag, 17. November 2006 00:49, schrieb Tobias Koenig:
> When you try to merge editing of PDF documents and viewing of X other
> formats in one application you have always the problem that some
> features (e.g. insert/replace pages) is not available for all document
> formats, that is not just an usability problem but also a hint for bad
> design. Lets follow the UNIX philosphy, one tool for one task.
Our tools are KParts ;)
Inconsistent support for different formats with slighlty different
possibilities is typically for a lot of programs.
But would you propose: A Kate for each encoding, a Konqueror for each
kioslave, a Krita for each image format, a KWord for each document format
etc.?
Concerning viewers/editors:
I personally *strong word for not liking* it that I always have to start
another program to change something in a file I am just viewing (like
embedded in Konqueror). Now how usable and bad designed is this!
There are some file formats (ha, emphasize on the term file) for which there
are parsers and working memory representations and display algorithms that
are optimized to view documents. But for most (usually lightweight in size)
there is not. E.g. most KParts used in Konqueror are already KReadWriteParts
that are just used as KReadOnlyParts.
What about this: There would be different profiles, like viewonly and several
types of edit/manipulate. When viewing a text document and wanting to fix a
small bug/mistype the user can turn to edit profile, correct it in place and
then turn back to viewonly. Or scrap an image. Programs/parts only show the
menu entries which are assigned to a profile and adapt the input controller.
Editing/manipulating code is separated in plugins and loaded on demand (did
someone read toolet in this? ;)
Heck, even the file select dialog let's one manipulate the file system (delete
file, create directory, rename file)! The trick is that this is simpy not
prominent in the ui, after all the user is out to select a file(name).
And let's not forget that this is a technical discussion. The user does not
care about programs, libs etc, but about windows showing him his data and
letting him manipulate/view it. If windows for several file formats are drawn
and the user input is handled all by the same program is simply nonrelevant.
He just cares to have a pleasing und understandable, beautyful interface to
the system, which holds his virtual stuff.
Friedrich
More information about the kde-core-devel
mailing list