[digikam] [Bug 374191] New: Unusable context menu entries in tags view

[bugzilla_noreply]

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

            Bug ID: 374191
           Summary: Unusable context menu entries in tags view
           Product: digikam
           Version: 5.4.0
          Platform: Appimage
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: general
          Assignee: [hidden email]
          Reporter: [hidden email]
  Target Milestone: ---

There are some entries in the context menu of tags in the tags view of the left
sidebar that are either not working properly or do nothing.

"Find Duplicates" switches to the "Duplicates" rider of the "Fuzzy" tab as
expected, but does not select the tags previously selected to be searched. This
should probably be fixed.

"Export" only sends the currently selected item in the main view to the export
tool. If this is at all useful, it should send all items belonging to the
selected tag(s) to the export tool. Or maybe this should just be removed from
this context menu and export goes over selected items in main view and the top
menu bar.

The submenu of "Batch Process" contains only a grayed out entry "No batch
process plugins available". What is this submenu supposed to do?

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

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

--- Comment #1 from [hidden email] ---
Git commit 762161177b9862601396b53dea64e6037ef391cc by Gilles Caulier.
Committed on 27/12/2016 at 01:09.
Pushed by cgilles into branch 'master'.

remove obsolete Batch Process menu entries in context menus

M  +0    -28   app/utils/contextmenuhelper.cpp
M  +0    -5    app/utils/contextmenuhelper.h
M  +0    -1    libs/album/albumselectiontreeview.cpp
M  +0    -2    libs/tags/tagfolderview.cpp

https://commits.kde.org/digikam/762161177b9862601396b53dea64e6037ef391cc

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

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

--- Comment #2 from Simon <[hidden email]> ---
Regarding the issue with "Find Duplicates": The correct tags are actually set,
but for some reason the check whether this selection is valid
(FindDuplicatesView::slotCheckForValidSettings) is false and thus "Tags" is not
selected in the "Duplicates" view.

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

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

[hidden email] changed:

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

--- Comment #3 from [hidden email] ---
"Find Duplicates" -> confirmed. Just a call is missing somewhere to turn on
Tags search instead Albums search.

"Export" -> The current behavior is correct. Only the current selected image in
Tag album is exported. It work as main application Export menu. If you want to
export whole tag contents, just select all with CTRL+A before.

"Batch Process" -> Fixed...

Gilles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

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

[hidden email] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|general                     |Tags

--
You are receiving this mail because:
You are the assignee for the bug.

[Simon Frei]

> [hidden email] changed:
> [...]
> "Export" -> The current behavior is correct. Only the current selected image in
> Tag album is exported. It work as main application Export menu. If you want to
> export whole tag contents, just select all with CTRL+A before.

I understand how to do it using the main view, but I do not understand
why a menu entry on the tag behaves this way. If there was an export
entry in the context menu on a item in the main view, this behaviour
would be expected. However for export on a tag I would expect that
export applies to this tag, i.e. the tag album. If this behaviour is not
desirable, then this option should either be removed or transferred to
the context menu in the main view. To me it makes no sense to select
images in the main view, then right click the tag in the left sidebar
and select an export tool to export all selected images. I would either
use the top menu bar or right click on one of the selected items in the
main view.

> "Batch Process" -> Fixed...
>
> Gilles Caulier
>
As usual, thanks for the quick response!

[bugzilla_noreply]

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

--- Comment #4 from Simon <[hidden email]> ---
> [hidden email] changed:
> [...]
> "Export" -> The current behavior is correct. Only the current selected image in
> Tag album is exported. It work as main application Export menu. If you want to
> export whole tag contents, just select all with CTRL+A before.

I understand how to do it using the main view, but I do not understand
why a menu entry on the tag behaves this way. If there was an export
entry in the context menu on a item in the main view, this behaviour
would be expected. However for export on a tag I would expect that
export applies to this tag, i.e. the tag album. If this behaviour is not
desirable, then this option should either be removed or transferred to
the context menu in the main view. To me it makes no sense to select
images in the main view, then right click the tag in the left sidebar
and select an export tool to export all selected images. I would either
use the top menu bar or right click on one of the selected items in the
main view.

> "Batch Process" -> Fixed...
>
> Gilles Caulier
>
As usual, thanks for the quick response!

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

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

