We didn’t have much activity around desktop search at GUADEC 2024. So I went through the BoF notes from 2023 to see how much we achieved after last year’s energetic discussions.
Plan next steps for system search designs:
We think libgnomesearch is the answer, nobody worked on it this year though.
Indexing the whole home dir:
Carlos spent some time pushing this, we still want to do wider research to see if its practical to deploy the change to everyone.
Rename tracker and tracker-miners:
Done by Carlos and Sam, coming in GNOME 47
Still some work to do, e.g. renaming the Discourse tag and the Matrix room.
Decide which website to keep and clean up the others:
Death to the wiki: Still need to clean the wiki up
tracker.gnome.org still exists, and requires updating for the rename
tinysparql.org now exists for TinySPARQL itself, currently redirecting to the API documentation.
Move “How search works” to developer guide: not done
Determine if we can help Contacts and Calendar use TinySPARQL:
Contacts: Andy Holmes and Corentin Noel are doing some work using TinySPARQL, I don’t know the status.
Calendar: Nobody pushed this forward, as far as I know.
Remote search:
Nobody worked on this.
How do we make third party app search better?
I think nobody worked on this.
SearchProvider API should be an XDG standard, not a GNOME specific API
Nobody worked on this.
One thing not mentioned here that we did, is started the TinySPARQL web IDE project, which is in progress as a GSoC internship with Demigod and Rachel.
Thanks for reading and let me know if you’re interested in working on Search in GNOME!
For my part I’m very much still in the research phase, which is why I’ve been hanging around asking questions; just to catch up with SPARQL/RDF. Here’s a quick vague overview.
I’ve been looking at TinySPARQL as way for host and applications to federate groupware content (email/contacts/calendar), namely to avoid passing account credentials across the sandbox boundary (i.e. GOA). In the case that application developers went for this, they would probably want a simple set of tools to replace the bits GOA used to provide. To that end, I’ve been positioning newer code to be compatible with such a use case.
It’s worth noting that unlike Accounts SSO, GOA’s discovery/authentication happens in the client-side process. Personally, I think that makes sense for a sandboxed application if it’s going to be using the credentials itself and otherwise it shouldn’t have them. However, I don’t believe we had a conversation about Accounts SSO in the context of sandboxing and tracker. I’d be interested to hear your perspective on the whole thing, Corentin, since this is very much your wheelhouse
I wonder, if it could be transformed from search provider to intent provider.
Instead of writing Berlin for Clock search provider gives a timezone in Berlin, we could have Clocks covering intents “time, timezone”, with action “present (synonyms as “show, tell” handled by gnome-shell)” and parameters “Berlin, Prague…” , so when you would write “Tell me what time is in Berlin”.
Now, this is pretty useless on the mobile devices. But let’s account for OpenCL and Whispers models integration running on the GPU (for more modern devices on NPUs), and you can just press microphone button and ask this getting the result.
