Add configure command to native messaging interface

[jelmervdl]

Useful for benchmarking mostly

[XapaJIaMnu]

So... isNull() is like key: "", whereas isUndefined() is the key is not found at all?

[jelmervdl]

The returned QJsonValue is QJsonValue::Undefined if the key does not exist.

https://doc.qt.io/qt-6/qjsonobject.html#value

[XapaJIaMnu]

How was it then working beforehand!?

[jelmervdl]

I have no idea, nor have I tested missing keys properly? They definitely look pretty distinct and incompatible:

inline bool isNull() const { return type() == Null; }
...
inline bool isUndefined() const { return type() == Undefined; }

(From qjsonvalue.h#107-113)

[XapaJIaMnu]

Good! I should make use of this to add automatic tests on githubCI!

[jelmervdl]

I marked it as draft because I just implemented this as a one-off for some benchmarking work. However, this functionality might be useful for other use cases as well.

There should be probably be a min(requested-threads, std::thread::hardware_concurrency()) or something.

[XapaJIaMnu]

Yeah, that's what I do: https://github.com/XapaJIaMnu/translateLocally/blob/master/src/settings/TranslatorSettingsDialog.cpp#L24
Should that be written to settings if changed?

[jelmervdl]

I'd say no, that would be unexpected. I like the idea that it will default to whatever you selected in the GUI, but you can reconfigure it easily if you want something specific for that session/client application.

In my measurements, the Configure command is pretty much free when it is the first command issued. bergamot-translator's AsyncService does almost no work until the first translation is requested.

[jelmervdl]

Oeh note to self: it should do everything from the pointer reset line in std::async or something, because that's a blocking call that will wait for all still pending translations to finish. And that should not be blocking the event loop!

And then I need to think a bit about how it should treat translation requests that come in after the Configure command. They should be queued/processed after it, and not to the service that is about to be reset (thereby delaying the reset even more). So maybe the reset() should be blocking the event loop?