Adopting AppData in KDE?

Matthias Klumpp matthias at tenstral.net
Tue Nov 5 23:04:47 GMT 2013


2013/11/5 Marco Martin <notmart at gmail.com>:
> [...]
>> > > use cases (not to mention more general web based ones) unserviced.
>> > Can you please clarify what AppStream is missing for mobile?
>>
>> Ignoring the lack of UI (that’s fixable): non-repository  based listings and
>> installation, anything that isn’t an application.
>
> on the other hand a bit that may be useful for us is the part of installing
> from repositories and a semi-automated import of assets based on the metadata
> of existing applications
The installation bit is handled by Listaller, another project making
use of some AppStream facilities and providing cross-distro app
packages. However, this does not solve the non-application cases. Some
time ago, I was asked to include that in Listaller's scope, but I
decided against it at that time, because it looked like something
which should better be handled per-desktop.
Ideally, Bodega would combine data from lots of different sources and
display them in an user-friendly way. Thanks to PackageKit, nobody has
to care about the details of PM anymore when writing apps like this,
thanks to AppStream, metadata about applications is available to
display them nicely, and Listaller might add cross-distro software
sources to the list (for that case, GNOME is cooking up Glick2, which
is technically different).
Btw, thinks like Plasmoids might make sense to be only displayed on
KDE, because they aren't useful on GNOME (same applies for GNOME-Shell
Extensions on KDE). If these things would be treated as applications
in software-centers, I could add a "type="plasmoid" /
"gnome-shell-extension" to the AppStream spec (we'd still have to
solve the icon-source case, but that's rather trivial).
Cheers,
    Matthias

-- 
Debian Developer | Freedesktop-Developer
KDE-Developer    | GNOME-Contributor
I welcome VSRE emails. See http://vsre.info/




More information about the kde-core-devel mailing list