[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Adopting AppData in KDE?
From: Todd <toddrjen () gmail ! com>
Date: 2013-11-06 8:30:06
Message-ID: CAFpSVp+F1OFXGmA7PqwWfGe74JKh+yDsf4+pATgGJbHDfH9nZQ () mail ! gmail ! com
[Download RAW message or body]
On Tue, Nov 5, 2013 at 9:49 PM, Matthias Klumpp <matthias@tenstral.net>wrote:
> 2013/11/5 Todd <toddrjen@gmail.com>:
> > [...]
> > Looking at the spec, I have a few suggestions:
> (I assume you mean the AppStream spec)
> > For <project_group/>, I think it would be good to allow arbitrary groups
> > rather than limiting it to only a few recognized groups. This is another
> > gatekeeper issue: no project our group would have the authority to say
> which
> > group is and is not acceptable.
> project_group allows arbitrary values already, the specs just say
> "known values include..." which is in no way a recommendation. And I
> am not planning to change that ;-)
>
>
That isn't clear from the description.
> > I also think sleeping multiple groups and/or sub-groups. KDE at least
> had
> > sub-groups like KDE edu, KDE multimedia, and calligra. I think it would
> be
> > good for apps to be able to identify themselves as belonging to one of
> these
> > groups. I could also see an application providing, say, gnome/KDE
> > integration that could benefit from belonging to both groups.
> I think this would be overly confusing for users. Just say "KDE-Edu"
> or "KDE-Multimedia" would make some sense... But in all cases, the
> applications are part of the KDE umbrella project. Mozilla also has a
> "Mozilla Messaging" department, but it is still listed as "Mozilla".
> I am not sure of what value adding subgroups would bring to the users...
>
>
Amarok is a multimedia program under the KDE umbrella, but it is not a
KDE-multimedia app. People who want to install the full Calligra suite
would probably want to get a list of all Calligra applications, not a list
of all KDE applications.
I am not sure how it would be confusing, the app store could list all
applications under a particular umbrella, as well as groups under that
umbrella.
> > I think it would be good too either have a change log tag or a
> > machine-parseable change log spec that would allow app stores to display
> the
> > change log (that is something that bothers me about YaST, you can only
> view
> > a change log after the app is installed). It needs to be in a reasonably
> > consistent format so the app store can extract the changes for the most
> > recent version, the date of the last release, and the most recent version
> > number. The Android app store provides this information, for example.
> This is already done via PackageKit for the connected package.
> Including upstream information would require extra logic for parsing
> version numbers of every distribution, and it would require additional
> caches for chagelogs.
> I like the idea, but having distributor's changelogs is nicer at time.
>
That would still require standardizing distributor's changelogs.
> It also will be insanely difficult to get all app authors to write a
> machine-readable changelog and change the changelogs they are writing
> already.
>
>
Any more difficult than getting them to write appdata files?
> > Regarding mimetypes, I recall there had been some concern over apps
> that get
> > their mimetypes dynamically either at build-time or runtime from other
> apps
> > or libraries. Might this be a good opportunity to find a solution to
> this?
> > As with the add-ons I mentioned previously, the app-store can either
> > atomically download these plugins or allow the user to download them.
> The
> > details would be left up to the implementation I assume.
> This is slready done, some implementations exist :-)
>
>
Okay, it doesn't seem to be widely used though.
> For a more extreme question, is there a reason all this information cannot
> just be put into the .desktop file, or an additional .desktop file? Why
> does this have to be an xml file? It seems like a lot of the information
is
> either parsed from the .desktop file or identical to the .desktop file.
Why
> can't we just extend the .desktop file spec, or include a modified
> special-purpose .desktop file, to handle the missing bits? This will also
> solve issues like translation.
> The nested screenshots are not possible with desktop-file-layout, as
> well as the long-description & co.
>
>
Not in the current standard, the question is "what is the advantage is of
creating an entirely new standard with a lot of redundant information over
just extending the existing standard?".
[Attachment #3 (text/html)]
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 5, 2013 \
at 9:49 PM, Matthias Klumpp <span dir="ltr"><<a \
href="mailto:matthias@tenstral.net" \
target="_blank">matthias@tenstral.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">2013/11/5 Todd <<a \
href="mailto:toddrjen@gmail.com">toddrjen@gmail.com</a>>:<br> > [...]<br>
<div class="im">> Looking at the spec, I have a few suggestions:<br>
</div>(I assume you mean the AppStream spec)<br>
<div class="im">> For <project_group/>, I think it would be good to allow \
arbitrary groups<br> > rather than limiting it to only a few recognized groups. \
This is another<br> > gatekeeper issue: no project our group would have the \
authority to say which<br> > group is and is not acceptable.<br>
</div>project_group allows arbitrary values already, the specs just say<br>
"known values include..." which is in no way a recommendation. And I<br>
am not planning to change that ;-)<br>
<div class="im"><br></div></blockquote><div><br></div><div>That isn't clear from \
the description.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 \
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> I also think sleeping multiple groups and/or sub-groups. KDE at least had<br>
> sub-groups like KDE edu, KDE multimedia, and calligra. I think it would be<br>
> good for apps to be able to identify themselves as belonging to one of these<br>
> groups. I could also see an application providing, say, gnome/KDE<br>
> integration that could benefit from belonging to both groups.<br>
</div>I think this would be overly confusing for users. Just say \
"KDE-Edu"<br> or "KDE-Multimedia" would make some sense... But in \
all cases, the<br> applications are part of the KDE umbrella project. Mozilla also \
has a<br> "Mozilla Messaging" department, but it is still listed as \
"Mozilla".<br> I am not sure of what value adding subgroups would bring to \
the users...<br> <div class="im"><br></div></blockquote><div><br></div><div>Amarok is \
a multimedia program under the KDE umbrella, but it is not a KDE-multimedia app. \
People who want to install the full Calligra suite would probably want to get a list \
of all Calligra applications, not a list of all KDE applications.<br>
<br></div><div>I am not sure how it would be confusing, the app store could list all \
applications under a particular umbrella, as well as groups under that \
umbrella.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> I think it would be good too either have a change log tag or a<br>
> machine-parseable change log spec that would allow app stores to display the<br>
> change log (that is something that bothers me about YaST, you can only view<br>
> a change log after the app is installed). It needs to be in a reasonably<br>
> consistent format so the app store can extract the changes for the most<br>
> recent version, the date of the last release, and the most recent version<br>
> number. The Android app store provides this information, for example.<br>
</div>This is already done via PackageKit for the connected package.<br>
Including upstream information would require extra logic for parsing<br>
version numbers of every distribution, and it would require additional<br>
caches for chagelogs.<br>
I like the idea, but having distributor's changelogs is nicer at \
time.<br></blockquote><div><br></div><div>That would still require standardizing \
distributor's changelogs.<br></div><div> </div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It also will be insanely difficult to get all app authors to write a<br>
machine-readable changelog and change the changelogs they are writing<br>
already.<br>
<div class="im"><br></div></blockquote><div><br></div><div>Any more difficult than \
getting them to write appdata files?<br></div><div> </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<div class="im">
> Regarding mimetypes, I recall there had been some concern over apps that get<br>
> their mimetypes dynamically either at build-time or runtime from other apps<br>
> or libraries. Might this be a good opportunity to find a solution to this?<br>
> As with the add-ons I mentioned previously, the app-store can either<br>
> atomically download these plugins or allow the user to download them. The<br>
> details would be left up to the implementation I assume.<br>
</div>This is slready done, some implementations exist :-)<br>
<div class="im"><br></div></blockquote><div><br></div><div>Okay, it doesn't seem \
to be widely used though.<br></div><div class="im"> <br> > For a more extreme \
question, is there a reason all this information cannot<br> > just be put into the \
.desktop file, or an additional .desktop file? Why<br> > does this have to be an \
xml file? It seems like a lot of the information is<br> > either parsed from the \
.desktop file or identical to the .desktop file. Why<br> > can't we just \
extend the .desktop file spec, or include a modified<br> > special-purpose \
.desktop file, to handle the missing bits? This will also<br> > solve issues like \
translation.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">The nested screenshots are not \
possible with desktop-file-layout, as<br> well as the long-description & co.<br>
<div class="im"><br></div></blockquote><div><br></div><div>Not in the current \
standard, the question is "what is the advantage is of creating an entirely new \
standard with a lot of redundant information over just extending the existing \
standard?".<br>
</div></div><br></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic