Bug 188959

As for default dir, should probably default to
xdg-user-dir PICTURES
(and not home), at least.

Rex, we are trying to retrieve standard dirs with KGlobalSettings::picturesPath() or QDesktopServices::storageLocation(QDesktopServices::PicturesLocation).
Unfortunately this does not work on some distros (returns HOME)

Syam: Yes our first run dialog has quite a few weaknesses. Alas, writing dialogs is no great fun for me.

Thanks for the clarification, I'll see if I can find out what's going wrong (at least on fedora anyway).

Just a piece of information, I dont have a 'Pictures' folder in my home dir. I usually delete those directories immediately after I install Fedora.

Marcel,

On new First Run Assistant, on last page, i can ask to user if he want to scan collection now, or later using "Tool/Scan for New Items". There is something special to do for DB viewpoint ?

Gilles

(In reply to comment #0)
> 2. OR - avoid the full directory scan. Ask the user to select directories to
> scan later (much like adding directories to Amarok collection).

At least when digiKam is started, you can disable the scanning of the directories in the setup dialog. But this is not what you wanted of course.

Gilles,
maybe we should disable this option per default and ask in the assistant:

1. Scan now (first initial scan)
2. Scan on startup

So you can choose between those two options.

Andi

I agree with Andi.
There is no sense in starting for the first time without a collection scan - the app is empty and useless!
We should ask to scan now (with a warning that it may take a while), or offer to quit and scan when starting again.
(I also do not like the option to disable scanning on startup as well, I dont see any sense in that)

?? Huh? I wrote my answer two hours ago, it has been added now? Well... I guess B.K.O. is on holiday, too :-)

Marcel, Andi,

At first run, there is many possible cases:

1/ Collection is new. No DB version 3 or 4. DB need to be created at least.

2/ Collection come from digiKam < 0.10 : DB need to be converted at least. 

3/ Collection is already referenced with digiKam 0.10 : at least, DB is take as well.

For case 1/, if we don't scan at first run, No item will be visible.
For case 2/, if we don't scan at first run, Only items referenced to DB version 3 will be visible.
For case 3/, if we don't scan at first run, Only items referenced to DB version 4 will be visible.

Do you see any problems with these workflow ?

Gilles

(In reply to comment #7)
> There is no sense in starting for the first time without a collection scan -
> the app is empty and useless!
It's still useless if it takes ages to scan a directory with large number of images, and no way to stop it. Not to mention that subsequent application startup will have the same behaviour, unless you delete the configuration files.

> We should ask to scan now (with a warning that it may take a while), or offer
> to quit and scan when starting again.
That'd be good.

Gilles:

Oh yes, look at AlbumManager::changeDatabase. It's similar. Even seven different cases to handled there :-(

For your cases:
1) Create an empty database with no album root is possible, but that's really pretty useless. But yes you can do that if someone really wants. Hm, maybe it's not possible because a dialog will pop up with the setupcollection page.
2) Conversion always includes a collection scan. No way around that. Convert&Scan or dont convert. That's because there are conversion steps first, then the scan, followed by more conversion steps, followed by dropping old tables.
3) If there is a digikam4.db already, we really need no full collection scan. In this case, it's not necessary to add album roots!

While not directly on-topic of the original bug report:
it might generally be useful to add a   
--no-scan option and a --scan-only dir1 dir2 ....option.

Best, Arnd

To Marcel #11

Damned, it's complex.

I can provide a bool flag if user won't to scan at first startup, and pass it to AlbumManager::setDatabase() call from main.cpp. But, in AlbumManager, some code need to be added to manage all possible cases to drive this flag.

I think it's dangerous to not convert DB v3 and work. 

Also, What user can do if no items are displayed from iconview / folderview in case of no scan of unregistered collection. This is a non sence for me.

The message must be clear in Assistant. No scan can give an unsuitable interface.

Gilles

Resume of IRC talk between me and Marcel yesterday evening to solve this file:

SOLUTION:
- After last page of assistant, scan is processed.
- We show progress dialog and we have a cancel button.
- User can stop scan when he want.
- DB considérations are preserved : DB conversion/creation are done just before to show progress dialog.
- If user stop scanning, it will begin again on next startup.

PROBLEM:
- if cancel button is pressed, dialog is closed, but scan continue in background.
- all debug message from scan process are still in the console.

TODO:
- ScanController::cancel() method is not implemented.
- Also missing to stop CollectionScanner in this case.

Gilles Caulier

SVN commit 962420 by mwiesweg:

Allow to cancel CollectionScanner and SchemaUpdate operations.
They will now query an observer to continue or cancel.

CCBUG: 188959

 M  +53 -3     collectionscanner.cpp  
 M  +11 -101   collectionscanner.h  
 M  +11 -4     collectionscannerobserver.h  
 M  +71 -13    schemaupdater.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=962420

