Bug 176549 - Moving applets to different screen results in an immediate drop
Summary: Moving applets to different screen results in an immediate drop
Status: RESOLVED DUPLICATE of bug 188116
Alias: None
Product: plasma4
Classification: Unmaintained
Component: multiscreen (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
: 196211 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-11-30 16:27 UTC by Miikka Salminen
Modified: 2009-10-21 14:40 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Miikka Salminen 2008-11-30 16:27:41 UTC
Version:            (using KDE 4.1.3)
OS:                Linux
Installed from:    Ubuntu Packages

I can drag plasma applets (tested with analog clock) around different twinview/xinerama screens, but the parts touching the different screen than the one they were added to become invisible during their stay on the different screen. Also, if I drop them on the different screen, I can't pick them up anymore (even though I'm sure I clicked on where I left them). The only way to remove these invisible untouchable applets is through the add widgets menu.
Comment 1 Sebastian Sauer 2008-12-08 21:21:59 UTC
Not reproducable for me with trunk (aka upcoming 4.2 beta2). What happens is, that the dragged applet will be auto-dropped to the other screen as soon as my mouse-pointer did reached the other screen. But then I can pick up the applet again and move it to whereever I wanna have it.

So, remaining bug may those "auto-drop" if mouse/applet reaches the other screen rather then staying in drag-mode till I dropped the applet manually.
Comment 2 Aaron J. Seigo 2008-12-08 21:29:33 UTC
> Not reproducable for me with trunk

i believe it depends on the z ordering of the containments. what probably needs to happen is to ensure that the containment with the mousing happening it needs to be raised above other containments in z-order.
Comment 3 Miikka Salminen 2008-12-18 23:27:28 UTC
After upgrading to KDE 4.2 beta 2, the behaviour has changed to what Sebastian Sauer described.
Comment 4 Aaron J. Seigo 2008-12-18 23:45:12 UTC
Ok, so renaming this bug to reflect that.
Comment 5 Craig Magina 2009-03-19 17:23:14 UTC
The description Sebastian Sauer gives is the one I experience under Fedora 10, KDE 4.2.1.
Comment 6 Aaron J. Seigo 2009-06-13 19:54:50 UTC
*** Bug 196211 has been marked as a duplicate of this bug. ***
Comment 7 Beat Wolf 2009-10-21 14:40:40 UTC

*** This bug has been marked as a duplicate of bug 188116 ***