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

In T7774#209645, @ebo wrote:

isn't this done?

Partial / WIP fix: branch work/tfry/refresh_draft_list

There are actually two separate causes for this:

• For newly created drafts, the native client fails to keep track of their existence. It will thus only "find" them, when it is re-started.
• Beyond this, the only place where drafts are synced is the "info-fetched" command. This is sent in response to the "info" command, and that only gets sent when changing to a different email, or reconnection. Further, only reduced info (not drafts) is sent back to the web client, in case the message was already cached in the native client (WebsocketClient::info()).

Apparently, the relevant option appears to have been renamed in outlook:

Related to T7972 and T7726 . Currently it would be unclear, whether we should fall back to some other available native client.

isn't this done?

WebServer::processCommand, case Command::Register. When a web client connects, we send the mapping to both web client and native client. However, when a native client connects, we only send the mapping to the web client. We'd need both, here, too. However, we probably want to refactor both cases to use common code.

these articles on the graph API might be useful:

there have been changes affecting this:

That might be related to T2196 which has been hopefully fixed in 2.2.50 and also in the next 2.6. Closing this task.

That might be related to T2196 which has been hopefully fixed in 2.2.50 and also in the next 2.6. Closing this task.

We also discussed emails that can't be decrypted. They are due to implementation details just currently skipped. They will also be so in the future as an implementation detail.

Someone should test whether gpgol2 is able to reencrypt all subfolders of a given folder. The file reencrypt tool (current name "recipients" "hugh") does this already.

the web client received some changes in the meantime and behaves more verbose regarding connections to a native client. we should check this again, especially if GpgOL/Web is supposed to be used for different outöook accounts at the same time.

in the meantime we decided it's not always desirable to have the process autostarted. therefore the current default (manual start) is considered ok, but if possible a configuration option should be implemented, so users can activate autostart if they find it useful.

Done with https://invent.kde.org/pim/mimetreeparser/-/commit/0624268ae545ced59177ce15f92be119ba43025a

Should current behavior of 'starting with no arguments' be preserved? or should we add a --generate or --doit or similar ?

A bit tricky to fix unfortunately, making the window active is not really possible on Windows. See https://doc.qt.io/qt-6/qwidget.html#activateWindow but there seems to be some tricks one can use: https://forum.qt.io/topic/1939/activatewindow-does-not-send-window-to-front/11?_=1750663659477

The question is whether any part of Qt/KF6/MTP forks another process and does not do it correctly. For example it is required that the child figures out the fds to close and then closes them and does not rely here on the parent.

For each part that needs to be reencrypted I create a QGpgME Encrypt Job

Do you start other process while this context is in use? If you do a fork, you need to make sure that all file descriptors are closed. How is that done?

Interesing part of the logs: