[digikam] [Bug 314441] New: Rename settings during import ignored

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=314441

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|3.1.0                       |3.2.0

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[xilef4040]

https://bugs.kde.org/show_bug.cgi?id=314441

[hidden email] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #36 from [hidden email] ---
I can confirm that the auto-rotation of JPEGs during import does not work with
digikam 3.2.0 on KDE 4.10.2, Kubuntu 13.04.

Additionally, the date-based creation of subfolders converts custom text in
single quotes to lowercase. E.g. using the pattern "yyyy-MM-dd 'Sunset' "
results in folder "2013-06-01 sunset" being created. Instead, the folder should
be called "2013-06-01 Sunset".

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[CABPSOFT - Camilo Bohórquez]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #37 from CABPSOFT - Camilo Bohórquez <[hidden email]> ---
The bug still in 3.2.0 (At the image download, rename settings is ignored).

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

https://bugs.kde.org/show_bug.cgi?id=314441

Jo Scheuchenpflug <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #38 from Jo Scheuchenpflug <[hidden email]> ---
Bug (renaming does not work when importing) still present in 3.2.0 with
3.7.10.-1.11-desktop Opensuse 12.3
but renaming started from BatchQueueManager works fine.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Rüdiger Härtel]

https://bugs.kde.org/show_bug.cgi?id=314441

Rüdiger Härtel <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #39 from Rüdiger Härtel <[hidden email]> ---
(In reply to comment #33)
> Created attachment 79794 [details]
> Another attempt, but still not working
>
> I did another attempt, slightly different than the previous one. I don't
> like the way the code is looking now (creating a parsesettings object, from
> which info is taken to put into a parsesettings object, etc.), but I like
> even less that it is still not working. I still get the message :
> No location could be retrieved for url
> KUrl("file:///media/6461-6562/DCIM/100CANON/IMG_3798.JPG")

Hi Jonatan,

I used your patch and modified slightly and now it works. How to proceed? Shall
I commit? Can I commit?

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Rüdiger Härtel]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #40 from Rüdiger Härtel <[hidden email]> ---
Created attachment 80748
  --> https://bugs.kde.org/attachment.cgi?id=80748&action=edit
Another attempt, now it works

This is the proposed patch that brings back renaming during import of images.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #41 from Gilles Caulier <[hidden email]> ---
Rüdiger,

Thanks for you feedback. I will review patch asap...

Gilles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Andi Clemens]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #42 from Andi Clemens <[hidden email]> ---
Today I finally had a little bit of time for fixing the ImportUI bug, but now
the problem has been fixed :-)
Well at least a little bit, the patch seems to work fine, but the preview of
the new filename is not shown.
I don't know if this feature is still present in the new importUI, but it was
there in the old code.

Gilles,

I could commit the patch if you like to, but there are still some problems with
the ImportUI:

- Already downloaded images are not marked as imported?
- "New filename" preview is gone?

Andi

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #43 from Gilles Caulier <[hidden email]> ---
Hi Andi,

Yes, i review patch too, and it sound fine for me. Let's go to commit.

==> Already downloaded images are not marked as imported? => there is another
file about if i remember about this problem (see bugs #313678 and #281758)...

==> "New filename" preview is gone? => this feature must still here now, but
you are right. Another stuff which have disappear...

Gilles

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Andi Clemens]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #44 from Andi Clemens <[hidden email]> ---
The patch has been applied, thanks Rüdiger Härtel  for your help. I will not
close this bug yet since the filename preview is not yet fixed.

Andi

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Andi Clemens]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #45 from Andi Clemens <[hidden email]> ---
The "Camera filenames" option is not working, too. I will try to fix this
now... (it just returns the plain camera filename, no upper or lowercase is
applied)

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Andi Clemens]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #46 from Andi Clemens <[hidden email]> ---
Git commit 1583c952ac27d76c61dd947db8c064b08519adc3 by Andi Clemens.
Committed on 25/06/2013 at 11:09.
Pushed by aclemens into branch 'master'.

fix "Camera filenames" import option

M  +6    -1    utilities/importui/widgets/renamecustomizer.cpp

