Hallo,
I have some more comments to the new file open dialog.
1. If no image is selected the preview area should display the "No preview" image with "No selection" as text.
2. Use thumbnails if they are available. That will make the preview faster, if the images are big.
3. Do not allow images to resize the preview area.
4. Look at the Gimp open dialog and make it look similar. ;-) http://hagemaenner.de/stuff/gimp/Gimp-2.1-Open-Image.png
MfG Tobias
- If no image is selected the preview area should display the "No
preview" image with "No selection" as text.
Agreed
- Use thumbnails if they are available. That will make the preview
faster, if the images are big.
Having tested it, I tend to disagree. My machine is not too fast, but the preview generation is surprisingly fast even for very complex files (fraction of a second even for the advanced tutorial). Opening the dialog itself takes longer. On the other hand on-the-fly previews have the advantage of being always up to date and leaving no garbage on the disk.
- Do not allow images to resize the preview area.
They do not resize it now. Except that when the filename of the image is too long - in that case it pushes the preview widget wide (at the expense of the file list). This must be fixed.
- Look at the Gimp open dialog and make it look similar. ;-)
Err, what advantages does it have that we don't? From the look of it, I'd say that ours is better if only due to the filename entry field.
- Use thumbnails if they are available. That will make the preview
faster, if the images are big.
That sounds right in theory at least, but I would not be terribly suprised if Inkscape was just as fast if not faster in many cases. (librsvg was and possibly still is faster than libpng).
Testing with an SVG that contains patterns, gradients, embedded images, lots of transforms and clones might help prove it holds true for larger more complex documents.
How can SVG+Raster graphics be faster than pregeneratd raster graphics? Does inkscape have some brilliant system of dropping detail when zoomed far out?
Having tested it, I tend to disagree. My machine is not too fast, but the preview generation is surprisingly fast even for very complex files (fraction of a second even for the advanced tutorial). Opening the dialog itself takes longer. On the other hand on-the-fly previews have the advantage of being always up to date and leaving no garbage on the disk.
The "garbage on disk" is intentional because it allows applications that do not understand SVG (or whatever else) to reuse the thumbnails (I realise SVG is not the best example because Nautilus can already preview SVG as can any GDKPixbuf capable application).
- Alan H.
Am So, den 08.08.2004 schrieb bulia byak um 19:47:
- Use thumbnails if they are available. That will make the preview
faster, if the images are big.
Having tested it, I tend to disagree. My machine is not too fast, but the preview generation is surprisingly fast even for very complex files (fraction of a second even for the advanced tutorial). Opening the dialog itself takes longer. On the other hand on-the-fly previews have the advantage of being always up to date and leaving no garbage on the disk.
I have an 6MB SVG image in my SVG folder and it took over half an hour to show the preview on my P800! It is even slow, if I browse some bigger PNGs. If you worry about not being up to date you can compare the timestamp in the thumbnail with the file date. And no, I don't think that thumbnails are garbage, as long as all programs use the same.
- Look at the Gimp open dialog and make it look similar. ;-)
Err, what advantages does it have that we don't? From the look of it, I'd say that ours is better if only due to the filename entry field.
I'm just speaking about the preview area. It has the "Preview" title, some space around the image, shows the file size and displays a folder icon, if you are an a folder an not on an image.
MfG Tobias
Tobias Jakobs wrote:
I have an 6MB SVG image in my SVG folder and it took over half an hour to show the preview on my P800! It is even slow, if I browse some bigger PNGs. If you worry about not being up to date you can compare the timestamp in the thumbnail with the file date. And no, I don't think that thumbnails are garbage, as long as all programs use the same.
How about this for a short-term fix: we fstat() the file, get its size, and only preview it if it is smaller than some arbitrary amount.
And maybe, also, we show the file size on the "No preview" image?
Thumbnails would be nice, but maybe that is something best left until later. Right now we are just trying to get it to work. ;-) I am afraid that this dialog can become a full-time project on its own, and steal time from other more productive work. If people really consider thumbnails important, then I think that this will require another volunteer programmer. After all, SVG Editing is the core purpose of Inkscape, and we still need to work toward spec compliance.
Bob
On Sun, 2004-08-08 at 17:44, Bob Jamison wrote:
How about this for a short-term fix: we fstat() the file, get its size, and only preview it if it is smaller than some arbitrary amount.
That seems sensible, although fstat() is not portable (at least not to Windows) ... probably you will need to fseek(..., 0, SEEK_END) and then use ftell() to determine the file's length.
-mental
MenTaLguY wrote:
On Sun, 2004-08-08 at 17:44, Bob Jamison wrote:
How about this for a short-term fix: we fstat() the file, get its size, and only preview it if it is smaller than some arbitrary amount.
That seems sensible, although fstat() is not portable (at least not to Windows) ... probably you will need to fseek(..., 0, SEEK_END) and then use ftell() to determine the file's length.
-mental
Ok, now it checks for file size > 1 MB.
Bob
Bob Jamison wrote:
Thumbnails would be nice, but maybe that is something best left until later. Right now we are just trying to get it to work. ;-)
XMP Tumbnail metadata chunk!!!
They generally embed a blob of Base-64'd JPEG data. And XMP was made to allow for quicker scanning of a file without needing to parse it whole as XML.
participants (6)
-
Alan Horkan -
Bob Jamison -
bulia byak -
Jon A. Cruz -
MenTaLguY -
Tobias Jakobs