CCMAIL: plasma-devel@kde.org
note that the wallpaper is only getting wheel events and move events
when itemAt != this, which is different from the "if there's no applet
there" logic that's used for containmentactions stuff. this could
have... odd... effects for containments that use graphicsitems, like
folderview.
in general it seems like this code's gotten crufty and could do with
some cleanup, once someone decides what the 'proper' behaviour actually
is.
svn path=/trunk/KDE/kdelibs/; revision=1067596
let's before emit a screenchanged with -1 as the new screen for both.
this will make the views forget about them and they won't try to swao them again
makes possible to switch containments on multimonitor or pervirtualdesktopviews=true
svn path=/trunk/KDE/kdelibs/; revision=1063989
In ContainmentPrivate::dropData, some bits assumed there was a dropEvent passed.
This doesn't always happen, for instance with ContainmentActions::paste(). The
points needed are instead taken from the scenePos and screenPos.
BUG: 196416
svn path=/trunk/KDE/kdelibs/; revision=1060831
* AppletScript::addStandardConfigurationPages adds also publish page
* AppletScript::standardConfigurationDialog does not add standard pages (there is addStandardConfigurationPages)
svn path=/trunk/KDE/kdelibs/; revision=1039471
* allow drops on the toolbox, this gives is a place to drop things on the panel at all times, similar to the context menu on toolbox
* small delay on showing the drop zone indicator so that when dragging into the tasks widget, for example, we don't end up flickering as it crosses the panel containment edge
svn path=/trunk/KDE/kdelibs/; revision=1039186
an an application and/or an url list can be associated with an aplet
and a context menu entry and an applet handle button will be added to
launch that application.
the applet will be considered a preview of something, where the
application its full view, for example the picture frame can open
gwenview
svn path=/trunk/KDE/kdelibs/; revision=1024487
this is icky and depends on scene()->sendEvent
but we need it to know whether the containment plugin has child items
expecting a contextmenuevent, before we eat the event.
by the time contextmenuevent runs normally it's too late.
svn path=/trunk/KDE/kdelibs/; revision=1018486
load requires a containment
fix @since (I could've sworn I did this already..)
rename ContextAction->ContainmentActions
misc. improvements from aaron
no more warnings
qDeleteAll
don't iterate with keys()
svn path=/trunk/KDE/kdelibs/; revision=1012647
fix copyright
always init a contextaction before trying to use it
no more unexpected click-throughs
contextAction() returns the plugin name instead of a pointer
svn path=/trunk/KDE/kdelibs/; revision=1012645
-setContainment, so that we don't have to try and use the parent any
more.
-hasConfigurationInterface; this should've already been there.
-default values for a couple of functions that I think make sense
svn path=/trunk/KDE/kdelibs/; revision=1012644
