Tuba

Tuba copied to clipboard

I often find myself wanting to search for a thing I bookmarked or starred, but there's no way to search just those, and the general "post" search is too broad to be useful most of the time. It'd be great if it was possible to either search individual views (e.g. with a search icon in the headerbar), or alternatively, having a more sophisticated filtering in the search view (e.g. a way to filter for things like "my bookmarks", "posts by $USER", "my own posts", and so on).

I'd say the options are:

1. search on what's already in memory
2. wait for mastodon to improve their filters (https://github.com/mastodon/mastodon/issues/27155)

---

1. I think we've discussed this before but the gist is that all timeline APIs are pagination-based. Say we want to search the active user's bookmarks, we'd have to paginate forever until we get all posts and then search in them (well, we'd search while paginating). This might be ok if the user has like 100 bookmarked posts but when you get to thousands it's very spammy to the instance (and maybe memory intense if we keep them in memory for a while for follow-up searches). What can be done is search on what's already in memory or what's visible
2. Mastodon does have a filter that has a wider scope but includes bookmarks, in:library. It will return posts that are in your bookmarks, favorites etc. The linked suggestion is for bookmarks only

Maybe this library thing could be good enough for now, e.g. as a fourth option in the Search view? Does it include my own posts as well or only favorites/bookmarks?

Does it include my own posts as well or only favorites/bookmarks?

It should but you can also pass from:tbernard

Maybe this library thing could be good enough for now, e.g. as a fourth option in the Search view?

Not sure. You'll probably discover that it might be missing some of your posts. That's due to elasticsearch and indexing. Elasticsearch is heavy and many instances don't have it enabled or haven't indexed everything. It might be possible to check if the current instance has elasticsearch enabled but other details might not be available so I'm not sure if it should be very prominent in Tuba. What about a button that opens a dialog with more details and a cheatsheet?

The web client displays them but doesn't really explain what they do

Oh nice, yeah if we just had GUI support (i.e. exposing which filters there are, autocomplete for users, date chooser for dates, etc.) for those features in the search view it'd cover the described use cases I think.

Until there is a Nautilus-like filtering UI with widgets to make this easy, how about using a GtkTooltip (or a cheatsheet popover widget from a clickable icon in the GtkEntry, maybe) to give the user hints and examples of valid search syntax? We do this in GTG for the quick-add entry field simply using a tooltip, but we also had the idea to use a popover widget for the searchentry that has more complex syntax: https://github.com/getting-things-gnome/gtg/pull/725

Even if you have a set of filter widgets eventually, it would still be great to keep the self-documenting UI cheatsheets to let the user know about the freeform syntax that can be used in the search field. Even if I could read about it on some website or help page, I can never remember it; it should be right there in the UI.

I was thinking something similar to twitter's advanced search as a start and we can then iterate later (autocomplete, widgets in entry...):

Screencast from 2024-03-06 14-54-18.webm

Since filter support depends on the instance, it will be transparent and fill the search entry (and do the search) rather than do a search in the background with the filters without showing them to the user

PRed on #962

I'm not super fond of it tbh.

• It can read already written queries and populate the dialog from it
• The banner is wordy but needed. AFAIK, only Mastodon supports these filters and only if they have full text search enabled (which is heavy and expensive so most smaller instances don't have it enabled. AFAIK, non-admins cannot know if it is so I cannot show it conditionally)
• The invert filter (-is:reply) tip should also be noted somewhere, not sure if that's the best place. It's a bit hard to transform it into GUI because it's 3 states: invert, none, enabled (-is:reply vs nothing vs is:reply)