Hey Simon,
I finally had the time after the conference day to replace the
minimum and maximum similarity selection boxes in fuzzy
search, duplicates search and maintenance by a new, generic
DIntRangeBox (in libs/widgets/common) which makes the look,
feel and behaviour consistent in all places.
The commit can be found here:
https://commits.kde.org/digikam/903c53415f3fa63d53f02eb828e3169cb4cc9009
I already tested the behaviour yesterday. There may be need for
polishing, potentially. The fuzzy image search panel does not look
really nice yet.
The DIntRangeBox can be used for all int value ranges. I can think
of it being used as input to search for images in a range of 0 to x
MB/KB/GB, for example.
I do not know which potential applications there are additionally.
But at least, it enforces the order of min and max value. Also it
emits signals on min and max
value change.
Also, I lift this now quite old discussion to our now more clean dev
room.
Regards,
Mario
On 14/04/17 15:15, Mario Frank wrote:
Hi Simon,
The similarity range is not necessarily the same for fuzzy
and duplicates search.
Consider that yo dou a duplicates search and see an image
where you are sure that there is a near-duplicate which is not
listed,
as it's similarity is lower, for example. Then you can do a
fuzzy search for this specific image. And in this case you
want to be able
to use different similarity thresholds. But you want to still
have the previous thresholds in duplicates search.
Yeah, I saw the GUI changes and they look good as I
mentioned. This is the stuff that I sometimes do not see. So,
feedback and hints
for improvement are appreciated.
Cheers,
Mario
Am 14.04.2017 um 12:38 schrieb
Simon Frei:
Hi Mario,
I am not sure I can follow with everything you wrote, but that
is exactly why it sounds good that you annex this :)
I assumed the limits should not independent in the tree
places, where it is used, as I didn't think you necessarily
want the same range for e.g. duplicate and image search.
Also did you notice the small GUI changes (some column stretch
and padding adjustments) as well?
Cheers,
Simon
On 14/04/17 12:30, Mario Frank
wrote:
Hey Simon,
I'm sitting in a train and had the time to look at the
patch.
The idea to extract the similarity interval as class is
good.
And the polishing part seems also good at first glance.
But I think the way you extract the similarity interval does
not go in the right direction.
We should enforce consistent look&feel and also
behaviour everywhere we use such constructs.
And the max and min widget should not be directly accessed.
We use similarity interval in
- duplicates search in the fuzzy search sidebar
- duplicates search in the maintenance dialogue
- fuzzy image/drop search in fuzzy sidebar
In every spot, it should look and behave the same way.
If this is okay for all of you, I would annex the
(fuzzy/duplicates) searches part more or less as I think
that I now have a quite good overview
of the codebase in that part.
If this is okay, I would rewrite your idea and implement it
more generic, i.e. create a widget for ranges/intervals
under libs/widgets/common.
This way, the behaviour of altering the maximum and minimum
would be encapsulated and easier to confirm as correct.
How does that sound?
Cheers,
Mario
Am 13.04.2017 um 23:26 schrieb
Simon Frei:
Hi Mario,
The patch in https://bugs.kde.org/show_bug.cgi?id=353331
is in master, right? Can this bug be closed?
Also I removed some more unnecessary borders around widget
and did other minor GUI polishing regarding fuzzy
searches. Also I did a little refactor around the
similarity limit controls.
I don't really have the overview over which are the
relevant bugs, so I attached it here.
Cheers,
Simon
On 04/04/17 17:10, Mario
Frank wrote:
Hi Simon,
after polishing some parts, I was finding myself more in
refactoring the AlbumSelectors class.
I found out that the duplicates search itself allows
searching both in tags and in albums.
But the AlbumSelectors only returns either PAlbums or
TAlbums (one of the lists is empty) depending on
the selected tab.
So I refactored the class and it now returns all
selected albums with selectedAlbums and the selected
tags
with selectedTags no matter which tab is chosen in
duplicates search.
In Fuzzy image and sketch search, selectedTags returns
an empty list.
So I could now squeeze the (I think) last way on
restricting the duplicates search results, i.e.
The user can select both tags and albums and apply one
of 5 operations to the selected objects:
- "One of" aka union - Search in the set of images that
are either in the selected tags or albums
- "Both" aka intersection - Search in the set of images
that are both in the selected tags and albums
- "Albums but not tags" aka difference - Search in the
set of images that are in the selected albums but not in
the selected tags
- "Tags but not albums" aka difference - Search in the
set of images that are in the selected tags but not in
the selected albums
- "Only selected tab" aka obvious - Search in the
selected albums, if albums tab is active and in the
selected tags if tags tab is active
With the refactoring, I was also able to fix incorrect
indentation ( the AlbumSelectors was shifted right a
bit).
I have already done some tests which worked without
problems.
I will attach the current patch to bug https://bugs.kde.org/show_bug.cgi?id=353331
with some screenshots of the new fuzzy sidebar
so you all can take a look. Sadly, my localisation is
now broken and I have mixed English and German texts.
I do not see more ways to restrict the results in the
fuzzy sidebar. Further improvements of fuzzy/duplicates
search will be subject to
better duplicates recognition algorithm(s).
Cheers,
Mario
Am 02.04.2017 um 22:47
schrieb Simon Frei:
Hi Mario,
I originally just wanted to get rid of the borders
around the albumselector widget. Then I ran into
problems when the tags tab is not added. This lead to
quite a lot more changes than intended. This now
ensures that no operations regarding tags happen, when
the albumselector was constructed without tags
selecting and I simplified some things.
In my opinion this change is big enough to warrant his
own branch. Is just much easier and less error prone
(at least for me) than exchanging patches by email.
Cheers,
Simon
On 01/04/17 13:35, Mario
Frank wrote:
Hey Simon,
Yes, the restriction should be either to albums or
to tags. The not selected restriction variant is
still disabled. I just wored it now to the selected
tab instead of checkbox.
I don't allow to restrict on tags for complexity
reasons. We have a one to one relation between
albums and images. So checking if an image belongs
to an album is a constant time check. This does not
hold for tags. If I let them restrict to tags, I
would have to check if one of the image tags is in
the selected tags list. This is a linear complexity
operation. And the more they tag their images, the
slower the check will be. It is even possible that
restricting by tags can make the search slower than
without restriction. That's why I wrote that I do
not see a value. The drawback can be higher than the
gain.
Cheers,
Mario
Am 1. April 2017 00:58:13
MESZ schrieb Simon Frei
[hidden email]:
One more thing I
forgot: Previously the other type (either album
or tag) was disabled. It is still meant, that
the user chooses either tags or albums, not a
mixture of both by switching between the tabs,
correct?
On 31/03/17 22:21,
Gilles Caulier wrote:
--
Diese Nachricht wurde von meinem
Android-Mobiltelefon mit K-9 Mail gesendet.
Locked
