[Digikam-devel] [Bug 133590] New: Usability: Walking through photos using image View (F3)

[krienke]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133590         
           Summary: Usability: Walking through photos using image View (F3)
           Product: digikam
           Version: unspecified
          Platform: SuSE RPMs
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: wishlist
          Priority: NOR
         Component: general
        AssignedTo: digikam-devel kde org
        ReportedBy: krienke uni-koblenz de


Version:           0.9.0beta (using KDE KDE 3.5.4)
Installed from:    SuSE RPMs

In digikams main window one can preview images by pressing F3. So instead of the icons one sees an enlarged version of only one photo.

However changing from one photo to another in this view mode is not optimal at the moment. Three things happen in such a photo change:
1. The old photo disappears
2. A blinking Text "Preview extraction in progress is shown.
3. After a short while the next photo is shown.

This process especially the blinking text can make one quite nervous:-) and is in my eyes not usefull.

When changing from one photo to another the last photo should remain on the screen until the next one has been loaded (avoiding a white screen). Only the cursor should change to an hourglass to show that something is happening. This way watching the  the photos would be more smooth than it is now.

Rainer
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133590         
caulier.gilles free fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|general                     |Albums GUI
            Summary|Usability: Walking through  |Usability: Walking through
                   |photos using image View (F3)|photos using image View (F3)
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

> This process especially the blinking text can make one quite nervous:-)
> and is in my eyes not usefull.

and it does take too long IMHO to get to the next image.
At least it still does feel slow, for example in comparison to
gqview (which does a pre-fetching of the next image).

> When changing from one photo to another the last photo should remain on the screen until the next one has been loaded (avoiding a white screen). Only the cursor should change to an hourglass to
> show that something is happening. This way watching the
> the photos would be more smooth than it is now.

What gqview does (if the next image has not yet already been
loaded in the background, e.g. when trying to go through many images
too quickly) is  to incrementally display
the new image starting from the top.
By this it is at least possible to decide earlier to move on or not.
Not sure whether this is possible with the widget used for the display.

(In addition a time-line type of view with thumbs at the bottom,
as eg. in Adobe Bridge might be useful)

Anyway, digikam is getting better and better - amazing work!

Best, Arnd
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133590         




------- Additional Comments From arnd.baecker web de  2006-09-05 19:21 -------
> This process especially the blinking text can make one quite nervous:-)
> and is in my eyes not usefull.


and it does take too long IMHO to get to the next image.
At least it still does feel slow, for example in comparison to
gqview (which does a pre-fetching of the next image).

> When changing from one photo to another the last photo should remain on the screen until the next one has been loaded (avoiding a white screen). Only the cursor should change to an hourglass to
> show that something is happening. This way watching the
> the photos would be more smooth than it is now.


What gqview does (if the next image has not yet already been
loaded in the background, e.g. when trying to go through many images
too quickly) is  to incrementally display
the new image starting from the top.
By this it is at least possible to decide earlier to move on or not.
Not sure whether this is possible with the widget used for the display.

(In addition a time-line type of view with thumbs at the bottom,
as eg. in Adobe Bridge might be useful)

Anyway, digikam is getting better and better - amazing work!

Best, Arnd
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133590         




------- Additional Comments From caulier.gilles free fr  2006-09-05 21:14 -------
> and it does take too long IMHO to get to the next image.

This is true about JPEG images, but not with all RAW files and all PNG/TIFF files saved by image editor. The kio-slave use the reduced embedded image to render preview.

Of course the same way need to be done to use Makernote preview embedded in JPEG files using Exiv2. It's still todo.

>What gqview does (if the next image has not yet already been
>loaded in the background, e.g. when trying to go through many images
>too quickly) is  to incrementally display
>the new image starting from the top.

A cache management need to be done. Still todo.

>In addition a time-line type of view with thumbs at the bottom,
>as eg. in Adobe Bridge might be useful

Easy todo using the thumbbar from showfoto. If we have some free time, we will done later.

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[ord-2]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133590         




------- Additional Comments From o.r-d laposte net  2006-09-06 12:57 -------
I promissed some weeks ago to open an bug report on the blinking stuff. but I forgot so here is the last mail on the subject
> The best implementation I have seen yet. is the one in eofg or showfoto
> > with a progress bar

Is not possible because i don't have a progress feedback from the preview
extractor kioslave. The Showfoto/Image Editor loading part is completly
different and of course can do it.

> > I would suggest writing the "preview
> > extraction in progress " under or over the image instead of taking the
> > image away.

