Will definitely give this a read-through @suhr. Thank you so much for the resources. Maybe I could try to find a way to bring the solutions listed in this into my proposal (if i understand what is written xD)
One example way to do it is in Trac, our bugtracker:
https://dev.haiku-os.org/query
What they do is have fixed “And” and “Or” menus with the list of attributes in each. Whenever you select an attribute in one of these, it adds a new line in the query.
Existing lines can be removed with a “-” button.
They also do some more things, for example, if you already added the “status” field (which is a set of checkboxes) to the current term of your query, you can’t add it a second time.
(in this case it is term based: the Trac query is always in the form of (x AND y AND …) OR (z AND W AND …) OR (…), which makes things quite a bit simpler but slightly more limited than allowing arbitrary terms.
1 Like
Without negation, it’s easy to make a UI for AND and OR.
Let’s start with a single condition:
[+] Condition 1
Clicking on [+] adds another one to the list:
[+] [+] Condition 2
or [+] Condition 1
Clicking on the first [+] again adds another one:
[+] [+] Condition 3
or [+] Condition 2
or [+] Condition 1
Now let’s click on the [+] near Condition 2:
[+] [+] Condition 3
or [+] [+] Condition 2
and [+] Condition 4
or [+] Condition 1
This adds Condition 4 and groups both Condition 2 and Condition 4 in an expression with the type opposite to the type of the parent expression (patent is “or”, so the children is “and”).
1 Like
A generic QBE style UI could look like this:
Find:
| Disc | Type | Name | |
|----------|----------|----------|-----------------|
| [Disk 1] | [Type 1] | [Name 1] | [Add attribute] |
[Add row]
Where:
[Disk 1] [has any value]
[Type 1] [has any value]
[Name 1] [contains] []
Let’s find all png images which size is the same as the size of screenshot.png:
Find:
| Disc | Type | Name | Size | |
|----------|----------|----------|----------|-----------------|
| | [Type 1] | [Name 1] | [Size 1] | [Add attribute] |
| | [Type 1] | | [Size 1] | |
[Add row]
Where:
[Type 1] [is] [image/png]
[Name 1] [is] [screenshot.png]
[Size 1] [has any value]
Variables are added to “where” list automatically as you create them. For a given variable, there could be a list of conditions connected with “or”. We probably do not need nested or/ands.
I couldn’t quite parse this sentence.
It differs depending on the filetype you have set for the query.
The “AND/OR/NOT” part shows “AND” marked by default and can be changed by the user. It defines how this attribute/search-term column is combined with the one to right of it.
The attribute part depends on the attributes available for that filetype; text/email will show From,To,Subject,When etc., audio/mpeg gets Artist,Title,Album,Track etc.
The “Other” submenu has all available attributes that are registered in the MIME db (as presented in the FileTypes preferences.
That is why scrollbars were invented. 
We shouldn’t artificially set a limit, though I agree that most querys will have few attribute columns, though the user may choose to display other attributes that are not part of the query. E.g. for a search for an “Artist” the user may want to see the “Title” as well.
The Find window’s BColumnListView will very much be like a normal Tracker window in List mode in that regard, i.e. changing sort-order, re-arranging columns, showing/hiding attributes.
As said before, that seems to me a poweruser requirement that can be solved with brackets in the “Formula”. The current Find panel doesn’t handle that either, and in the last 2 decades nobody filed a ticket at Trac that they miss this feature dearly.
It may not be an often encoutered problem in actual usage…
If we can come up with a workable solution for that, great, otherwise I’d say keeping the current Find panels features/limitations is fine if we can get nice and easy live results. That’s the main goal for this project, I think.
I think one big advantage of having the live-result attribute-columns in the new (mocked-up) Find panel, is that it allows to search over quite a few attributes without having to add a new line for each at the top. Compared to the current Find panel (or Trac) you get the first search term of all attributes on one line, whereas before each attribute and its “contains/is/is not/etc” pop-up, search text box, and “AND/OR” pop-up are all added in their own new line. Plus the Add/Remove buttons.
This would all be very compact in one line above the live-result-list.
1 Like
Oh wow! This is actually pretty intuitive. Maybe we could place such a thing under an advanced query section? I’m not sure whether this would fit into the mock-up design for streamlined queries because of its column space restrictions, in the filters. But I’m pretty sure if time permits, then we could also build an alternative window that has the filters in some other fashion that allows for this sort of a filtering. It definitely fixes every issue that could come up with complex queries 
I was actually trying to get at something that you explained in this reply. Was a bit confused as to what we were supposed to show but got that cleared up now
Yup this makes perfect sense. It would be really intuitive to use as well. In most cases, I think that it would be set to either completely AND or completely OR so for streamlining most of the queries, we wouldn’t need to delve into the complex side of the queries, though if we do get the time after perfecting this part, then I would be glad to try my hand at it
Yup. Definitely agree on this. I think its a very very rare case that something like that pops up. In most cases, it would be easier to use the formula view itself 
Yup. It didn’t strike me at first but then yah this does make sense xD. There is pretty much no upside to limiting the amount of queries. Since the current Find window doesn’t do anything of this sort, it would be better to keep all the functionalities of the current find window as well, while building on top of that.
If time permits…
There could be a menu “Edit formula” that opens the current query’s formula in a new window with all those widgets needed to fine-tune all those nested AND/OR/NOR combos. Sounds challenging to me to parse the formula and all, but that’s why it’s on the backburner and nicely separated into it’s own window.
Honestly, I’m not convinced that queries on top of columns are actually helpful to a user. Neither I’m aware of any other UI that uses this design.
We’ll see. In my mind it’ll work as quickly and perfectly as type-ahead-filtering applied drive-wide instead of the current folder, and limited to the chosen attributes instead of all of the currently visible in a Tracker window.
1 Like
Yah I do feel that it does work pretty well because it’s more intuitive to look at and use in general? As far as why the same kind of UI isn’t being used elsewhere, I guess that’s the part that makes Haiku special in the first place right? The Queries for files?
Also honestly, I wasn’t able to understand what you said exactly 
See the User Guide on Tracker under “Type-ahead filtering”.
I recommend to quickly do the QuickTour, and for your GSoC project at least read about Tracker, Queries, Attributes, Index and the “Workshop: Filetypes, Attributes, Index and Queries” in the User Guide…
1 Like
Yup I’ll go through it by the end of today only. For now, I was busy studying the darkwyrm docs and the Haiku API. Will definitely go through all the things. Even PulkoMandy did recommend me a few docs so have quite a lot to work my way through
I did go through the quick tour but I do need to go through the user guides on each one.
1 Like
Oh so okay now it makes sense xD. But yah, I think that’s exactly what this application could end up doing. The only i guess kind of a difference would be that searches wouldn’t be cleared just after a small period of time or something like that. Apart from that, I still do think that a UI upgrade like that would help a lot of newcomers onto the OS use the application easily. Honeslty speaking, the first time I stumbled by the application, I was slightly confused because at the time, I wasn’t aware of how the Query system works and everything. So from that standpoint, this change does have its merits I feel.
Hey Everyone. So I did change my GSoC proposal incorporating the changes from this forum, @humdinger, @PulkoMandy’s chats. I was going through the BQuery API and how the BDirectory, BNode, entry_ref and node_ref classes all work together. Still have to wrap my mind around these so that is the one section that I left uncompleted as of now but I will definitely complete it in the next week.
Apart from that, I did make a timeline, but I thought of asking all of you to check whether you think such a timeline is either too loose or too tight. I will modify it accordingly. Thanks a lot
4 Likes
That was also my thought exactly. Why not have the query result updated live as you change the query? That would be consistent with the single window per view in Tracker and with Haiku in general. Live updating queries are already used so this would be a natural extension.
It is not per default, single view in Tracker at all!
But live updating queries would be a great extension!
But who can and will work on this feature?
Well I’m submitting a proposal for it tomorrow when the applications for GSoC open up. I would be working on this feature itself for the GSoC period (Probably going to start earlier than that too) .
Btw I have linked my proposal here. I would love for more feedback on it as I can edit this until the GSoC application deadlines.
5 Likes
Current Update: I am having my end-semester examinations going on right now until the 10th of April. I will start building out the application once my examinations get over to try and get a better picture of the UI exactly how it is going to look on the Operating System itself. Does that sound good or should I take some other path?
5 Likes