Version: 4.4.2 (using KDE 4.4.2) OS: Linux Installed from: Ubuntu Packages Steps to reproduce: 1. start ktimetracker 2. create and start a task 3. close ktimetracker to minitize it to the systray 4. do some real work 5. after some time, decide to have a break 6. left-click on the ktimetracker systray icon to open the application 7. press Escape to stop the current task Expected result: ktimetracker has the focus, and Escape stops the current task. Actual results: ktimetracker is visible, but it does not have the focus. So the Escape goes to the currently focused app, not to ktimetracker, and the task happily continues. A second click on the app window is necessary to focus the app before the Escape key gets registered.
Does not sound like the reason was in ktimetracker's source. Cannot try to reproduce because I am on a trip. Will be back in june.
Looks like a problem with KStatusNotifierItem class - both KTimeTracker and, for instance, Amarok use it and both have the same problem. It's still an issue as of KDE SC 4.4.5.
Thank you for the hint - this KStatUsNotifierItem stuff has been done by someone else but me - what is it and how can I solve this problem?
It's probably a bug in kdeui, although I can't find any existing bug report against that. Maybe ask Aurélien, who committed the change (r1042702)?
(In reply to comment #0) > Steps to reproduce: > > 1. start ktimetracker > 2. create and start a task > 3. close ktimetracker to minitize it to the systray > 4. do some real work > 5. after some time, decide to have a break > 6. left-click on the ktimetracker systray icon to open the application > 7. press Escape to stop the current task > > Expected result: > ktimetracker has the focus, and Escape stops the current task. > > Actual results: > ktimetracker is visible, but it does not have the focus. So the Escape goes to > the currently focused app, not to ktimetracker, and the task happily continues. > A second click on the app window is necessary to focus the app before the > Escape key gets registered. I just tried to reproduce the bug but it worked for me. Is there a particular thing to do in the 4th step to reproduce it? I just clicked on another window to focus it.
> I just tried to reproduce the bug but it worked for me. Is there a particular > thing to do in the 4th step to reproduce it? I just clicked on another window > to focus it. Try this: 1. Start KTimeTracker and minimize it to tray. 2. Start app A, and then app B so app B has focus. 3. Press Alt+Tab. Now app A has focus. 4. Press Alt+Tab. Now app B has focus. 5. Click on KTimeTracker's tray icon. It will get on top of other windows but it doesn't has focus.
I cannot reproduce this.
Anyway, it's fixed in KDE SC 4.5.0 (in kdeui, I think). Thanks.
Hello! Sorry to be the bearer of bad news, but this project has been unmaintained for many years so I will be closing this bug.
This or a similar problem is still reproducible with KTimeTracker built from Git master and KF 5.61.0. However KTimeTracker's code does not do anything special, it relies on KStatusNotifierItem's ability to show/hide the main application window.
How I reproduce the problem: 1. Start some other app, e.g. Kate 2. Run TimeTracker 3. Click on the KTimeTracker icon in system tray to hide (minimize) it 4. Click inside the Kate window 5. Click on the KTimeTracker's system tray icon again EXPECTED KTimeTracker must appear on top of Kate and get focus. ACTUAL Plasma taskbar indicates that KTimeTracker's window is now open. However Kate still has focus, and I can't even see KTimeTracker's window because the Kate's maximize window totally obscures KTimeTracker.
I can still reproduce in KTimeTracker and Kiten.
Here's what I've learnt today (using KF 5.85, Plasma 5.22.4) 1. Not reproducible on Plasma-Wayland. 2. Not reproducible if change window manager from kwin_x11 to fluxbox. We could hack-fix it in KF5Notifications by calling KWindowSystem::forceActiveWindow() - a patch I've created actually solves the problem. However because it's not reproducible on Fluxbox, I believe it should be fixed in kwin_x11.
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/knotifications/-/merge_requests/52
The bug described in comment #11 is still reproducible in Plasma 5.27.4 + KF 5.105.0 + Qt 5.15.9 on Fedora 37.
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/knotifications/-/merge_requests/102
This is a client issue