| Summary: | Add widgets close button appears after manual paint | ||
|---|---|---|---|
| Product: | [Unmaintained] plasma4 | Reporter: | Maciej Pilichowski <bluedzins> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Maciej Pilichowski
2007-12-23 09:06:22 UTC
"It's slow" bugs are not being accepted, but there is an issue that applets starting or closing don't cause an update(). In other words, the button doesn't appear or disappear until the mouse enters the listview. Jason -- I rephrase then. There is no visual feedback at all, not even busy cursor mouse and I have to wait several seconds. So I have no clue if I really added the widget and I have to wait, or I didn't and I have to add it again. How are you running kde4? KDE4LiveRC2+. Via VirtualBox or booting from CD (since I see no difference I am testing it now with VB). That's where the slowness is coming from. VirtualBox has virtualization overhead and running off CD has poor seek times. In both cases, the file system is being decompressed on the fly. Applets appear instantaneously with a regular installation. Slowness of the system can be achieved as well by simply running KDE4 on slow CPU. So visual feedback (busy cursor mouse) would be very welcome. Users of older computer will be grateful (me including, I still use PIII 800MHz running KDE 3.5.8 now). *** Bug 154549 has been marked as a duplicate of this bug. *** setData() is being called normally and is not being overridden anywhere that I can see so the dataChanged() signal should be going though fine. Not sure why it's not... Need somebody strong on interview for this one. before the widget is ready we don't know where it will appear. i don't see a way to address this with a poor hack. this make this BR a "make it faster" report which isn't useful as it's a general and never fully achievable BR (optimizations can always be done, right?) This report gone somewhere else I didn't intended, it was added another my report (now 100% valid), and not it is a wontfix. So back to visual feedback --> please change cursor to mouse busy cursor (reopening). Bug 154549 is exactly what i was talking about in my first comment, which is why I marked it as a dupe of this. But the other one is cleaner so it's better to leave that one open instead. As for visual feedback, the mouse pointer should show a plus next to it up until the time that the plasmoid is loading. The plasmoid becomes visible straight after that. There isn't actually any time to show a busy cursor. 1) user clicks "add" 2) change the mouse cursor 3) load and run widget 4) change the mouse cursor back Am I missing something? That can be done. SVN commit 753469 by jstubbs: Switch to a busy cursor while the applet is loading BUG: 154512 M +10 -0 containment.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=753469 Jason, thank you! |