Summary:
Those information mostly clutter the plasmoid UI and are not very useful in the energy plasmoid
The battery plasmoid represents the state of the battery, for battery information we have the Energy information KCM in kinfocenter that will display this after D23152 .
Test Plan:
Before:
{F7257309}
After:
{F7257310}
Reviewers: ngraham, #plasma, broulik, #vdg, filipf
Reviewed By: ngraham, #vdg, filipf
Subscribers: apol, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D23237
Properties like Identity, SupportedUriSchemes, SupportedMimeTypes are mandatory.
Ignore the player if it's clearly violating the spec.
CHANGELOG: Players not compliant to MPRIS specification will no longer work with Media Controller applet.
Differential Revision: https://phabricator.kde.org/D22596
Summary:
It wasn't ported before due to the slot being overloaded.
Code became cleaner if we renamed one of the private slots.
Test Plan: Compiles
Reviewers: #plasma, sitter
Reviewed By: sitter
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D22841
Summary: It seems it's unused and also is the only source code in all of the KDE repos that uses kjsembed
Reviewers: davidedmundson
Reviewed By: davidedmundson
Subscribers: apol, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D22691
Summary:
Ejecting e.g. a USB stick removes it from the bus (bus power is removed),
but the last notification should be kept, otherwise a message like
"The device can be savely removed" immediately disappears.
Unfortunately it is almost impossible to tell when a device has been
physically removed (only indirectly, when a new device is plugged into
the same port), so allow some small leakage - in case the same device is
later replugged, no leakage happens.
Test Plan:
Card reader:
1.insert medium, mount, unmount
-> message "Device can be savely removed" is shown in device notifier
for 5 seconds
2. eject medium, reinsert
-> device appears without message and with default label
Reviewers: #plasma, broulik, ngraham
Reviewed By: ngraham
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D22312
Summary:
it was the only remaining user of that dialog helper.
the connection between the two was fairly meh. the engine would invoke the
kded module over dbus, the module would then process the request, find that
only one desktop entry is specified, resulting in one action being found
and then running that action on behalf of the engine. this is overly
complicated for no additional gain. the engine is the sole user of this
functionality AND it already had knowledge of the service system, so
soliduiserver in this case doesn't actually add anything. it's just a more
involved call chain.
the useful code of soliduiserver is now in the hotplug dataengine directly
and the soliduiserver no longer supports the actions dialog. hotplug is now
the sole authority for hotplugging.
soliduiserver:
- include cleanup
- all classes no longer in use have been removed
- kdelibs4support is no longer a link target
- new link targets i18n + widgetsaddons (previously pulled in by
kdelibs4support)
hotplug:
- hotplugjob now directly executes service actions using classes imported
from soliduiserver
- no longer links qtdbus
- new translation domain plasma_engine_hotplug (for i18n call in imported
service classes)
- new link against ki18n for that reason
Test Plan: running an action works same as before, internally it no longer relies on dbus/kded
Reviewers: broulik
Reviewed By: broulik
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D21761
Summary:
this engine is not used anywhere!
the engine used kfilemetadata to obtain metadata of a file. KFM however
is entirely defunct and does absolutely nothing without nepomuk.
that is to say: it is already broken for years and in fact not even
correctly sets the item.type key because of how the original code worked.
this change drops the kfilemetdata use altogether and instead sets the
item.type (which we can easily determine) to file when working with a file
in theory (I think) Baloo/File is the modern replacement for kfilemetadata,
but its properties are no longer "stringy" so we'd have to map a huge
enum manually into stringy keys for our representation. which at this time
seems not worth it, considering we (KDE) do not seem to use the engine
anymore and third parties would have had an entirely broken engine WRT file
sources as well, so I am guessing no one outside KDE uses it either.
all things considered I think simply rolling the engine back to the
minimum functional use is the best course of action here.
this effectively only changes the engine behavior to once again set
item.type=file on actual files while making it no longer require
kdelibs4support.
Test Plan:
in engine explorer requesting a directory gives unaltered directory data,
when requesting a file it correctly sets the type to file
Reviewers: davidedmundson
Reviewed By: davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D21765
l10n daemon script
Laurent Montel
David Edmundson
Shawn Starr
Méven Car
David Faure
Christophe Giboudeaux
Kai Uwe Broulik
Albert Astals Cid
Stefan Brüns
Harald Sitter