Re: Improvements in the fuzzy search sidebar

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Improvements in the fuzzy search sidebar

Mario Frank
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:


2017-03-31 17:32 GMT+02:00 Mario Frank <[hidden email]>:
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
2) 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.








Loading...