>Hum this is my proposal : delayed the blink effect (for example 500ms). If a
>preview is found, nothing will appear. If no preview is available, the whole
>image is loaded and it can take a while. In this case the blink effect will
>apppear...
>
> If you is agree with this rule, please make a new file in B.K.O, we will do
>it later the first beta1, because we have planed to do this release during
>next week with Marcel, and we try to fix the last know bugs actually.
>
I still think the blink stuff is a bad ideas. I would prefer a fake progressbar
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[krienke]

Am Mittwoch, 6. September 2006 12:57 schrieb ord:
> >Hum this is my proposal : delayed the blink effect (for example 500ms). If
> > a preview is found, nothing will appear. If no preview is available, the
> > whole image is loaded and it can take a while. In this case the blink
> > effect will apppear...
> >

I also do *not* think that blinking is a good way to tell the user something
is happening. I am personally not aware of any application that uses a
blinking text for this purpose. This is always done by either a progress bar
or simply by changing the cursors shape.  Since the user is probably not
interested to know if the displayed image is extraced from the preview
section or from the original image it would make no sense to make digikam
behave differently in these two situations. The user I guess, simply wants to
see the photo as fast as possible.

Rainer
--
---------------------------------------------------------------------------
Rainer Krienke, Universitaet Koblenz, Rechenzentrum, Raum A022
Universitaetsstrasse 1, 56070 Koblenz, Tel: [phone], Fax: -1001312
Mail: [hidden email], Web: http://www.uni-koblenz.de/~krienke
Get my public PGP key: http://www.uni-koblenz.de/~krienke/mypgp.html
---------------------------------------------------------------------------

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[krienke]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133590         




------- Additional Comments From krienke uni-koblenz de  2006-09-06 13:19 -------
Am Mittwoch, 6. September 2006 12:57 schrieb ord:
> >Hum this is my proposal : delayed the blink effect (for example 500ms). If
> > a preview is found, nothing will appear. If no preview is available, the
> > whole image is loaded and it can take a while. In this case the blink
> > effect will apppear...
> >


I also do *not* think that blinking is a good way to tell the user something
is happening. I am personally not aware of any application that uses a
blinking text for this purpose. This is always done by either a progress bar
or simply by changing the cursors shape.  Since the user is probably not
interested to know if the displayed image is extraced from the preview
section or from the original image it would make no sense to make digikam
behave differently in these two situations. The user I guess, simply wants to
see the photo as fast as possible.

Rainer
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133590         




------- Additional Comments From caulier.gilles free fr  2006-09-08 16:49 -------
SVN commit 582194 by cgilles:

digiKam from trunk : image preview widget : do not run a blinking text during image loading. Toggle mouse cursor to busy instead.
CCBUGS: 133590

 M  +21 -56    imagepreviewwidget.cpp  
 M  +0 -1      imagepreviewwidget.h  


--- trunk/extragear/graphics/digikam/digikam/imagepreviewwidget.cpp #582193:582194
 @ -40,6 +40,7  @
 #include "albumsettings.h"
 #include "imagepreviewjob.h"
 #include "imagepreviewwidget.h"
+#include "imagepreviewwidget.moc"
 
 namespace Digikam
 {
 @ -50,13 +51,9  @
 
     ImagePreviewWidgetPriv()
     {
-        previewBlink      = false;
-        blinkPreviewTimer = 0;
         previewJob        = 0;
     }
 
-    bool                          previewBlink;
-    
     QString                       path;
 
     QPixmap                       pixmap;
 @ -64,15 +61,12  @
     QImage                        preview;
     
     QGuardedPtr<ImagePreviewJob>  previewJob;
-    
-    QTimer                       *blinkPreviewTimer;
 };
 
 ImagePreviewWidget::ImagePreviewWidget(QWidget *parent)
                   : QFrame(parent, 0, Qt::WDestructiveClose)
 {
     d = new ImagePreviewWidgetPriv;
-    d->blinkPreviewTimer = new QTimer(this);
     setBackgroundMode(Qt::NoBackground);
     setSizePolicy(QSizePolicy::Expanding, QSizePolicy::Expanding);
     setFocusPolicy(QWidget::StrongFocus);
 @ -81,9 +75,6  @
     setLineWidth(0);
     
     // ---------------------------------------------------------------
-    
-    connect(d->blinkPreviewTimer, SIGNAL(timeout()),
-            this, SLOT(slotPreviewBlinkTimerDone()));
             
     connect(ThemeEngine::instance(), SIGNAL(signalThemeChanged()),
             this, SLOT(slotThemeChanged()));
 @ -97,8 +88,6  @
         d->previewJob = 0;
     }
 
