Improvements in the fuzzy search sidebar
Mario Frank
mafrank at uni-potsdam.de
Thu Aug 10 08:32:19 BST 2017
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
>>>>>>>> <freisim93 at gmail.com>:
>>>>>>>>
>>>>>>>> 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:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2017-03-31 17:32 GMT+02:00 Mario Frank
>>>>>>>>> <mafrank at uni-potsdam.de <mailto:mafrank at uni-potsdam.de>>:
>>>>>>>>>
>>>>>>>>> Hey Guys,
>>>>>>>>>
>>>>>>>>> I was working lately on improving the fuzzy search
>>>>>>>>> sidebar.
>>>>>>>>>
>>>>>>>>> We have some bug reports that are a bit frustrating,
>>>>>>>>> namely
>>>>>>>>> 1) https://bugs.kde.org/show_bug.cgi?id=353331
>>>>>>>>> <https://bugs.kde.org/show_bug.cgi?id=353331>
>>>>>>>>> 2) https://bugs.kde.org/show_bug.cgi?id=372972
>>>>>>>>> <https://bugs.kde.org/show_bug.cgi?id=372972>
>>>>>>>>>
>>>>>>>>> Both bug reports complain that the album selection box
>>>>>>>>> in the duplicates
>>>>>>>>> view only contains the root albums.
>>>>>>>>> The reason is that in a new installation, the root
>>>>>>>>> albums are not
>>>>>>>>> automatically expanded. This is a usability problem
>>>>>>>>> which I was able to solve quite easily. (fixes 372972
>>>>>>>>> and partially 353331)
>>>>>>>>>
>>>>>>>>> Then I found a bug in the fuzzy search. If the maximum
>>>>>>>>> and minimum
>>>>>>>>> similarity are identical (let's say 50 %)
>>>>>>>>> only images with 50,00 % similarity are found though
>>>>>>>>> there should also
>>>>>>>>> be results with 50,xy %.
>>>>>>>>> I could also fix that easily.
>>>>>>>>>
>>>>>>>>> Moreover I rewrote the AlbumSelector from a combo box
>>>>>>>>> based object to a
>>>>>>>>> tab based object which saves us quite some space
>>>>>>>>> (addresses 353331).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Interesting. This concept can be certainly use in other place.
>>>>>>>>>
>>>>>>>>> I'm curions : Which kind of space do you save by this way
>>>>>>>>> ? Can you take a shot ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Also, I added the possibility to restrict the fuzzy
>>>>>>>>> image/drop/sketch
>>>>>>>>> search to albums by adding an AlbumSelector. I only
>>>>>>>>> let the user
>>>>>>>>> restrict to albums
>>>>>>>>> but not to tags as the albums are the object the user
>>>>>>>>> sees. I currently
>>>>>>>>> do not see additional value in restricting to tabs in
>>>>>>>>> this case.
>>>>>>>>> The rearch results are also refreshed when selecting
>>>>>>>>> or deselecting an
>>>>>>>>> album and also when toggling the whole albums button.
>>>>>>>>>
>>>>>>>>> Finally I fixed a bug in the SAlbum query creation for
>>>>>>>>> fuzzy
>>>>>>>>> image/dropped/sketch searches. The "search" tag was
>>>>>>>>> not closed. This had
>>>>>>>>> no bad effects
>>>>>>>>> but is still not nice.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ah, i see this bug under OSX. I think a report already
>>>>>>>>> exists in bugzilla.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> What I could not fix (though I tried in multiple ways)
>>>>>>>>> is that in the
>>>>>>>>> AlbumSelector, the selection count summary is not
>>>>>>>>> shown after starting
>>>>>>>>> digiKam.
>>>>>>>>> The correct albums are checked but the text field is
>>>>>>>>> not filled with the
>>>>>>>>> summary. Do you have any clue how to solve this?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm not sure to understand well. Which summary do you talk
>>>>>>>>> exactly ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Normally, I would append the patch to a bug report but
>>>>>>>>> since it
>>>>>>>>> addresses many small problems, I append it here. Would
>>>>>>>>> all of you who
>>>>>>>>> have time review it?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Personalty not this week end. I teach tomorrow all the
>>>>>>>>> day, and must complete a huge project based on Qt5 in my
>>>>>>>>> office to draw real time measurement curves from Tokamak.
>>>>>>>>>
>>>>>>>>> Also Sunday it's GSoC 2017 proposals review period
>>>>>>>>> starting. This will take time too...
>>>>>>>>>
>>>>>>>>> best
>>>>>>>>>
>>>>>>>>> Gilles
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Mario
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9
>>>>>>>> Mail gesendet.
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20170810/2a4e61f8/attachment.html>
More information about the Digikam-devel
mailing list