Implemented in work/tfry/apiabstraction (since the reencrypt code had changed, considerably, in that branch, I did not base this on master).

Removal of vue: work/tfry/reduce_js_dependencies ; this branch is currently still a bit messy/buggy, but considered to be on par with the functionality master, in theory.

I added a config setting for Windows only: work/tfry/autostart .

EWS-API used in our code (CPP-wrappers -> description / our usage):

• EwsGetItemRequest -> get message(s) (one or several; mime content and parent folder id)
• EWSMessageDispatcher -> just a wrapper around:
  • EwsCreateItemRequest -> "Send message and save copy"
• Used by reencrypt, only:
  • EwsGetFolderRequest -> Apparently just gets the id and label of a folder
  • EwsCreateFolderRequest -> create new folder; includes indication whether that name already existed
  • EwsGetFolderContentRequest -> get all mails in a folder; additionally uses:
    • EwsFindItemRequest -> obtain list of messages in a folder (does not list subfolders)
  • These two just needed to create (reencrypted) messages without having them appear as new
    • EwsCopyItemRequest -> copy existing message from one existing folder to another
    • EwsUpdateItemRequest -> used to replace mime content of message, without change status (new/read...)

• Made some more tweaks to the UI

WIP at work/tfry/reencrypt_ui

Tested with gpg4win-5.0.0-beta479 @ win11

@tfry tested this, and it seems fine.

Addendum: I currently do not think we can do anything about this, except for documenting it.

I suppose you selected "Allow", then, and yes, that's enough to "fix" the problem. Chromium does remember the decision (unfortunately, it also remembers if you selected "Block", and some users are doubtlessly going to do so).

i didn't see any of this in chromium 141.0.7390.77, but i do after an upgrade to 143.0.7499.170. but only at the first start. when i closed chromium and launched it again, the logo appeared as desired (i did a successful pairing the first time).

when do you see this precisely?

when do you see this precisely?

Observations (confirmation wanted):

• • If no other gpgol-client Window is currently showing, the newly created window will show on top
  • With the config window showing (but nothing else)
    • clicking on reencrypt the first time will fail to bring the window to the front
    • cancel it and click on reencrypt, again -> window comes to the front
  • Similar observations when clicking on view/decrypt, reply, etc. for the first / second time.
• Hypothesis: Windows might become whitelisted depending on their title

Merged, manually (e63f7c1a62bd94594c0d7cd4326b94afc0e5fe71)

Should be doable your QStandardPath::GenericDataLocation . See also T7987