Evolution compose window issue in plasma desktop

mcloaked · 2025-11-01 09:58:25

For a long time I have been using Evolution mail within the Plasma desktop running Wayland without issue. After the recent major plasma version update when I select 'new' or 'reply' in Evolution to compose a new message, the compose window goes behind the main evolution window, and although I can click to focus and raise the compose window to the front, I have always previously had the compose window open as raised and in front of the main Evolution window. I have tried various different options to create a window rule to keep the compose window raised so that it is in front and in focus, but I have been unable to find any set of rule options that works.

If anyone else has had the same issue and knows a solution I would appreciate knowing what that is, if you can post the fix.

Edit: I have managed o get a rules that works for a new compose window - since the window title is Compose Message, and have a rule to force raise the window. But for reply and reply to all, the window title is specific to the subject, so I can't make a rule that works. Perhaps there is one property that will identify any reply window so that the raise rule will work?

Last edited by mcloaked (2025-11-01 11:32:27)

seth · 2025-11-01 13:29:16

Is evolution https://wiki.archlinux.org/title/Waylan … plications ?
Maybe the window class + role? (Does the property detection work on kwin/wayland? Is it actually still there?)

On a limb:

xprop

mcloaked · 2025-11-01 13:44:44

I run with no xwayland programs in the plasma session - just pure wayland. Possibly the window class + role would be relevant - but I don't know what is needed for the specific fields for that when creating an appropriate rule. The property detection does seem to work within the window rules setting page, and clicking on the compose window does fill in the properties box - but due to the window title being the specific comment field for the reply maybe that makes it fail. The xprop doesn't do anything as it isn't x.

I presume that the recent major version update to plasma now has code for window stacking that is not compatible with evolution, since presumably that is designed for gnome and not the mainly qt based applications for most of the plasma applications. It was working fine until the new update and window stacking in plasma wayland has been a bit problematic for a while, so some fixes likely led to regressions. I searched the kde bug list but this particular issue seems not to be there.

mcloaked · 2025-11-01 14:03:24

I added a comment at https://discuss.kde.org/t/apps-cant-rai … r/40531/20 - perhaps there will be a response there.

seth · 2025-11-01 14:19:43

Cross-test: how does "GDK_BACKEND=x11 evolution" behave then?
What happens if you disable focus stealing prevention (one would run into stuff like that if the timestamps are off)

mcloaked · 2025-11-01 14:36:08

Yes GDK_BACKEND=x11 evolution behaves correctly - but under wayland it behaves as I described. I tried the various focus stealing prevention options, and that did not help the issue.

mcloaked · 2025-11-01 14:52:42

It will be a while for me to follow up on this as I am now on travels away from my laptop... I will catch up later in the month.

Arch Linux

#1 2025-11-01 09:58:25

Evolution compose window issue in plasma desktop

#2 2025-11-01 13:29:16

Re: Evolution compose window issue in plasma desktop

#3 2025-11-01 13:44:44

Re: Evolution compose window issue in plasma desktop

#4 2025-11-01 14:03:24

Re: Evolution compose window issue in plasma desktop

#5 2025-11-01 14:19:43

Re: Evolution compose window issue in plasma desktop

#6 2025-11-01 14:36:08

Re: Evolution compose window issue in plasma desktop

#7 2025-11-01 14:52:42

Re: Evolution compose window issue in plasma desktop

Board footer