Gnome-shell-extension-gsconnect: Add a search function for conversations

[terencode]

Is your feature request related to a problem? Please describe.
For when you need to find a specific message buried behind a bunch of others.

Describe the solution you'd like
Add a search button + a shortcut key (ctrl + F) to be able to find an SMS within a conversation and maybe also from all of them at the same time (ctrl + shift + F).

System Details :

• GSConnect version: 28
  
  
  
  • Installed from: AUR repository
  
  

[andyholmes]

I'll have a look at this :) We can't really use a proper database, so it might be prohibitively slow to do.

[terencode]

I feared that :/ wouldn't you be able to refactor the code so that you use a database and then query the messages from there for the SMS app?

[andyholmes]

Yep, but it would require pulling in libgom, which isn't a standard library or very well maintained.

Last time we required extra libraries for things, it caused more confusion and problems than it really helped with, unfortunately.

[ferdnyc]

(He's understating, it was a complete nightmare.)

This is also going to be limited to whatever history is actually available to GSConnect, no? It's not like it can run device-side queries against the full SMS history, it's just the local data.

I'm not that familiar with the SMS plugin since it doesn't work for me (frickin' Samsung), and it wasn't immediately clear from the code (I didn't look very hard) — how much of the device's messaging history is actually available? Does GSConnect get a full mirror up front, or is data for an individual conversation only retrieved on demand?

[andyholmes]

(He's understating, it was a complete nightmare.)

That's true :D

I'm not that familiar with the SMS plugin since it doesn't work for me (frickin' Samsung)

This may be changing, as someone has apparently got it working on a Huawei device, but it's unclear if that will fix it for Samsung yet or if that will need special treatment. The big blocker here is that the main SMS guy Simon just doesn't have a broken Samsung phone to test with.

how much of the device's messaging history is actually available?

We actually sync it all, since it comes in chunks of conversations that are each received in a unique thread (that is a task thread for each packet over the network). So it's not really blocking our main thread, and new messages after that are tiny by comparison. Basically what happens is the Android app dumps named columns from a sqlite database into JSON packets.

Because we don't have a real database it usually ends up cached in memory, otherwise we'd be doing a lot of disk I/O and it would probably be better not to cache at all. This is usually okay though, because contrary to popular belief JavaScript engines are pretty good at compressing objects when they share a common structure.

The problem is really one of scaling; if you have a very large message history we're going to loop through tens of thousands of messages probably with a Regex. While we can use JS or GLib async features to prevent blocking the main loop, ultimately we'd probably end up starving the event loop anyways with all the pending events. That either means hitting the GC hard as each event resolves and gets collected, or holding a ref on each until we're done; so memory vs CPU trade-off. This is actually the same blocker for the multiplex bluetooth backend.

The only reason I marked this as a maybe, is there are obviously tricks we can use to do a little better than just blindly firing off thousands of GSources. We could search messages asynchronously, but in synchronous batches of a few hundred, and we could cache those initial results and do sub-searches as the search terms are refined (eg. som...ethin...g). I'm just skeptical that it's really going to work out; JSON is really not a database and single-threaded JavaScript just doesn't hack these situations well.

[ferdnyc]

This _may_ be changing, as someone has apparently got it working on a Huawei device, but it's unclear if that will fix it for Samsung yet or if that will need special treatment. The big blocker here is that the main SMS guy Simon just doesn't have a broken Samsung phone to test with.

Yeah, I came to the conclusion that rooting my GxS6 was the path of madness, and never even tried. My old GxS4 was not only rooted, but running a community Android build, and that was no big deal. But they've gotten pretty excessively locked down since then.

I have a _Verizon_ Galaxy S6 he could just have, since I'm on Sprint and have no use for it, plus it came to me free anyway.¹ But I don't know how useful it would be — even the bootloader is locked up tight as a drum. Though, apparently it is still possible to root them.

Notes

1. (The "extra" phone was given to me with the hope I could use it to replace my previous broken phone. That was before I discovered that the carriers/manufacturers have come up with all sorts of sneaky ways to get around the Federal unlocking requirements. The phone's radio firmware only has support for the specific LTE _bands_ that Verizon uses, and not the ones Sprint uses. So even though it's an unlocked CDMA/LTE device, it can't connect to Sprint's LTE network. Useless. ...I ended up going to Sprint and leasing the pre-owned GxS6 I'm currently carrying, but have to return like any day now. At least I got to use the same case.)

[andyholmes]

I don't think there's much reason to keep this as a maybe, since we're caching everything in memory currently. No ETA, but consider this an accepted feature request.