Version: (using KDE 4.0.2) Installed from: Ubuntu Packages OS: Linux Several aspects of the plasmoid handles confound my expectations. First, they sometimes move based on the plasmoid's screen position. Sometimes they're on the right, sometimes on the left - I can't figure out what causes this behavior, and it confuses and upsets me. Second, if I want to resize, the plasma handles only appear if I hover over the plasmoid - but they disappear as soon as I overshoot the handle edge. I.e., I do this: hover over the plasmoid to make the handles appear (which takes a noticeable fraction of a second); then move my mouse to click the resize or rotate handle or whatever. But my mouse control is not very precise, so sometimes I overshoot by 1 or 2 pixels. The handle vanishes. My mouse cursor is now 10 or 12 pixels away from the plasmoid, and I must move it back onto the plasmoid to try again. Annoying - a little tolerance for my humanity would be appreciated.
> I can't figure out what causes this behavior the appear on the side that is most likely to not result in you resizing the widget and hitting a screen edge. it prevents having to first move the widget then resize it if it is near, e.g., the left edge. > a little tolerance for my humanity would be appreciated. that's a good point. we'll be reimplementing applet handles shortly due to new features in QGraphicsView with Qt 4.4, and i'll try and keep this in mind when getting to that.
I am still getting similar behavior in 4.0.83. With the folderview plasmoid, by default it is in the upper left corner, so the thick handle with the controls is on the right. But when you move it away from the edge, the thick handle now wants to be on the left. While this makes sense from a developer's perspective, it can be very disconcerting to a user. Use case: move plasmoid away from left edge of screen, decide you don't like it in the new position, try to move it back to its original position. It's very hard because the thick handle is now on the other side hindering a move back to the original position. I can also confirm the difficulty in trying to correctly position a mouse over an initially invisible handle.
Slippery thing and placement of "toolbox" are separate issues, for the latter one here is report: https://bugs.kde.org/show_bug.cgi?id=164055
there is a timeout now so overshooting doesn't immediately cause the handle to fade out.
imho it is not fixed per se, there is slight improvement, but the problem exists. For me it is still extra effort to work with those vanishing handles. I can only admit that solving this is difficult due to the UI design (i.e. since they are intended to work entirely on timeout there will be always problem by definition).
PS. Just one though -- what with extra button "sticky"? User could press it and work with handles attached, press it second time and there is timeout again.
And one another :-) What strikes me is faulty UI here -- in order to get somewhere (handle area) you have to move mouse somewhere _else_ (plasmoid). This is counterintuitive when handle just disappeared and you want to get it back. The second problem is timeout for appear. My suggestions: * when user enters plasmoid show handle right away, no timeout * when user enters plasmoid handle area show handle too -- I am only not sure if with timeout or not, but rather not
"What strikes me is faulty UI here -- in order to get somewhere (handle area) you have to move mouse somewhere _else_ (plasmoid). " Completely agree with this. Luckily we have Aaron who will ignore us and the logic. :-)