* containmentActions -> addContainmentActions
* make both take an event for positioning purposes
* make prepareContainmentActions a more generic so that one code path for handling setting up a ContainmentActions plugin is used everywhere; this also shrinks addContainmentActions down to just being a permissions checker
* make PopupApplet use ContainmentPrive::addAppletActions directly; fewer code paths to track, as it allows removal of ContainmentPrivate::showApplContextMenu
svn path=/trunk/KDE/kdelibs/; revision=1173567
exposes the whole Context*.
The activity functions have to be left in for BC, and they still work as
they did before.
svn path=/trunk/KDE/kdelibs/; revision=1125570
Now corona will layout it's containments instead of letting
them do this task. This was created as a slot so we could preserve
BC. Subclasses of Plasma::Corona must be sure to skip containments
of Panel type during layouting if they wish to reimplement it to
have their own layout.
If subclasses doesn't care about it, just leave it alone and
everything will work just as before. :)
Reviewed-by: aseigo, notmart
svn path=/trunk/KDE/kdelibs/; revision=1095549
* 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
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
there are a few defaults, only one real plugin exists so far
rightclicks are still overridden by the contextmenu event.
the user is warned about plugins that need configuring.
svn path=/trunk/KDE/kdelibs/; revision=1012636
The idea is that you drop a file from a webpage, or basically a URL onto Plasma and Plasma creates a suitable applet to display this URL. For example an image frame for picture, or a previewer for pdf files. Downloading the data itself (and possibly saving it) is left to the applets. The mimetype needs to be retrieved as it cannot be determined from the URL.
The code pathes I've changed or added are, roughly:
- "something" is dropped onto Plasma
- if it's a remote URL, we don't know the mimetype of the object behind the URL yet
- a KIO::TransferJob is used to retrieve the mimetype asynchronously, and will call back
- we open a QMenu that says "Fetching file type..."
- If the user closes the menu while the mimetype is being retrieved, we will open a new one
- When the TransferJob calls back, and we have our mimetype, we offer a list of applets suitable for this kind of content
- If the user chooses to create an applet, we put the transfer job on hold to make it available for recycling by the applet
- If the user dismisses the offering, we kill the job
Thanks to marco for reviewing and everybody else for the input :)
Next steps are making some more applets work with this.
CCMAIL:plasma-devel@kde.org
svn path=/trunk/KDE/kdelibs/; revision=1009004
this is a place for things which shouldn't be duplicated over every single containment, like "lock" and "new activity".
for now we still add the lock action to every containment, so that none of the code lower down notices the change - but we only have one action behind it all :)
svn path=/trunk/KDE/kdelibs/; revision=937923
* check the remove action on immutability changes (prevents "Remove" from showing up erroniously when locking then unlocking)
svn path=/trunk/KDE/kdelibs/; revision=897290
containment, don't show text on icons except add windgets and add
activity
show the remove activity button in the toolbox for non active ones
svn path=/trunk/KDE/kdelibs/; revision=891209