http://commits.kde.org/digikam/1583c952ac27d76c61dd947db8c064b08519adc3

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #47 from Gilles Caulier <[hidden email]> ---
Andi,

Look like RenameCustomizer::signalChanged() is not connected to ImportUI to
dispatch event on icon-view class.

Camera file name is stored by CameraItemInfo::name. New file-name to use during
import is stored by CameraItemInfo::downloadName.

Through digiKam setup cameras/Import Windows section, we can configure
icon-view to display file-name under thumbnail (as AlbumGUI). It can be easy to
reproduce 2.x renaming result by this way in Qt4 model/view port. Icon-item
print file-name through ItemViewImportDelegate::drawName(). Call to this method
is done into ImportDelegate::paint() line 279.

As you can see, drawName() is called to print only CameraItemInfo::name. There
is n rules to print CameraItemInfo::downloadName if rename customizer settings
has changed.

Gilles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Andi Clemens]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #48 from Andi Clemens <[hidden email]> ---
Gilles,

CameraItemInfo::downloadName is never set anywhere in the code (verify it by
removing the downloadName member from the CameraItemInfo class, no assignment
anywhere).

This means there is a lot more wrong in the code then simply not showing the
downloadName. For example the method CameraItemPropertiesTab::setCurrentItem()
will always display "unchanged" in line 485 because the downloadName is never
set. It is only set (internally) in ImportUI::downloadCameraItems() in line
2053.

Right now we are not able to simply display the new name in the ImportUI,
because there is a lot of code missing from what I've seen so far.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Andi Clemens]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #49 from Andi Clemens <[hidden email]> ---
Gilles, Marcel,

There are still some problems I am not able to fix on my own:
- First of all, displaying the download name is not as easy as it might sound.
I was able to display it (not yet happy with it thought due to some rendering
issues), but the concept doesn't work for workflows were you just download a
bunch of selected images. The problem is that the download names are not
matching the onces after the download process.
For example: 5 images in the ImportUI, named image_#### (image_0001, image_0002
etc). If you only select the image_0003 and image_0004, they will be named
image_0001and image_0002 after the download, which is ok, because it doesn't
make sense to use the names from the ImportUI.
I guess we need to rename the images in the view when a selection is done, but
this is a weird concept in my opinion, because the selected images will have
the new downloadName, the others the old camera name.
I guess this is confusing. Any ideas how to fix this issue?

- Right now I don't really understand the code, I am not able to see when the
view has finished loading and how to detect this in the ImportUI. I need this
to initialize the advancedRenameManager to set the new file names. But right
now I can not find the appropriate signal or slot.
The only thing I found so far is the NewItemsFinder in
ImportUI::finishDialog(), but it is created locally and no signal / slot
connection is done, so the ImportUI must recognize the change through some
other mechanism.
Can you help me out here?

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #50 from Marcel Wiesweg <[hidden email]> ---
> I guess we need to rename the images in the view when a selection is done,
> but this is a weird concept in my opinion,

Well this is how it is in fact. Either we do it, or we don't display a download
name at all per default.
I guess there will be a "preview" name generator which is initialized with
selection change and a "final" name generator.
Is generating the name always fast or are there cases where loading of data is
necessary?

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #51 from Gilles Caulier <[hidden email]> ---
To Andi, #49 :

>I guess we need to rename the images in the view when a selection is done,

This is how 2.x release do with Qt3support classes.

> but this is a weird concept in my opinion, because the selected images will have the new
> downloadName, the others the old camera name.

I think no, if downloadName is used to printed new file name in icon-view and
if for each changes from Rename Customizer, downloadName is updated accordingly
with settings. By default set downloadName = name (camera file name) from
camera item container.

I remember to have implemented this way in the past.

In old code, we can see 2 connections from settings widget to camera icon view
:

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/v2.9.0/entry/utilities/cameragui/main/cameraui.cpp#L498

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/v2.9.0/entry/utilities/cameragui/views/cameraiconview.cpp#L209

First is for batch process settings done at download time as loss les
conversion for ex which change file extension. Second is for rename customizer.

