Description of problem: The Evolution appointment window steals the focus every time it pops up. If you are not looking at the screen while typing, you suddenly start typing in the search field of the reminder. This is pretty annoying. Version-Release number of selected component (if applicable): evolution-3.12.11-22.el7.x86_64 How reproducible: Every time a reminder comes up Steps to Reproduce: 1. Create a appointment 2. Type while the appointment comes up Actual results: Evolution reminder window steals focus and you type suddenly in a different window Expected results: Reminder window comes up without focus, so you still type at the right window. Reminder window only gets focus when you click on it.
Thanks for a bug report. I fixed this upstream with commit [1], which is for 3.22.2+ and 3.23.1+. You can apply it to /usr/share/evolution/3.12/ui/alarm-notify.ui and it'll last until you update the evolution. This change will be included in RHEL 7.4, after the rebase to 3.22.x version of the evolution (bug #1386852). I also made a follow-up commit [2], which can be done only for 3.23.1, due to new translatable strings and changed UI, which are are not permitted in stable releases. [1] https://git.gnome.org/browse/evolution/commit?id=3694a31 [2] https://git.gnome.org/browse/evolution/commit?id=3c3439c
Quick question: Will the window still be on top of all other windows.. as this is actually nice to see the window, just the focus stealing would be the problem. SO the idea was.. "Always on top=True" while "Has initial focus=False".. So the window can still set with focus by clicking on it.
Yes, the window stays on the top after applying both commits from comment #2. The second commit adds an option for it, but it's left turned on, which means "current behaviour" (except of stealing focus). It's enough if you apply the first commit to the .ui file on your local machine and you are all set.
Hey Milan, I have tested the patch on my test system, and the appointment window still pops up on front and takes the focus.
Are you running GNOME Shell, or any other desktop/window manager? The documentation says that it's only a hint and the window managers can ignore it, which, I'm afraid, happened here.
I am running Gnome Shell 3.14 (RHEL 7) (not classic mode)
I tried to reproduce with gnome-shell-3.14.4-53.el7.x86_64 and it works for me, though it didn't right after I changed the alarm-notify.ui file. It required a re-start of the evolution-alarm-notify process (kill it and then run evolution works just fine, because the Evolution starts the process when not running).
I will try again. I am sure I even rebooted at some time after making the change. Will et you know after the next reminder :D
My test is to create an event in a local calendar with a reminder with 30 minutes before the appointment, say with a start at 10:00, while it's 9:40 (thus it'll be triggered immediately after the event is saved). To let it trigger again I edit this existing event and change its start time by one minute, thus in this case at 10:01.
This change is part of the rebased package (bug #1386852). I use it locally and it works as expected under MATE, but it higly depends on the desktop environment whether it obeys the flag or not. If you've trouble under GNOME Shell, then I suggest to create a new bug report there, referencing this one.
Tested manually on x86_64, ppc64le and aarch64 using evolution-3.22.6-10.el7 The described problem did not appear (i.e. focus was not stolen).
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2066