QOwnNotes
QOwnNotes copied to clipboard
pbek
Tag filtering OR/AND
Tag filtering uses an OR conjunction. An AND conjunction would be very useful with multiple notes, otherwise you have to search for the note in the tag results or use a deep folder hierarchy (which could be prevented when using tags). It would be great to have this permanently either in the panel settings or as a toggle AND/OR button in a toolbar.
Tag filtering uses an OR conjunction. An AND conjunction would be very useful with multiple notes, otherwise you have to search for the note in the tag results or use a deep folder hierarchy (which could be prevented when using tags).
it is currently written so that a user could select multiple tags and see the notes from those tags, so yeah like an OR. an AND could be useful, though i highly doubt an avg user would understand the meaning of such an option.
We need better wording for such an option first. The implementation should be relatively straightforward, not a big change.
It would be great to have this permanently either in the panel settings or as a toggle AND/OR button in a toolbar.
Nah, not the toolbar :rofl: its already crowded like crazy.
I expected the filter to behave AND-like by default to find the blue dog in paris immediately instead of looking through dozens of notes to find something specific. Otherwise you still depend on a structured folder system for a knowledge base/archive. But I checked with Digikam and the OR filter really seems to be the standard for tags. I guess it never was an issue since most people manage their images by date anyway and use tags as supplement but for a notes app this really would be a great improvement.
Maybe a single setting for the tags panel would suffice? 'note includes all selected tags' or the like.
This could be a personal preference and might never be changed after initial set-up.
Tudumo had a nice interface: By <shift>-clicking multiple tags you got "AND"-filtering and by <ctrl>-clicking "OR"-filtering. <Alt> excluded a tag.
Interesting, QON is already pretty short-cut heavy anyway. The AND filter alone might already be a lot of work though.
How about extending Tag::fetchAllLinkedNoteIdsForFolder with a provided list of tag ids from the tree view and using a sql query like
"SELECT note_file_name, note_sub_folder_path " "FROM noteTagLink WHERE tag_id = :id AND tag_id = :id AND tag_id = :id AND ...."
It seems the database does not satisfy NF3?
Yes, plus it needs to work with all other settings, not destroy the current way it works, without adding much new complexity to this sensitive part and a sane integration into the user interface or settings.
Doing optional AND-filtering would kind of break the isTaggingShowNotesRecursively feature (or the other way around) and highly increase the complexity of MainWindow::filterNotesByTag() to try to navigate around the issue.
And I guess you need tripple the code complexity of https://github.com/pbek/QOwnNotes/blob/163aa5e38b2a1d667e51fe2a36d5e5faca0beb95/src/mainwindow.cpp#L5706-L5720 and at least double the code complexity (and amount of sql queries) of each Tag::fetchAllLinkedNoteIdsForFolder and Tag::fetchAllLinkedNoteIds to even attempt to make AND-filtering work.
Yes, plus it needs to work with all other settings, not destroy the current way it works, without adding much new complexity to this sensitive part and a sane integration into the user interface or settings.
I cannot judge the UI integration for lack of a suitable overview.
To prevent another setting the OR filter could be replaced altogether IMHO. I cannot see a reason to use it. If I'm looking for the blue dog from 2010, there is no benefit in seeing all dogs, all blue and all notes from 2010. If I forgot how I tagged it, I can just check the tags individually.
And I guess you need tripple the code complexity of
I was even hoping to reduce the complexity and reduce the amount of queries since these code sections looked a little overkill for fetching note ids but I wasn't thinking about nested tags yet.
The tag recursion and AND filter is tricky... This query would provide the notes in question without the need for multiple loops and filters - without accounting for tag children though (yet).
SELECT note_file_name, tag_id
FROM noteTagLink
WHERE tag_id IN (4, 7) -- the tag ids (+ child ids if recursion is on) to search via AND
GROUP BY note_file_name
HAVING COUNT(DISTINCT tag_id) = 2 -- the amount of selected tags
~~One could add a series of OR tag_id IN (5, 8) to the query but that wouldn't account for all possible selected parent-child combination.~~ There should be an easier way via query. I think the (4,7) part would just have to hold all tag children ids. This way you would have 'one query to rule them all'.
If you don't want to touch these parts of the code, one solution would be another filter panel like in Digikam. I know, more panels :-1: but is it possible to add entire QML Widgets to the UI like the addLabel function? This would open many new possibilities for scripting.
Database questions:
- What is the id in noteTagLink?
- Is there a reason you don't satisfy 3NF?
@Waqar144? :smile:
is it possible to add entire QML Widgets to the UI like the addLabel function?
no, the QML user interface Qt library is not even included in the build process...
What is the id in noteTagLink?
The unique identifier of the link table between notes and tags (you can open notes.sqlite to take a look at the tables)
I'm not talking about one query here, I'm talking about that all queries of all methods might need to be duplicated to work with all parameters, settings and things the user select in the user interface.
To prevent another setting the OR filter could be replaced altogether IMHO. I cannot see a reason to use it. If I'm looking for the
blue dog from 2010, there is no benefit in seeing alldogs, allblueand all notes from2010. If I forgot how I tagged it, I can just check the tags individually.
Yes, but there are many users(like me) and others(like the user who created the feature request for multiple tag filtering) who like the way it works right now and would not want it to go away. TBH, I haven't ever used or seen an AND filter anywhere. It has a use case, but for me it would be a secondary thing.
If I'm looking for the
blue dog from **2010**
You do not necessarily need to do everything using tags. There is a filter by text, filter by folder functionality as well. Which often times reduces the search result to 1 if you remember things.
I was even hoping to reduce the complexity and reduce the amount of queries since these code sections looked a little overkill for fetching note ids but I wasn't thinking about nested tags yet.
Which code sections are overkill for fetching note ids? :thinking:
~One could add a series of
OR tag_id IN (5, 8)to the query but that wouldn't account for all possible selected parent-child combination.~ There should be an easier way via query...
Haven't looked at the db for a while, so can't say for sure. But a query might be able to do most of the job.
If you don't want to touch these parts of the code, one solution would be another filter panel like in Digikam.
For me, thats out of the question because A) we do not have any space left for additional panels. B) it's just crazy to have two panels for tags.
The unique identifier of the link table between notes and tags (you can open
notes.sqliteto take a look at the tables)
I did, that's why the question came up. The tag_id note_id relation should be separate from the note name etc. There are different ids for the same note_file_name.
You do not necessarily need to do everything using tags. There is a filter by text, filter by folder functionality as well. Which often times reduces the search result to 1 if you remember things.
You are right, I don't need the feature now but it might come in handy with hundreds of notes.
Which code sections are overkill for fetching note ids? :thinking:
For instance the example from @pbek (Lines 5706 to 5720): you cycle through a list of tags, list of notes etc and access the database multiple times to create a list of noteIds instead of preparing a single query with Qt first. This might be OK for a few selected tags but I think there's a performance penalty when accessing the database multiple times (maybe even the HDD?). I used a few test folder of different sizes for testing and there are a few seconds delay with a few hundred notes. This might not affect most users now, but maybe in the future. (This was already discussed somewhere else.)
For me, thats out of the question because A) we do not have any space left for additional panels. B) it's just crazy to have two panels for tags.
Well, it's not that crazy if a big project like Digikam uses it. However, It wouldn't be for tags but rather for filtering and could be toggled on and off; the search bar could fit there too.
Thank you for the feedback!
For instance the example from @pbek (Lines 5706 to 5720): you cycle through a list of tags, list of notes etc and access the database multiple times to create a list of noteIds instead of preparing a single query with Qt first.
Thats partly because how @pbek initially wrote it and then I carried it forward. A single query may or may not be performant. Haven't tested yet. SQLite is designed to handle short multiple queries in a very short time. But yeah, the performant penalty is there and I have thought about reworking this in someway but haven't got around to do it. The main performance problem comes from tag counting, if we disable that the performance is very bearable for normal cases.
I used a few test folder of different sizes for testing and there are a few seconds delay with a few hundred notes. This might not affect most users now, but maybe in the future. (This was already discussed somewhere else.)
Yes a rather huge discussion.
Well, it's not that crazy if a big project like Digikam uses it. However, It wouldn't be for tags but rather for filtering and could be toggled on and off; the search bar could fit there too.
We don't necessarily have to do everything Digikam does ;) I am a KDE lover, but sometimes I dont agree with their design choices of having a mammoth of features in every application. We are already a monster, these days I usually advocate against adding more features, but its hard to control @pbek :laughing:
Also how about you try and implement this, would be nice to have a new contributor :fireworks:
I might take you up on that offer. I'd start with the database though to simplify the calls and reduce anomaly potentials. The tag counter shouldn't be a huge problem then. I'll have to polish my c++ skills and get to know Qt. :smiley:
Qt is easy, and c++ is you know what ;) I am looking forward to the patch :grin: :+1:
I hope you are also looking forward to test all permutations of settings and edge cases. :laughing:
Any hope this might be implemented?... Beside evernote (meh), I can't find any note taking tool that does multi tag filtering with AND. Good job with the rest, it's a fantastic app :)
Hard to tell if anyone fancies rewriting the whole search and dealing with all the regressions. 😅
Hard to tell if anyone fancies rewriting the whole search and dealing with all the regressions. sweat_smile
It doesn't sound promising :)
If any one else depends on this feature for note taking, I've found this plugin for Sublime text that offers quite powerful search capabilities, including AND/OR and wilcards in tags: sublime_zk. It's not been updated for a while, but I had it working with Sublime text latest version without problems.