--001a11c2c54c108b6b04ea7df6bd Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 5, 2013 at 9:49 PM, Matthias Klumpp wrote: > 2013/11/5 Todd : > > [...] > > Looking at the spec, I have a few suggestions: > (I assume you mean the AppStream spec) > > For , 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?". --001a11c2c54c108b6b04ea7df6bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= ue, 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. =A0This is an= other
> 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. An= d I
am not planning to change that ;-)


That isn't= clear from the description.
=A0
> I also think sleeping multiple groups and/or sub-groups. =A0KDE at lea= st had
> sub-groups like KDE edu, KDE multimedia, and calligra. =A0I think it w= ould be
> good for apps to be able to identify themselves as belonging to one of= these
> groups. =A0I 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, th= e
applications are part of the KDE umbrella project. Mozilla also has a
"Mozilla Messaging" department, but it is still listed as "M= ozilla".
I am not sure of what value adding subgroups would bring to the users...


Amarok is a mu= ltimedia program under the KDE umbrella, but it is not a KDE-multimedia app= .=A0 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 applicat= ions.

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.
=A0
> 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 displ= ay the
> change log (that is something that bothers me about YaST, you can only= view
> a change log after the app is installed). =A0It needs to be in a reaso= nably
> consistent format so the app store can extract the changes for the mos= t
> recent version, the date of the last release, and the most recent vers= ion
> number. =A0The Android app store provides this information, for exampl= e.
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.<= br>

That would still require standardizing = distributor's changelogs.
=A0
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 diffi= cult than getting them to write appdata files?
=A0
> Regarding mimetypes, I recall there had been some concern over apps th= at get
> their mimetypes dynamically either at build-time or runtime from other= apps
> or libraries. =A0Might this be a good opportunity to find a solution t= o 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. = =A0The
> 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.
=A0
> For a more extreme question, is there a reason all this information ca= nnot
> just be put into the .desktop file, or an additional .desktop file? = =A0Why
> does this have to be an xml file? =A0It seems like a lot of the inform= ation is
> either parsed from the .desktop file or identical to the .desktop file= . =A0Why
> can't we just extend the .desktop file spec, or include a modified=
> special-purpose .desktop file, to handle the missing bits? =A0This wil= l also
> solve issues like translation.
The nested screenshots are not possibl= e with desktop-file-layout, as
well as the long-description & co.


Not in the cur= rent standard, the question is "what is the advantage is of creating a= n entirely new standard with a lot of redundant information over just exten= ding the existing standard?".

--001a11c2c54c108b6b04ea7df6bd--