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 

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.


More information about the kde-core-devel mailing list