-    d->blinkPreviewTimer->stop();
-
     delete d;
 }
 
 @ -106,9 +95,8  @
 {
     if (path == d->path) return;
 
-    d->path              = path;
-    d->previewBlink      = false;
-    d->blinkPreviewTimer->start(200);
+    setCursor( KCursor::waitCursor() );
+    d->path = path;
 
     if (!d->previewJob.isNull())
     {
 @ -127,19 +115,10  @
     emit previewStarted();
 }
 
-void ImagePreviewWidget::slotPreviewBlinkTimerDone()
-{
-    d->previewBlink = !d->previewBlink;
-    updatePixmap();
-    repaint(false);
-    d->blinkPreviewTimer->start(200);
-}
-                
 void ImagePreviewWidget::slotGotImagePreview(const KURL&, const QImage& preview)
 {
-    d->blinkPreviewTimer->stop();
-    d->preview    = preview;
-    d->pixmap     = QPixmap(contentsRect().size());
+    d->preview = preview;
+    d->pixmap  = QPixmap(contentsRect().size());
 
     // It is very important to kill the thumbnail job properly
     // so that is frees its shared memory. Otherwise the memory
 @ -152,23 +131,23  @
 
     updatePixmap();
     repaint(false);
+    unsetCursor();
     emit previewComplete();
 }
 
 void ImagePreviewWidget::slotFailedImagePreview(const KURL&)
 {
-    d->blinkPreviewTimer->stop();
-
     if (!d->previewJob.isNull())
     {
         d->previewJob->kill();
         d->previewJob = 0;
     }
 
-    d->preview    = QImage();
-    d->pixmap     = QPixmap(contentsRect().size());
+    d->preview = QImage();
+    d->pixmap  = QPixmap(contentsRect().size());
     updatePixmap();
     repaint(false);
+    unsetCursor();
     emit previewFailed();
 }
 
 @ -179,35 +158,23  @
 
     if (!d->path.isEmpty())
     {
-        if (!d->previewJob)
+        // Preview extraction is complete...
+        
+        if (!d->preview.isNull())
         {
-            // Preview extraction is complete...
-            
-            if (!d->preview.isNull())
-            {
-                QPixmap pix(d->preview.smoothScale(contentsRect().size(), QImage::ScaleMin));
-                p.drawPixmap((contentsRect().width()-pix.width())/2,
-                             (contentsRect().height()-pix.height())/2, pix,
-                             0, 0, pix.width(), pix.height());
-            }
-            else
-            {
-                // ...or failed...
-
-                p.setPen(QPen(Qt::red));
-                p.drawText(0, 0, d->pixmap.width(), d->pixmap.height(),
-                           Qt::AlignCenter|Qt::WordBreak,
-                           i18n("Cannot display image preview!"));
-            }
+            QPixmap pix(d->preview.smoothScale(contentsRect().size(), QImage::ScaleMin));
+            p.drawPixmap((contentsRect().width()-pix.width())/2,
+                            (contentsRect().height()-pix.height())/2, pix,
+                            0, 0, pix.width(), pix.height());
         }
         else
         {
-            // Preview extraction under progress
-            
-            p.setPen(QPen(d->previewBlink ? Qt::green : Qt::darkGreen));
+            // ...or failed...
+
+            p.setPen(QPen(Qt::red));
             p.drawText(0, 0, d->pixmap.width(), d->pixmap.height(),
-                       Qt::AlignCenter|Qt::WordBreak,
-                       i18n("Preview extraction in progress..."));
+                        Qt::AlignCenter|Qt::WordBreak,
+                        i18n("Cannot display image preview!"));
         }
     }
     else
 @ -253,5 +220,3  @
 }
 
 }  // NameSpace Digikam
-
-#include "imagepreviewwidget.moc"
--- trunk/extragear/graphics/digikam/digikam/imagepreviewwidget.h #582193:582194
 @ -73,7 +73,6  @
     
     void slotGotImagePreview(const KURL&, const QImage& preview);
     void slotFailedImagePreview(const KURL&);
-    void slotPreviewBlinkTimerDone();    
     
 private:
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133590         
caulier.gilles kdemail net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE



------- Additional Comments From caulier.gilles kdemail net  2006-12-11 15:00 -------
Blinking problem with preview mode is fixed.

Preview cache still TODO.

I tag this file like a dupplicate than B.K.O 132047 witch talking about this subject.

Gilles

*** This bug has been marked as a duplicate of 132047 ***
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel