Otherwise clicking it would show an "invalid URL" error and
trying to open the properties dialog would trigger an assert.
This can normally not happen but you can get here with e.g. plasmoidviewer
BUG: 455433
Summary:
applets that acces their config in C++ needs to implement
configChanged() in order to still work correctly in the scripting
console
Test Plan: correct icon when created from scripting console and config written from there
Reviewers: #plasma, broulik
Reviewed By: #plasma, broulik
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4461
Summary:
applets that acces their config in C++ needs to implement
configChanged() in order to still work correctly in the scripting
console
Test Plan: correct icon when created from scripting console and config written from there
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4461
This adds the "Open With..." option known from Dolphin to the icon applet when it points to a file.
Also adds a "Open Containing Folder".
While at it, moves the action logic for jump list actions to C++ side
Differential Revision: https://phabricator.kde.org/D3905
This brings back the properties dialog allowing to manipulate the icon and label of a widget.
CHANGELOG: Icon widget properties, such as name, icon, working directory, etc can now be edited
Differential Revision: https://phabricator.kde.org/D2687
Dragging an app link .desktop file from Folder View showing desktop:/
from Folder View (but not Dolphin) to desktop/panel, spawning an Icon,
was broken because:
- KDirModel::metaData adds the UDS_LOCAL_PATH (local file) url as
text/uri-list to the drag MIME data, but also the original desktop:/
URL as a second special MIME format for KDE URLs, using KUrlMimeData
- Dolphin only does the first part, using a partial code copy from
KDirModel
- ContainmentInterface::processMimeData uses KUrlMimeData with default
options to decode the drag MIME data - the default option is
PreferKdeURLs, so it retrieves the desktop:/ URL from the FV drag
but not the Dolphin drag (since it lacks it)
- Thus the Icon applet is handed a desktop:/ URL in the FV case, which
the code - not using KIO - isn't written to handle
This patch adds an async KIO::StatJob to the Icon code when
QURL::isLocalFile is fast to try and resolve an URL to a more local
one the rest of the code can handle.
Rewriting more of the Icon code to use KIO /would/ have been nice,
however it ultimately ends up using KDesktopFile which can't handle
non-local files, so at some point resolving to the proxied-for path
would happen anyway.
BUG:356548
Dragging an app link .desktop file from Folder View showing desktop:/
from Folder View (but not Dolphin) to desktop/panel, spawning an Icon,
was broken because:
- KDirModel::metaData adds the UDS_LOCAL_PATH (local file) url as
text/uri-list to the drag MIME data, but also the original desktop:/
URL as a second special MIME format for KDE URLs, using KUrlMimeData
- Dolphin only does the first part, using a partial code copy from
KDirModel
- ContainmentInterface::processMimeData uses KUrlMimeData with default
options to decode the drag MIME data - the default option is
PreferKdeURLs, so it retrieves the desktop:/ URL from the FV drag
but not the Dolphin drag (since it lacks it)
- Thus the Icon applet is handed a desktop:/ URL in the FV case, which
the code - not using KIO - isn't written to handle
This patch adds an async KIO::StatJob to the Icon code when
QURL::isLocalFile is fast to try and resolve an URL to a more local
one the rest of the code can handle.
Rewriting more of the Icon code to use KIO /would/ have been nice,
however it ultimately ends up using KDesktopFile which can't handle
non-local files, so at some point resolving to the proxied-for path
would happen anyway.
BUG:356548
This is the beginning of revision history for this module. If you
want to look at revision history older than this, please refer to the
techbase wiki for how to use Git history grafting. At the time of
writing, this wiki is located here:
http://community.kde.org/Frameworks/GitOldHistory
If you have already performed the grafting and you don't see any
history beyond this commit, try running "git log" with the "--follow"
argument.
Branched from the monolithic repo kde-workspace, frameworks branch, at commit
049113e719dd2fc4446d054fa1a3aada330094f0