SVN commit 962421 by mwiesweg:

Add methods to abort the schema update at first startup (includes the initial collection
scan for images imported from older db versions)
or cancel the complete scan at normal startup (including the scan at first startup
when starting with an empty database)

CCBUG: 188959

 M  +41 -0     scancontroller.cpp  
 M  +14 -2     scancontroller.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=962421

SVN commit 962513 by cgilles:

more informations about first scan process, especially if user cancel this operation at the first run
CCBUGS: 188959

 M  +4 -3      startscanpage.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=962513

Marcel,

Are you tried with a huge collection, without a DB 4 file ? If you press cancel,  scan continue again in background.

Gilles

Marcel,

If you kill digiKam during First Scan (because progress dialog Cancel button do not stop this operation), at next session, digiKam restart again collection scanning. But in this case, Progress dialog is not used : Splashscreen appears instead... As there is no progress bar in splash, this can be very annoying, especially with huge collection. 

Gilles Caulier

> Are you tried with a huge collection, without a DB 4 file ? If you press
> cancel,  scan continue again in background.

Yeah that's because the cancel button of DProgressDialog does nothing. There is a protected slotCancel() that checks for allowCancel, which is true per default, but then it just closes. It should emit a signal there, or how's that supposed to work?
Btw, was this with a DB 3 file, or just starting from an empty dir?

For comment #19: You can never keep a user from killing the app ;-) Perhaps the progress dialog should appear (and splash be hidden) after a longer amount of time, like 15-30s?

(In reply to comment #20)
> Perhaps theprogress dialog should appear (and splash be hidden) 
> after a longer amount of
> time, like 15-30s?

Then won't the user be completely clueless for the 15-30s?

To Marcel, #20,

Ok, a signal must be sent with Cancel button. I take a look.

From my test, DB v4 file have been removed before to restart digiKam. My collection is huge with full of RAW files (20Gb)

>Perhaps the progress dialog should appear (and splash be hidden) after a longer >amount of time, like 15-30s?

I think the progress dalog must be displayed at startup until initial scan is complete. I user cancel scan, at next session it must see progress dialog again.
Why ? because this process can take a while. Splash is not adapted for that.

If scan is complete, well at next session splash can be displayed, because we only check for new items. It's really faster.

This is want mean that a flag must be registered somewhere (rc file?) to check if initial scan is complete or not...

Gilles

Marcel,

with my last commit #962987, now scancontroller handle cancel button, but it's not enough : scan continue with splashscreen open...

Gilles

SVN commit 963038 by mwiesweg:

Also try to abort initial scan on cancel (both methods are a no-op if not running)
Show progress dialog in spite of active splash when initial scan is not marked.

CCBUG: 188959

 M  +6 -2      scancontroller.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=963038

Marcel,

It work better now. but it still a litlle problem.

After running assistant, initial scan start. I stay a little an press cancel. dialog is closed and splash appears, but not alone... the progress dialog is back again... and initial scan is back.

If i press Cancel again, initial scan is stoped and digiKam appears.

I stop digiKam and restart it. initial scan is back as espected. If i wait until scan is complete, closing and restarting digiKam, all start speedly...

Gilles

MArcel,

Are you seen my previous message there ?

Gilles

Whenever you start digikam it will scan. If you cancel, it will scan the next time.(*) If you cancel again, it will scan the third time. I think that's ok because using digikam is useless without an initial scan.
The alternative is to quit if cancel is pressed in the first run assistant.

Marcel,

No, you misunderstand me. Look below:

1/ "After running assistant, initial scan start. I stay a little bit and a press cancel. Dialog is closed and splash appears, but not alone... the progress dialog is back again... and initial scan is back."

This is appears on the first start of digiKam, the _same_ session in fact. I do not stop and restart yet digiKam. I think it's due of my DB path as already a DB v4 file with more than one root album set insinde.

2/ "If i press Cancel again, initial scan is stoped and digiKam appears."

Well, here now, it look  the good behavor. the problem is why user need to press 2 time on Cancel...

3/ "Now, I stop digiKam and restart it. initial scan is back as espected. If i wait until scan is complete, closing and restarting digiKam, all start speedly..."

For this one, of course all is fine...

Gilles

Ah.
I think the first scan is done from albummanager.cpp:674, the second one is done from digikamapp.cpp:167.
The second one is the regular call. I am thinking about removing the first call.

SVN commit 977533 by mwiesweg:

Remove call to collection scan. This branch is taken after running the first run wizard.
A second collection scan will be triggered afterwards from DigikamApp.
User need not press Cancel twice.

CCBUG: 188959

 M  +2 -1      albummanager.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=977533

Thanks Marcel, Fixed now. I close this file...

Gilles Caulier