Quassel is awesome, and has a really interesting idea in wanting to store logs in an sqlite db for better searching, but ironically in the current client implementation this seems to make it harder to search for stuff.
While searching for things in the immediately loaded buffer is easy (CTRL+F), searching for things said a long time ago can't be searched via the client. You either have to use command line tools to dump the sqlite db into a grepable text file or install the quasselsuche web app (last updated in 2012).
Once better long term search has been implemented in the client, quassel will become the best GUI IRC client hands down, I look forward to seeing the progress made in this area.
If I remember correctly, it has massive SQL-injection holes and isn't maintained anymore. The issues are known (quassels website etc warn people against using quasselsuche).
> While searching for things in the immediately loaded buffer is easy (CTRL+F), searching for things said a long time ago can't be searched via the client. You either have to use command line tools to dump the sqlite db into a grepable text file or install the quasselsuche web app (last updated in 2012).
Why not just open the sqlite file and search in there? Could even ask for the log to be stored in an FTS table for fast FTS queries.
That may work, but then you're in the same workflow as the more traditional IRC clients with their .txt logfiles and needing tools external to the IRC client. Ostensibly the point of moving away from the human-readable logfiles to something like an SQL DB was to let the client be a more powerful search engine into your chat history. So this is mostly a lament that while there's a great vision to what an IRC client can be in designing Quassel's infrastructure, Quassel has not yet fully realized its vision in this area, but I'm sure it'll get there some day.
I think the OP's original complaint is bore out of the idea that: if the client is already storing the logs in a structured format with a schema to accompany it, and the data engine has query features for that data which is powerful like grep (as SQL does), and it's already using that engine to power search for the immediate buffer - it seems a bit odd then to not build 'global' search right into the application, for all logs, based on the same mechanism.
I think it's nice you can do all the SQL dumping/munging stuff, given the implementation. I just don't want that in 99% of all use cases - the application doing search itself is enough normally. It's not like I use any of grep's more powerful features when I search logs, 99% of the time it's just something like "| grep foo" and I narrow it down iteratively or just pick out the result.
Honestly, technical specifics aside, this is also a matter of usability, and is something Slack gets very right: you never have to do anything for search to work well for the vast majority of use cases, even for very long histories. You just type the words you want and the results always come back, even from weeks or months before. Telling users to enable logs and then search text files is just much more activation energy. Telling them to do that after exporting their data from SQLite, even more so.
I'm using it with postgres, and yeah I don't know why there's no option to search all historical logs (well I guess if I really wanted it, it is an open source project), but since I have desktop client opened all the time, in settings I have it configured to fetch some ridiculous amount of backlog, and then ctrl-f searches quite far in the past.
While searching for things in the immediately loaded buffer is easy (CTRL+F), searching for things said a long time ago can't be searched via the client. You either have to use command line tools to dump the sqlite db into a grepable text file or install the quasselsuche web app (last updated in 2012).
Once better long term search has been implemented in the client, quassel will become the best GUI IRC client hands down, I look forward to seeing the progress made in this area.