Bug 166622

Created attachment 26147 [details]
Screenshot illustrating problem

This is invalid, please hover over the fields to see what they actually mean. But I will not close it right now, maybe I misunderstood you.

Created attachment 26148 [details]
mockup

I see now what they mean. To avoid user confusion, then, a third field should
be added that is a progress meter (much larger than the other two). See mockup.

There is a progress bar... I will close this now.

The progress bar runs from 0% to 100% in the status bar and then disappears. Once the import is completed there is no indication that anything was done, other than the checkmarks near each photo. Adding to the confusion are the two progress bars at the bottom of the window which do not indicate the status of the import.

My proposed fix is to make the progress bar separate from the status bar and to have the progress bar open at all times. Especially after the import is complete.

>My proposed fix is to make the progress bar separate from the status bar and to >have the progress bar open at all times. Especially after the import is complete. 

No. We don't need a separate window to host a progress bar. this last one is must be hosted to statusbar to be homogenous with all other main window in digiKam (for ex, editor or album gui)

Gilles Caulier

See it the other way around: If no progress bar is there, you are done :-)

Andi

On Wednesday 16 July 2008 10:45:49 Gilles Caulier wrote:
[bugs.kde.org quoted mail]

> No. We don't need a separate window to host a progress bar. this
> last one is must be hosted to statusbar to be homogenous with all
> other main window in digiKam (for ex, editor or album gui)

Those other windows don't have activities that take time to finish. Well, actually, they do: the Rebuild Thumbnails activity (Which has a popup progress bar that stays at 100% when done).



> See it the other way around: If no progress bar is there, you
> are done

That is not very intuitive for users.



I'll now propose a more general solution, and interface change. The way digikam now works is that the main window has two functions:
1) Thumbnails mode
2) View mode

Other modes,such as the Image Editor and Import, are handled in popup windows. How about incorporating these popup windows into the main Digikam window, which would now have four modes:
1) Thumbnails mode
2) View mode
3) Image Editor mode
4) Import mode

In import mode, the progress bar would pop up just like the Rebuild Thumbnails progress bar pops up.

> Those other windows don't have activities that take time to finish. Well,
> actually, they do: the Rebuild Thumbnails activity (Which has a popup
> progress bar that stays at 100% when done).


Yes, they have. Tagging and rating of images for example use progress bar in 
the main window.
All filters use a progress bar. I think it is not very nice to close a popup 
progress bar window all the time an action was triggered.

>
> > See it the other way around: If no progress bar is there, you
> > are done
>
> That is not very intuitive for users.


Why not? Nearly all apps I use work this way, what is so confusing about this?

> I'll now propose a more general solution, and interface change. The way
> digikam now works is that the main window has two functions: 1) Thumbnails
> mode
> 2) View mode
>
> Other modes,such as the Image Editor and Import, are handled in popup
> windows. How about incorporating these popup windows into the main Digikam
> window, which would now have four modes: 1) Thumbnails mode
> 2) View mode
> 3) Image Editor mode
> 4) Import mode


That has been discussed before and I don't think it will be changed, ever. The 
good thing about these multiple windows is that you can work on multiple 
screens / virtual desktops (like in Gimp). You said before the digiKam 
interface is too overloaded with tabs / functions. But bringing the image 
editor into the main window will expand it even more... the menu bar will 
explode :-)

Andi

I'm totally agree with Andi,

Another argument is about multithreading: camera interface for ex, download/upload to/from camera/computer using a separate thread. You can continue to use albumgui during transfert operations. If you embed cameragui into main interface, this will be not possible anymore.

Gilles Caulier

Can this one be closed now...?

yep, as invalid...

Gilles

Closing this now...

The situation still exists that users have no obvious indication that their images have finished imported. I may not have succeeded in proposing a solution that Andi and Gilles like, however, that does not mean that a solution does not exist. At a bare minimum, keep the progress bar open until the user clicks OK, as with the Rebuild Thumbnails dialog.

Well I guess this can be done... Gilles? what do you think? 

I changed the behavior and I must say, I don't like it.
The problem is that the progress bar will be shown all the time now.
I made changes in CameraUI::slotBusy, this is where the progress bar is hidden 
after a job has been done. But now the progress bar stays open when creating 
thumbnails etc, too.
I think the current solution is the best, when downloading you get messages 
like "fetching image xxx" or something like this, when it is ready and the 
progress bar is gone, it will read "Ready".
This works best (at least for me) in KDE3 and KDE4 version.

Andi

> I think the current solution is the best, when downloading you get
> messages like "fetching image xxx" or something like this, when it is
> ready and the progress bar is gone, it will read "Ready".
> This works best (at least for me) in KDE3 and KDE4 version.

Agree with Andi. Maybe this is not perfect solution but definitely the
best from suggested.

Dolphin has a similar disk-space progress bar. The text is "90% free". We could take inspiration from this, to make it clear what the permanent progress bar means.

Thanks, Andi. I have a calculus exam tomorrow and afterwards I will install KDE 4.1rc1 and build the latest Digikam SVN.

As some people (namely, all four friends that I've shown Digikam 0.10 beta to, plus the wife and myself) prefer having a persistent dialog, and others (namely, everyone else posting here) prefer not too, could this be made optional?

Thanks. The work you guys do on Digikam is nothing short of amazing.