Mario Frank <[hidden email]> changed:

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

--- Comment #5 from Mario Frank <[hidden email]> ---
"Finde Duplicates" sounds like work for me. Should the search only be done on
the Tags? I could try to patch that today.

--
You are receiving this mail because:
You are the assignee for the bug.

[Simon Frei]

On 27/12/16 11:52, Mario Frank wrote:
> [...]
>
> --- Comment #5 from Mario Frank <[hidden email]> ---
> "Finde Duplicates" sounds like work for me. Should the search only be done on
> the Tags? I could try to patch that today.
>

Yes, I would expect the search only to be done on the tags that are
selected in the tags view (otherwise what is the point of having the
context menu option, you could just select the fuzzy sidebar). Steps to
reproduce:

1. Go to Duplicates in fuzzy sidebar, select "Albums" in "Search in:"
section.
2. Go to Tags sidebar, right click on a tag and select "Find Duplicates..."
Actual result: The correct tag is set to be searched, but "Albums" is
still selected.
Expected result: Switch to "Tags".


One additional, related but different issue:
I addition the tag sidebar allows to select multiple tags at once, so I
would expect all these tags to be passed to the Duplicate tool.
Currently only the one tag that the right click happens on is passed to
the Duplicates tool.

[bugzilla_noreply]

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

--- Comment #6 from Simon <[hidden email]> ---
On 27/12/16 11:52, Mario Frank wrote:
> [...]
>
> --- Comment #5 from Mario Frank <[hidden email]> ---
> "Finde Duplicates" sounds like work for me. Should the search only be done on
> the Tags? I could try to patch that today.
>

Yes, I would expect the search only to be done on the tags that are
selected in the tags view (otherwise what is the point of having the
context menu option, you could just select the fuzzy sidebar). Steps to
reproduce:

1. Go to Duplicates in fuzzy sidebar, select "Albums" in "Search in:"
section.
2. Go to Tags sidebar, right click on a tag and select "Find Duplicates..."
Actual result: The correct tag is set to be searched, but "Albums" is
still selected.
Expected result: Switch to "Tags".


One additional, related but different issue:
I addition the tag sidebar allows to select multiple tags at once, so I
would expect all these tags to be passed to the Duplicate tool.
Currently only the one tag that the right click happens on is passed to
the Duplicates tool.

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

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

--- Comment #7 from [hidden email] ---
Simon,

About "Export" problem, this require a re-design/factoring/simplification in
kipi interface which must be postponed in the future. So typically, i don't
want to touch this implementation. Please open a separated bug for that, in
digiKam/kipiinterface section.

Gilles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

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

--- Comment #8 from Mario Frank <[hidden email]> ---
Git commit 319d66b5062d145ce4e04a23df7ecf68bfbfecfb by Mario Frank.
Committed on 29/12/2016 at 19:26.
Pushed by mfrank into branch 'master'.

Using the context menu in tags and album tree view for finding duplicates now
not only selects the selected tag/album for duplicates search
but also switches to the correct search mode.

M  +11   -0    libs/album/albumselectors.cpp
M  +5    -0    libs/album/albumselectors.h
M  +2    -0    utilities/fuzzysearch/findduplicatesview.cpp

https://commits.kde.org/digikam/319d66b5062d145ce4e04a23df7ecf68bfbfecfb

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

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

--- Comment #9 from Mario Frank <[hidden email]> ---
Simon,

your original bug report for "Find Duplicates" is resolved. I do not trigger
the duplicates search since the user may want to modify the similarity
interval. But the correct section (album/tag) is now selected. I already tested
it. Nevertheless, please confirm whether the functionality is correct.

Concerning the selection of multiple tags for context menu: this needs some
more work. Should this be also included in the 5.4 milestone? If not, we should
open a bug for this specific case.

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

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

--- Comment #10 from [hidden email] ---
>Concerning the selection of multiple tags for context menu: this needs some more >work. Should this be also included in the 5.4 milestone? If not, we should open >a bug for this specific case.

You decide. 5.4.0 is postponed to 8 January now. If you have enough time to do
it, let's go. Note: it's always better to touch same code at closed time, it's
more easy, instead to delay to much changes.

