DeltaTouch removed key-export menu items around version 1.10, presumably following the Android client design. Iâve just found out that the Android GUI key export options were removed due to an Android-specific security problem. On mobile Linux, it would be possible to export public and private keys (including public keys of contacts) directly to a keyring, which really ought to be more secure than an Android âDownloadsâ folder.
Importing the public keys of contacts from the keyring could also be much slicker than creating .asc files and loading them into a chat, especially for larger numbers of contacts.
Leftwards swipe message> hamburger menu> Copy text does not actually copy the text; you get another menu (the popup) and have to press a second button marked âCopyâ to actually copy it.
When you want to remove a message from the Saved Messages, you have to swipe rightwards, click on the red refuse container, and answer âDelete one message on all your devices?â with âDelete for meâ. In fact, this only removes the message from the saved messages; it does not delete instances of it elsewhere. âDelete one message from [chat name] on all your devices?â might be clearer.
I can bring back the key export function, but Iâm not sure whether direct export to a keyring is feasible right now.
Are you aware of any app that already does this?
Well, thatâs on purpose Itâs a compromise that has to do with being able to select only a part of the message text, the swipe thing of Lomiri UI Toolkit and DeltaTouch aiming to work both on mobile and desktop linux, see here for background. Iâm open for better solutions.
Do you mean when you have saved a message so that the bookmark icon appears? I think at least DC Android will show the same behaviour and strings as DeltaTouch in this case.
Yes, most Linux mailclients that do encryption. If you wish to encrypt an email to alice@example.com, they will use any public key for that address found in your keyring (often by default, but asking for confirmation with a popup). For instance, Claws, KMail and Neomutt all interact with a keyring like this. I think Evolution does. Keyrings usually have extensive command-line functionality, too.
Actually, mailclients interacting with keyrings seemed sufficiently standard that I assumed it would be fairly easy to implement, not much harder than key export to file. But either would be pretty useful and not really much less secure than the DB.
Maybe relabel the âCopy textâ button to say âSelect and copyâ or âCopy or reactâ or something? Then the user would expect another menu.
Yes, I mean that. Okay, Iâll suggest it for the other clients. EDIT: Done!
And thank you for creating the URL recognition issue and for being, if anything, too responsive to my comments. I need to more clearly distinguish between when I am just mildly astonished by the UI (possibly just because itâs got a skiamorph) and when something is actually malfunctioning.
When editing a message one cannot remove or replace any attachments. This is mildly inconvenient, though I suppose one could accidentally send an extremely inappropriate attachment.
On the account setting labelled: âIf read receipts are disabled, you wonât be able to see read receipts from othersâ, I think you are right that this is less clear in English, and âyou also wonâtâ would be clearer. Labelling the setting âNeither send nor request read receiptsâ would be shorter and clearer.
Separately, while the setting seems to disable sending receipts, it seems I am still receiving them (both from people using other versions of Deltatouch and from other Deltachat clients).
This didnât seem illlogical. Not telling someone (and eavesdroppers) youâre online and reading their messages is useful, but ignoring them when they tell you they are online does not improve anyoneâs privacy. But I donât know if I am requesting the receipts. Iâd prefer receipts off by default, also to halve to number of messages, but I can see the opposing argument.
Finally, two truly trivial cosmetic issues. If the last message sent was to chat which was formerly the oldest (bottommost), that chat correctly moves to the top, but the horizontal rule under that chat goes missing. And horizontal and vertical centering of Latin characters and emojis in avatars is conspicuously off.
Itâs the same as in the official clients. Message editing is a feature of the core, and itâs for the text part of the message only for now. If you have sent an inappropriate attachment, just delete the message for everyone.
The strings are from the official clients, so it would be a general suggestion applicable to all clients.
When you disable the setting, future messages that you send out wonât request read receipts. Messages you have already sent out before changing the setting will continue to receive receipts. Does that match your experience or do you receive receipts for messages sent after disabling the setting?
Not sure I fully understand, but except for exposing the setting in the UI, all the read receipt stuff is handled by the core anyway, so nothing that can be changed in DeltaTouch.
I noticed this and thought I fixed it a long time ago. Obviously the âfixâ does not work on platforms other than Ubuntu Touch. I believe that itâs an upstream bug in Lomiri UI Toolkit that will be hard to work around if the fix I already applied is not enough. Iâve created an issue in the DeltaTouch repo, but will likely have to move it to the Lomiri repo.
Iâm telling QML to center the char in the avatar. Seems that doesnât always work, but not sure whether there will be capacity to fix this soon.
As mentioned before, Iâm very grateful that you are reporting all these things. It may take a while until it will be fixed in the app in many cases though - hope you understand.
Itâs a compromise that has to do with being able to select only a part of the message text, the swipe thing of Lomiri UI Toolkit and DeltaTouch aiming to work both on mobile and desktop linux, see