I have the battery monitor applet set to always hidden in the system tray. When extending all items and left clicking nothing happens. Right click and the tooltip work. Reproducible: Always Steps to Reproduce: 1. Set systemtray settings to always hide the battery aplet 2. Expand systemtray 3. Click battery Actual Results: Nothing Expected Results: The battery monitor opens
Confirmed. Is it a regression (meaning it worked in 4.8 series)?
Yes. I just tested it on a 4.8 system.
Marked as regression, thanks a lot Maarten!
This is not the battery applet's problem. This has something to do with the way applet popups are implemented in general. Probably the combination of such implementation and setting the applet always hidden in tray gives rise to the bug. Not sure if this is a problem of widget-systemtray enough to reassign to it.
Definitely not a battery bug, may be a systray bug - so reassigning it indeed.
Idk if this matters anymore, but I confirm on 4.9.0, openSUSE packages.
I have the same issue, however I believe it is battery applet specific: * It also happens if the battery applet is set to auto, so it's definitely unrelated to setting it to always hidden. On my system, it just depends on whether the icon is hidden or shown, not why. * The auto-hidden device applet works all right. * Setting the network applet to always hidden, is also works all right.
*** Bug 307865 has been marked as a duplicate of this bug. ***
Update: Clicking the battery icon works. It is only the text that does not open the applet. (see duplicate) You can use that as a workaround.
*** Bug 307454 has been marked as a duplicate of this bug. ***
I use a PC (I have no battery) but I use this applet to disable power management when I'm going to watch long videos or a streaming in the web browser and it happens to me too. Happens only when its hidden. I hope it will be fixed soon. But, as Maraten De Meyer said (thanks), if you click in the icon, nor the text, it works, so that will do the trick until it's fixed.
I can confirm this bug on 4.9.80 also. The icon works but the text doesn't
Viranch it works with hidden Device Notifier (text) and Nepomuk but not with hidden Battery Monitor text. This is a very annoying bug.
(In reply to comment #13) > Viranch it works with hidden Device Notifier (text) and Nepomuk but not > with hidden Battery Monitor text. This is a very annoying bug. As I noted earlier, this is not a plasmoid specific bug. The plasmoid uses a special way of showing the tray icon which is not used (yet) by any other plasmoid and whose implementation is not a part of the plasmoid. The reason for using such a way is that the icon for this plasmoid is dynamically built at runtime based on battery percentage, while other plasmoids like device notifier and nepomuk have constant static icons. In short, the bug is in that implementation. Marco had implemented this AFAIK, so he might be the right person to ask.
This bug is still present in KDE 4.10.1.
Still present in 4.10.1 here too.
I digged through the code to find out about the cause of this bug - or, furthermore, to find out why usually, the popup *does* open when clicking the text. Unfortunately, I am stuck: I noticed that the MouseRedirectArea in the IconsList (systemtray/package/contents/ui/IconsList.qml) redirects the text mouse events to the "target". In case of the "widget" items (like the battery manager), the events are forwarded to the task representing the widget, an instance of SystremTray::PlasmoidTask. Here I am stuck, I cannot find out why mouse events sent there somehow end up triggering the popup to open. I would appreciate if whoever works on this code would give me a hint - it already took me 3 hours to find what I got, which is quite frustrating considering that this would probably have been a matter of minutes for someone knowing the code. But it seems nobody is interested in this bug. I also found out that the bug is related to the compactRepresentation: If I remove the compactRepresentation from batterymonitor.qml, the popup opens correctly. This is why it does not affect the device monitor. Somehow, replacing the icon representation breaks the forwarding from the task to opening the popup of the PopupApplet.
I think I found the problem: In popupapplet.cpp, PopupAppletPrivate::createIconWidget, the clicked() signal of the icon is connected to the internalTogglePopup slot of the private part of the PoupApplet. This is the path which is taken when the text is clicked (as I found out via gdb). However, when the compactRepresentation is set up in DeclarativeAppletScript::qmlCreationFinished, nothing is connected. Hence the click is not forwarded to the PopupApplet. Unfortunately, QDeclarativeItem does not have a clicked() signal. How should this be handled?
bug still present in 4.10 no one wants to fix it? battery widget is plagued with qml bugs, very much beta state.
I can confirm this on 4.10.2, but for any non-native KDE system tray icon- not just battery widget
Ralf: if indeed a signal needs forwarding, then a subclass of DeclarativeItemContainer that emits a signal when it gets a mouseReleaseEvent would be needed. fwiw, it all works flawlessly here for whatever reason (other than that one needs to click right on the text; the white space is not reactive which is not correct). i wonder if this is working as expected in master, and just not in 4.10?
(In reply to comment #21) > Ralf: if indeed a signal needs forwarding, then a subclass of > DeclarativeItemContainer that emits a signal when it gets a > mouseReleaseEvent would be needed. > > fwiw, it all works flawlessly here for whatever reason (other than that one > needs to click right on the text; the white space is not reactive which is > not correct). > > i wonder if this is working as expected in master, and just not in 4.10? I did all the aforementioned experiments in the then-current master. Clicking the text (I even tried hitting a black pixel) does not work either, I have to click the icon. I just tried again with current master, with no change in behaviour. Another possibly interesting observation: If I click and drag, I can actually move the battery icon around horizontally - which does not make much sense. I cannot do that with the other icons.
> Another possibly interesting observation: If I click and drag, I can > actually move the battery icon around horizontally - which does not make > much sense. I cannot do that with the other icons. This is because the icon is inside a ListView because of support for multiple batteries. Multiple icons won't be showed when in tray, but the ListView is still there with the single item, and hence the battery icon glides.
> If I click and drag, I can actually move the battery icon around horizontally - which does not make much sense I recently fixed that. > (other than that one needs to click right on the text; the white space is not reactive which is not correct). It's because the name_item in IconsList.qml doesn't have a width and so only where there's text it's clickable.
> > (other than that one needs to click right on the text; the white space is not reactive which is not correct). > It's because the name_item in IconsList.qml doesn't have a width and so only where there's text it's clickable. I actually fixed this after making that comment :) It works as expected now .. In any case ... if anyone can confirm this problem with master, please re-open. Otherwise, I'm seeing this as FIXED. Cheers.
I updated kdelibs, kde-runtime and kde-workspace to current master. The issue persists.
bug CONFIRMED in 4.11 beta 2. widget opens only after clicking on icon, not text.
Confirmed on 4.11 Beta 2. I thought maybe using just an Item instead of a ListView if there is only one battery fixes (workarounds) that but given it doesn't work with the print-manager plasmoid either which is just a dumb icon (and should use plasmoid.popupIcon anyway :P). I have to investigate what device notifier does different that makes it work
Yes, device notifier just uses popupIcon and this works but when a plasmoid uses a custom CompactRepresentation it doesn't. So I bet it doesnt work with the notification plasmoid either.
no, notifications and device-notifier widgets works as expected when clicking on text while hidden in systray :°
(In reply to comment #29) > Yes, device notifier just uses popupIcon and this works but when a plasmoid > uses a custom CompactRepresentation it doesn't. So I bet it doesnt work with > the notification plasmoid either. IIRC it results in a popupEvent being triggered. This is available in QML. See: http://techbase.kde.org/Development/Tutorials/Plasma/QML/API#Events
I just tried, the popupEvent is not fired for the battery monitor when I click the label. Only clicking the icon.
Did you notice my findings in comment 17 and comment 18? Maybe they are helpful.
*** Bug 325991 has been marked as a duplicate of this bug. ***
*** Bug 316709 has been marked as a duplicate of this bug. ***
*** Bug 327606 has been marked as a duplicate of this bug. ***
This is by the way fixed in Plasma 2. I'm leaving the bug open to track it in out long term maintainance release, will close once Plasma 2 is out (if it isn't closed then).
This also affects the new plasma-nm (kdeplasma-applets-plasma-nm 0.9.3.3-1 on Arch Linux). I don't know if the widget was affected before the latest release but I've just noticed it. > This is by the way fixed in Plasma 2. Great, I'll wait :D
*** Bug 335135 has been marked as a duplicate of this bug. ***
I can confirm this on Kubuntu (the most recent version), KDE 4.13.2. I've been getting it with Workrave, Artha, and the Owncloud client icon, so the suggestion that this is non-native kde apps seems plausible to me too. I look forward to it being fixed in plasma 2 (when's that likely to work its way here?), the workaround with the icon is handy!
*** Bug 338952 has been marked as a duplicate of this bug. ***
*** Bug 344845 has been marked as a duplicate of this bug. ***
*** Bug 351665 has been marked as a duplicate of this bug. ***
Hello! This bug report was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this bug has already been resolved in Plasma 5. Accordingly, we hope you understand why we must close this bug report. If the issue described here is still present in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging Thanks for your understanding! Nate Graham