Some app lile t3legram prepend other textxs when a message is copied, so
if a retroshare link is passed via t3legram and the user do copy/paste
on retroshare, retroshare get "some text + retroshare link", to avoid
the link being forgot we parte pasted textx more aggressively
AddTrustedNode.qml support for plain certificate and node link import/export
Move clipboard wrapper to it's own singleton ClipboardWrapper.qml with
improved clipboard API
To import contact
/identity/import_key
{"radix":"AgIRBAAABd..."}
To export contact
/identity/export_key
{"gxs_id":"ffffffffffffffffffffffffffffffff"}
In both cases if everithing went fine the answer is something like
{"data":{"radix":"AgIRBAAABd...", "gxs_id":"fff..."}, "returncode":"ok"}
Some retrocompatible adaptations were necessary to libretroshare
RsGenExchange::deserializeGroupData
p3IdService::deserialiseIdentityFromMemory
Now accept an extra optional pointer parameter to return the id of the
key so we can return it back from libresapi too and can be used to
request more information about the key to the API.
In 943a4213fb default identity creation
burst has been solved but some times the duplication happens in
sequent instances of the app, now te app store permanently if default
identity has been created so this other kind of duplication is avoided
too (hopefully)
Use QDir::homePath() instead of RsAccounts::ConfigDirectory() to
determine libresapi socket path, this way statically linking to
libretroshare is not needed and the android package size is reduced
dramatically 20+MB -> 13MB
At same time this solves the socket path mismatch between retroshare
android service and the other android applications due to merge
Qt Creator get confused if files with same name are present in the same
project and when clickng on debug info open the same file, renaming
main to avoid this
The crash was introduced at 533dbef0c7
This has been particurarly tricky as lot of different parts contributed
in causing unexpected behaviours
When the activity is created onNewIntent is not called and we have to
get the intent data from C++ bu other means, but C++ code is running
in a different thread so there is no guarantee that the intent data is
reacheable yet on starting, so the C++ code has to wait for the intent
data being ready, but paying attention to not cause a deadlock beetween
the two thread (the android ui thread may be waiting for some
operation performed by Qt)
Because of notification intent flags not properly set the activity was
recreated also if it was already on top, this caused a nasty
interaction between android ui thread and qt thread that derived in a
deadlock, to avoid this lot of try/error has been made until the
proper soup of manifest and intent flags has been found
At this point link handling, notification handling, and Activity closing
should work as expected without any deadlock or crash