If you need more time, i can again postpone 5.4.0. There is no special reason
to publish 5.4.0 in first week of January. Let's me hear.

Gilles

--
You are receiving this mail because:
You are the assignee for the bug.

[Simon Frei]

> --- Comment #10 from [hidden email] ---
>> Concerning the selection of multiple tags for context menu: this needs some more >work. Should this be also included in the 5.4 milestone? If not, we should open >a bug for this specific case.
> You decide. 5.4.0 is postponed to 8 January now. If you have enough time to do
> it, let's go. Note: it's always better to touch same code at closed time, it's
> more easy, instead to delay to much changes.
>
> If you need more time, i can again postpone 5.4.0. There is no special reason
> to publish 5.4.0 in first week of January. Let's me hear.
>
> Gilles
>

Thanks a lot for the quick fixes!
From my point of view this is a minor issue, I did not report it because
it is important for my use of digikam. It is just from the UI, I would
expect this to work this way as a user (both involved functions allow
multiple tags to be selected, so the link between them should also
handle multiple tags). And as I am just reporting and not fixing, I
certainly don't have any say in when this should be done.
However I would suggest not to postpone 5.4.0 again, at least not for
this. There are for sure some people out there waiting for the release
(even if its just one), and disappointing them needlessly is not so nice.

[bugzilla_noreply]

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

--- Comment #11 from Simon <[hidden email]> ---

> --- Comment #10 from [hidden email] ---
>> Concerning the selection of multiple tags for context menu: this needs some more >work. Should this be also included in the 5.4 milestone? If not, we should open >a bug for this specific case.
> You decide. 5.4.0 is postponed to 8 January now. If you have enough time to do
> it, let's go. Note: it's always better to touch same code at closed time, it's
> more easy, instead to delay to much changes.
>
> If you need more time, i can again postpone 5.4.0. There is no special reason
> to publish 5.4.0 in first week of January. Let's me hear.
>
> Gilles
>

Thanks a lot for the quick fixes!
From my point of view this is a minor issue, I did not report it because
it is important for my use of digikam. It is just from the UI, I would
expect this to work this way as a user (both involved functions allow
multiple tags to be selected, so the link between them should also
handle multiple tags). And as I am just reporting and not fixing, I
certainly don't have any say in when this should be done.
However I would suggest not to postpone 5.4.0 again, at least not for
this. There are for sure some people out there waiting for the release
(even if its just one), and disappointing them needlessly is not so nice.

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

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

--- Comment #12 from Mario Frank <[hidden email]> ---
Hey Gilles,

I would not like to have the release postponed again. There is enough time for
testing and this modification for me and I agree with Simon. We should only
postpone for stability. This glitch should not be a reason. I'll look at it
over the weekend and make some more tests.

Cheers,
Mario

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

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

--- Comment #13 from Mario Frank <[hidden email]> ---
Hi Simon,
hi Gilles,

I got a working solution for initialising a duplicates search (selecting the
tags) for multiple selected tags. It works quite well. Moreover, I found some
function calls in the code that seem to be superfluous. I did not remove them,
but only set a comment @ODD.
I will append a patch. Although I tested it on my machine, I would like to have
someone else having a look over it. Can you test the functionality, too, Simon?

Another glitch for which I will open a bug is: In tags tree view, multiple tags
can be selected. But in Albums tree view, this is not possible. Perhaps this
should be enabled in DK 5.5.

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

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

--- Comment #14 from Mario Frank <[hidden email]> ---
Created attachment 103144
  --> https://bugs.kde.org/attachment.cgi?id=103144&action=edit
Patch for triggering duplicates search for multiple tags with context menu.

--
You are receiving this mail because:
You are the assignee for the bug.

[Simon Frei]

Hi Mario,

I justed tested it and it worked as expected.
I have a question/proposition: The existing slotNewDuplicatesSearch
funciton accepts a generic album pointer and then determines what type
(physical/tag) it is. You made two distinct functions for lists as
arguments that still accept generic album pointers but named them to
make it clear that either physical or tag albums are expected. Wouldn't
it be cleaner and less error prone to use one function name
(slotNewDuplicatesSearch) and overload it with different parameters
(PAlbum*, TAlbum*, QList<PAlbum*> and QList<TAlbum*>)?