http://www.3danim.de/images/kde/current-previews-with-text.png

Above is the link to an image showing some of the issues I have with the way 
previews currently work. These should be more more concrete than the previous 
mail.

To not let this drift off into unconstructive criticism, I'll try to point 
things out a bit more "let's do X in Y by doing Z"-style (well, maybe without 
the Z, as I don't know how things will be implemented technically) ;-)


- provide means to let applications register their own preview at some central 
instance; that way, whatever program is used for showing folder contents will 
not need to know all the different file formats, just where to get previews 
from; basically this encapsulates how previews work away from most of the 
system

- give applications full control over how previews are realized; some 
applications might need bitmaps, some vector / SVG, some video, etc.

- give applications full control over what is shown in a preview; nobody knows 
better than the application itself; there could of course be guidelines on 
what app-designers should put in and what not to put in

- a file manager is only responsible for displaying whatever preview there is 
registered

- only exception is, if there is no preview registered; then either try to 
create one (e.g. for simple things like images or PDFs) or show a generic 
icon (worst case)

- permit "cycling" pages for multi-page documents without opening a separate 
program

- whatever page of such a document is visible (on top), stays visible (doesn't 
jump back to page 1) when entering the folder a second time

- permit scaling the preview up to full-screen or near-full-screen


This should solve most of the issues pointed out in the image. E.g. if Amarok 
thinks that it would be best for users to see the cover art as a preview, it 
would register the cover art. If there was no cover available, Amarok might 
decide to instead show the music genre and the playlist the file is in. And 
so on. That way, users would always see the best possible representation of 
the file, thus they should be able to get the best possible context 
information out of it.

And not to forget, most of these points should be important for spacial file 
managers.


Cheers.

-- 
Markus Weiland
[EMAIL PROTECTED]
http://www.3danim.de
_______________________________________________
Appeal mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/appeal

Reply via email to