Both call this slot :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/v2.9.0/entry/utilities/cameragui/views/cameraiconview.cpp#L417

... which check items selection and call another internal slot from :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/v2.9.0/entry/utilities/cameragui/views/cameraiconview.cpp#L434

Which do the stuff about file renaming for each items in camera icon view. For
each icon view item, we have an Camera Item Settings instance, where
downloadName vlaue is changed accordingly. At end we refresh icon view to print
all target file name. Et Voilà.

Code puzzle is a little bit complex, due to factoring stage that i do, before
model/view port. It's not the best coding, but as i remember, it work well...

> Right now I don't really understand the code, I am not able to see when the view has finished
> loading and how to detect this in the ImportUI. I need this to initialize the
> advancedRenameManager to set the new file names. But right now I can not find the
> appropriate signal or slot.

Why you need to wait that pre download is done to set advancedRenameManager. Do
it before sarting donwload when user change something in settings view.

>The only thing I found so far is the NewItemsFinder in ImportUI::finishDialog(), but it is
>created locally and no signal / slot connection is done, so the ImportUI must recognize the
>change through some other mechanism.

This one is another part dedicated to find new items downloaded from camera and
update database. It's done when all is already completed. You init must be done
before...

Gilles

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #52 from Gilles Caulier <[hidden email]> ---
To Marcel, #50 :

>Well this is how it is in fact. Either we do it, or we don't display a download
>name at all per default.

I thionk the option to display file name must be show by default, else it will
be very difficult to adjust renaming settings. In 2.x implmeentation it work
like this.

>I guess there will be a "preview" name generator which is initialized with
>selection change and a "final" name generator.

It's a good idea. Just a preview in rename customizer widget can be enough and
lees complex to implement.

>Is generating the name always fast or are there cases where loading of data is
>necessary?

This is an important point. Generating new file name can take a while if use
use metadata or file properties.

Gilles

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #53 from Gilles Caulier <[hidden email]> ---
Andi, Marcel,

About Already Downloaded Flag from icon-view to indicate which item have
already imported to digiKam DB, look like this slot connection is commented :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/utilities/importui/main/importui.cpp#L191

CameraHistoryUpdater which manage status of already imported item with DB
through CHUpdateItemMap container do not dispatch information to icon-view. I
cannot see any code relevant in model/view. This is why there is no downloaded
information displayed over item. I think it can be fixed easily.

This is the older code relevant :

In process to update icon-view (item from camera are listed or item filter has
changed), CameraHistoryUpdater is called :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/v2.9.0/entry/utilities/cameragui/main/cameraui.cpp#L1139

CameraHistoryUpdater ask to DB if items are already imported :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/v2.9.0/entry/utilities/cameragui/controller/camerahistoryupdater.cpp#L154

...and give feedback to GUI through this slot :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/v2.9.0/entry/utilities/cameragui/main/cameraui.cpp#L1142

here, we pass to addItem() the relevant CamItemInfo with DB info. When
icon-view item is created :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/v2.9.0/entry/utilities/cameragui/views/cameraiconview.cpp#L260

... it use this container to plug the right icon over thumbnail to idicate
download status :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/v2.9.0/entry/utilities/cameragui/items/cameraiconitem.cpp#L285

Gilles



https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/v2.9.0/entry/utilities/cameragui/main/cameraui.cpp#L1162

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Andi Clemens]

https://bugs.kde.org/show_bug.cgi?id=314441

--- Comment #54 from Andi Clemens <[hidden email]> ---
(In reply to comment #51)

> > Right now I don't really understand the code, I am not able to see when the view has finished
> > loading and how to detect this in the ImportUI. I need this to initialize the
> > advancedRenameManager to set the new file names. But right now I can not find the
> > appropriate signal or slot.
>
> Why you need to wait that pre download is done to set advancedRenameManager.
> Do it before sarting donwload when user change something in settings view.

I need to wait because the manager needs all the files for generating its
caches. I have 5 cache maps that need to be filled, so that the actual renaming
or changing the rename string is rather fast.

I will try to implement something now, I'll keep you informed...

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel