But as soon I've added this feature to my TODO-list, I could not get this task out of my head... I recognized that obviously all nice pictures of this world seem to have frames: whether you go to an exhibition or take a look on a newspaper - nearly everywhere pictures have frames.
So Dolphin has now frames for picture previews too:
By the way: in Dolphin for KDE 4.1 the generating of previews is done more clever (or let's say: less stupid) than in the 4.0 version. Now the previews are generated for all visible items first like in KDE 3, not "randomly" like in KDE 4.0. This improves the felt performance a lot, as from the users point of view the previews are generated now immediately.
Please note that when you try SVN trunk that previews in general take a lot time in the debug version. Still there seems to be room for improvements when the previews are in the cache. KDE 3 is still faster in this regard, but we are working on it; I hope we can provide a faster solution for KDE 4.1.
38 comments:
I had the idea that you guys could maybe implement. The idea is to do a 2 pass picture generation.
The first pass (of all items, starting with the visible ones) is to check the cache and show the icons. This pass should be relatively speedy.
The files that have no pre-generated icon are not touched in this pass.
The second pass would then start generating the missing icons and show them.
Good idea? :)
@Thomas: it is already implemented this way in KDE 4.1. One minor difference to your proposal is that the passes don't differ between cached and non-cached versions. But as the cache anyhow is available for the whole directory, this does not really matter.
So the current approach is:
1. generate the previews for all visible items; if a cached version is already available, use it (if not: generate a preview and add it to the cache)
2. generate the previews for all invisible items; if a cached version is available, use it (if not: generate a preview and add it to the cache)
At last we get nice thumbnails for KDE too.... I have liked these on GNOME long time and now we just had it too :-D
Mayby then getting icon spacing little tigher too so there wouldn't be so much empty space ;-) (filled wish on bugs.kde.org).
Hey, cool work on Dolphin!
The slowness with Big-Directories was the only bad thing in 4.0 for me, good that it's fixed =)
Regards
Is the frame also drawn around svg previews?
Awesome. Always liked the frames on other systems. Nice work.
@Gissi:
> Is the frame also drawn around
> svg previews?
Yes, it is is shown for all image-mimetypes.
nice work,
is it also drawn in open/save-file dialogs ?
@anonymous:
> is it also drawn in
> open/save-file dialogs ?
Do you mean the preview pane right beside the item-view in the open/save-file dialogs?
If 'yes': no frame is drawn here currently
If 'no' and you mean the item-view itself: Currently in KDE 4.0 the open/save-file dialogs don't support previews inside the itemviews at all (although it would not be that much work to add this feature).
Oooh!
Could such a frame (probably a slightly different one, since they aren't quite images) be drawn for pdf files as well? They currently thumbnail oddly, since most have white backgrounds, and so does Dolphin.
@Anonymous:
> Could such a frame (probably a
> slightly different one, since
> they aren't quite images) be drawn
> for pdf files as well?
Technically it would be possible without problem. But currently the PDF thumbnail generator (not part of Dolphin itself) already adds some very small custom frames to PDFs - maybe a better approach would be fixing the thumbnail creator itself in this case.
ThumbCreator plugins can set a flag to draw frames. Why not re-use this mechanism? And if all image mime-types should have a frame drawn around them, shouldn't this be set by the plugin?
how does it look with dark color schemes?
@Oliver:
> And if all image mime-types should
> have a frame drawn around them,
> shouldn't this be set by the plugin?
Dolphin does not directly use the plugins, it uses the class PreviewJob for generating the previews. So PreviewJob would have to be extended to specify for which mime-types a frame should be drawn and also the ThumbCreator for images must be extended to support frames.
Also it is required that Dolphin resizes the generated previews to a smaller size and the frame must be added _after_ resizing, not on the original image.
Anyhow for sure it's worth to get discussed.
@K:
> how does it look with
> dark color schemes?
The frames respect the current color scheme. In the case of a dark scheme (e. g. black background, gray text) the frame is gray.
Does Dolphin already show thumbnails for videos or is it planned? It's one of the cooler features of Nautilus.
@anonymous:
> Does Dolphin already show
> thumbnails for videos or
> is it planned?
The creating of thumbnails in general is done outside the scope of Dolphin. Dolphin just requests from the KDE framework to get a thumbnail image for the current file. The "thumbnail framework" in KDE is very generic, so it's possible that a new application registers its thumbnail creator to the framework.
Long explanation, required for answering your question: if there is a videoplayer application in KDE 4.1 that provides a thumbnail creator, then Dolphin (and Konqueror) will be able to show video thumbnails :-) I guess DragonPlayer should provide this, but I have not tried it yet. Anyhow it is just a matter of time until the thumbnail creator for videos is ported to KDE 4 (maybe it has already been done).
Yay, thanks for the answer, I'm already looking forward to it :)
@anonymous:
> Does Dolphin already show
> thumbnails for videos or
> is it planned?
you may be not aware of this - konqueror in kde3.5 does create video thumbnails, if you install libarts-xine package
Are you sure that this is really a good idea? While it may look nice at first look I don't see any improvements in usability -- in fact drawing a frame could be some sort of highlighting one image, so it's more kind of one GUI element "wasted" for decoration
purposes.
Well, there could be one case where it's useful: To distinguish between the background of the picture and the background of the filemanager. But in this case I find the frame to obtrusive and would think a light dropshadow would be much more visually appealing.
And if you take a look how Apple (for example in iPhoto or and or Aperture) or other "picture handling programs" handle this, you'll see that it's exactly done this way: A shadow as unobtrusive indication of the image borders, and a frame as highlighting mark for selected images.
@Furanku:
> And if you take a look how Apple...
I had a look at Apple's Leopard version of Finder :-) In Finder the frames are drawn quite similar.
As you already said: adding a border is important especially for transparent images having only a tiny content. I've observed people that wanted to drop something into the viewport area and accidently dropped it above a transparent image as they could not see that the area was represented by the image. A border solves such usability issues...
Whether the frame is presented only as light dropshadow or whatever - this can be changed easily... The current style is quite similar to other file managers out there and for sure can be improved.
OK, when it comes to taste ... ;)
I still like the impression of an "physical picture" that really lays *on* the background better and more intuitive as a framed pikture that lays *in* the background, but well, we could discuss about that for hours, and in the end: You're the man ;)
Thanks for Dolphin! Esp. since I was among those who were not too happy to hear konqueror getting replaced as default filemanger back in those pre 4.0 days. Sorry, if those discussions were demotivating in your ears!
@Peter Penz about the "2 pass" suggestion of Thomas, I think that his point would be to split what you call the first pass, the preview of all visible items in two part:
1.a- first show all the visible item which have a cached version.
1.b- then show all the remaining visible item generating the preview.
Regards,
renoX
@renoX:
> I think that his point would be to
> split what you call the first pass,
> the preview of all visible items in
> two part:
> 1.a- first show all the visible
> item which have a cached version.
> 1.b- then show all the remaining
> visible item generating the preview.
I generally agree, but in practice the cache contains either all items of a directory or none. So there is no need splitting this into 2 passes: either 1.a is empty or 1.b is empty :-)
If somebody has time to improve this in the class PreviewJob of kdelibs, then it's fine. But from the Dolphin point of view it's not worth the effort as the result would be 100 % the same...
I've currently 92 open bugs and 79 open wishes for Dolphin, so I must concentrate on things that users will recognize ;-)
@Peter Penz: The author of a thumbnail plugin can set a flag in the .desktop file disabling thumbnail caching. This makes sense if the thumbnail generation is fairly quick, or if the file has a built-in preview thumbnail. There may be an advantage in deferring thumbnail creation/extraction until after cached images in this case.
Also about speed: I noticed when rooting around the thumbnailer service code that it tries KFileMetaInfo before ThumbCreator plugins. Now that KFileMetaInfo uses strigi, does it ever extract thumbnails?
PS I wrote a long-ish comment earlier, but it hasn't shown up. Did I lose it, or is it in a queue somewhere?
@Oliver: thanks for your additional informations, that's very interesting. I'm still quite new to KDE programming and am just a user of kdelibs - David Faure does all the tricky stuff :-)
> Now that KFileMetaInfo uses strigi,
> does it ever extract thumbnails?
I don't know honestly speaking. What I know for sure is that PreviewJob is a lot slower than in KDE 3 and I did not have the time yet for finding out the reason...
> PS I wrote a long-ish comment
> earlier, but it hasn't shown up.
> Did I lose it, or is it in a
> queue somewhere?
I've not enabled any confirmation for this blog for comments (-> no queue). It seems it has been lost :-(
I wouldn't say I know too much about the kde internals myself. I've just had a little experience from creating a thumbnailer plugin for my own purposes. And browsed around more of the code today to see how the magic happens.
Luckily for me, I kept the comment around in my clipboard. So:
"It looks like the ThumbCreator::Frames flag instructs the thumbnailing mechanism (which is used by PreviewJob) to draw a kind of frame round the preview, same way the ThumbCreator::Blend flag instructs to overlay the mimetype icon on the preview.
You can see this frame with e.g. text files, html files or pdfs. This isn't the same kind of frame as you've introduced in dolphin, it's more like a shadow effect.
The other part of the question I asked earlier is: who should decide which file types get frames drawn (especially for file types not yet invented)? When can Dolphin make a better decision than the authors of the thumbnailer plugin? When should dolphin use the Frames flag as a hint to draw its own frames?
If I were crazy, I might also ask whether it makes sense to request the thumbnailing mechanism to draw different kinds of frames - light or heavy drop shadows, dolphin style frames, strong dark borders, or just the bare preview. But I'm not crazy, and I anticipate that would cause trouble if weirdly framed thumbnails were created at dolphin's bequest, cached in the thumbnail directory and then viewed in nautilus, f'rinstance."
When I suggested the 2 pass system I had the following use case in mind (which I have seen quite often myself).
User has a dir of items (lets go for svgs) and then adds various rather large ones to the dir by doing an svn up.
Opening dolphin on this view will quickly show the already generated icons and then it will stall at the icons that are new. Only to continue to very quickly show the rest of the icons after the new one has been generated.
I think it is a huge improvement if the quick-to-show ones are shown immediately and the slow ones are delayed generated. Which makes the feedback much faster and responsive.
I understand it won't be on top of your list, plenty to do :) I've been walking around with this idea for a year at least myself. (after implementing it like I said in another piece of software)
Hope the use case helps :)
A little nitpicking regarding the frames dimensions: the right and lower side are one pixel fatter than the upper and left side. Looking closely at the screenshot I see this is due to a one pixel faint shadow on the right and bottom side of the picture. I think we can agree that this shadow is rather superfluous considering there's a frame around the picture already.
Maybe I'm late and it's fixed already, but in case it's not, please do so now. Thanks. ;)
@Datschge:
> the right and lower side
> are one pixel fatter than
> the upper and left side.
Ah, thanks for the hint, I was not aware about this. Seems that the inline image is shrinked one pixel too much... I'll fix this :-)
Cool, thanks for the quick response! =)
@Datschge: I've fixed the one-pixel issue a few minutes ago...
Yea, saw it at CIA as well. Considering this fix removed some code I guess this even speeds up the painting a little, doesn't it? =) Thanks again (and Happy Eastern)!
This "loading the viewable thumbnails first"-thing is nice. Gwenview in kde3 also implemented this and did this also very fast. I hope Gwenview for kde4 will implement this again (is not the case in kde-4.0x) and will be as fast as in the past. I prefer viewing pictures/thumbnails in external viewers.
Hi,
I visited your blog through Google and found it to be informative and interesting. Really it's a good blog, keep writing such a fantastic blog.
Further, if you need more help regarding Pictures Frames just logged on to the below link:
Poster Frames
Keep up the great work!
is the pdf preview working in your dolphin with suse 11 and kde 4.1?
@Be123: PDF previews should work since KDE 4.0 already. If it does not work there is maybe a package missing within your environment(Dolphin itself does not create the previews, this is delegated to plugins).
ThankYou, and thanks for David Faure, Aaron J. Seigo, Rafael Fernández López, Kevin Ottens, Holger Freyther, Max Blazejak, Michael Austin!
Thank You so mach for dolphin!
Post a Comment