| Summary: | applethandle doesn't dissapear | ||
|---|---|---|---|
| Product: | [Unmaintained] plasma4 | Reporter: | Edwin Schepers <yez> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | amantia, ambrop7, andrey, charlysnews, DavidLBarbour, facorread, goflo, kde, marcus, mike, rockmen1, rossg, tma.klein |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Screencast | ||
|
Description
Edwin Schepers
2007-11-23 20:11:07 UTC
there are many ways to get the applet handle to not disappear; we simply do not get reliable unhover events from qgraphicsview. i think we'll have to introduce a timer hack to get rid of the handles on uncaught unhovers. *** Bug 153294 has been marked as a duplicate of this bug. *** *** Bug 154125 has been marked as a duplicate of this bug. *** *** Bug 154128 has been marked as a duplicate of this bug. *** It's the same when moving the cursor from a plasmoid to a window or if just moving the mouse away too quickly. Though I found something: The battery monitor plasmoid also enlightens the "No Battery" text (at least that's what it says on a desktop computer) and when moving the mouse away, the "No Battery" text always gets back normal, always, even if the rectangle frame with buttons is still around the plasmoids. Maybe use the code that's for "No Battery" text. they both rely on dependable hover out events from QGraphicsScene. there is no special code in the battery applet. Well, it works for the "No Battery" text. So it should be possible to make it work for the frame and buttons. Peter, with all due respect, i understand where you are coming from but unless you are actually looking through the code i don't think it's realistic to be able to offer code-level input. it's actually due to an interesting quirk in the QGraphicsScene where only items that have previously received a hover in get hover outs. since the applet handle gets created in response to a hover event, it doesn't get a hover in, so it doesn't get a hover out. once created, it will get a hover in and then a hover out afterwards resulting in proper hiding after being shown only. *** Bug 154732 has been marked as a duplicate of this bug. *** I have the problem too, when I move the mouse fast over multiple icons on the desktop. <hack> I have an idea, it's just a proposition. I work on the same problem in my work and i have think about something. It's not a solution but it can works. We can add an automatic hide for the applet handle. For example if there is no mouse event on the item during x seconds, handle disappear. Ok it will not fix the issue but the handle will be hide. For KDE 4.0 it can be a solution isn't it? </hack> *** Bug has been marked as fixed ***. *** Bug 155535 has been marked as a duplicate of this bug. *** Was this fixed in SVN, because this bug is still in KDE4, though it doesn't happen as often as it did before. *** Bug 155956 has been marked as a duplicate of this bug. *** *** Bug 156227 has been marked as a duplicate of this bug. *** *** Bug 157046 has been marked as a duplicate of this bug. *** *** Bug 157046 has been marked as a duplicate of this bug. *** *** Bug 158001 has been marked as a duplicate of this bug. *** This bug, or rather #153294, is still present at least in Debian libplasma1 4:4.0.66+svn791114-3, i.e. svn revision 791114. The bug log doesn't say what commit fixed it, but I guess this is more recent. Please repoen, or unmerge #153294 and reopen that one. As aaron said, it's not fixed - the issue is due to some weird things in Qt. I guess by closing it he meant he wants to wait for TT to fix it... *** Bug 164628 has been marked as a duplicate of this bug. *** Created attachment 25518 [details]
Screencast
screencast (Ogg video format)
Comment on attachment 25518 [details]
Screencast
removing.. wrong bug report. sorry ;)
|