There's some weird hack in the way we do nested containments like the tray and the grouping plasmoid. When these nested containments create an applet, they pass "org.kde.plasma:force-create" in the argument list for whatever hackish workaround reason this was invented for. This breaks plasmoids that react to plasmoid.externalData in useful ways, e.g. Folder View configures its URL from external data, so it can be instanciated to show a particular URL. This happens when dropping an URL on a containment and picking Folder View from the applet-from-MIME menu choices. When adding Folder View to the grouping plasmoid, it therefore gets configured to show the location "org.kde.plasma:force-create" (this string is URL-like would not be rejected, although amittedly there's currently no input validation being done) and breaks in a way the user has no hope of understanding and fixing. I don't want to add special handling for "org.kde.plasma:force-create" to Folder View and other applets. I also don't think it's a good idea to make the magic string something non-URL; it could still conflict with what other plasmoids are doing. I request that this hack be done some other way than the plasmoid-facing argument list. Internals shouldn't be exposed to plasmoid code in this way.
I should definitely remove the arg once it has done what it wanted to do. On creation it checks the arguments and then sets a dynamic property onto itself. After that it could remove the argument.
https://phabricator.kde.org/T9224
I think I'll go adding a property on systray/grouping containments like "dynamiccontent" which would replace the argument. However... I think this would be resolved "properly" once we have sandboxed stuff, those two nesting containments would be replaced by out of process shells which would never be locked and bam, done
(In reply to Marco Martin from comment #3) > I think I'll go adding a property on systray/grouping containments like > "dynamiccontent" which would replace the argument. hmm, easy for Containment::addApplet, but not for Corona::createContainment, which would need to access the containment metadata before creating it, which is possible but very dirty
Could you explain a bit more context? What is this org.kde.plasma:force-create stuff even used for?
System Tray, so it can create applets even when the shell itself is immutable. I think the Grouping Plasmoid also uses it for the same purpose.