[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-05 17:37:46
Message-ID: CAFpSVpLf7iqDJ=afz5QVo_+GJNH1fkcojstH0PQFXPR97vjS2g () mail ! gmail ! com
[Download RAW message or body]
On Tue, Nov 5, 2013 at 6:21 PM, Richard Hughes <hughsient@gmail.com> wrote:
> On 5 November 2013 17:12, Todd <toddrjen@gmail.com> wrote:
> > For <project_group/>, I think it would be good to allow arbitrary groups
> > rather than limiting it to only a few recognized groups.
>
> I think restricting it to the desktops specified in the menu-spec makes
> sense.
>
>
It already has non-desktop projects than that (such as "mozilla"). And the
description ("specific upstream umbrella project") doesn't imply that the
"umbrella project" is necessarily tied to a particular desktop
environment.
> > 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
>
> Define ChangeLog? You mean what changed between versions?
>
>
Yes, as well as the version number and date, probably.
> > 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?
>
> In this case you can specify the mimetypes in the desktop file.
>
>
Yes, if you know beforehand what mimetypes your application will support.
But this isn't always the case.
> > It might be good to have an email address for the person or mailing list
> > responsible for the file.
>
> That's what <update_contact> is used for.
>
>
Good to hear. That should probably be added here:
http://www.freedesktop.org/software/appstream/docs/chap-AppStream-Metadata.html#sect-AppStream-Metadata-ASXML
> > Screenshots are available, but what about videos?
>
> Already filed: https://github.com/hughsie/appdata-tools/issues/9
>
>
Okay, good.
> > Does the <id/> tag really need to have the .desktop extension? Can't
> this
> > be specified by the type? So if it is "desktop" type, it can
> automatically
> > add the .desktop extension.
>
> No, as we'll be supporting other kinds of desktop applications in he
> future, e.g. glick2 bundles and that kind of thing.
>
>
Couldn't you just set another type for those? Or, if the literal file name
is not present, add a .desktop extension? Anyway, although it is present
in the example, this should probably be made explicit in the description.
> > For a more extreme question, is there a reason all this information
> cannot
> > just be put into the .desktop file
>
> You can't put multiline descriptions in a desktop file, or have
> multiple screenshots with localized captions, unless you *really*
> start to abuse the specification.
>
>
The specification can be updated, though, right? Can't new fields and
valuetypes be added for those things? It is a choice between extending an
existing spec or creating an entirely new one.
[Attachment #3 (text/html)]
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 5, 2013 at 6:21 PM, Richard \
Hughes <span dir="ltr"><<a href="mailto:hughsient@gmail.com" \
target="_blank">hughsient@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div class="im">On 5 November 2013 17:12, Todd <<a \
href="mailto:toddrjen@gmail.com">toddrjen@gmail.com</a>> wrote:<br>
> For <project_group/>, I think it would be good to allow arbitrary groups<br>
> rather than limiting it to only a few recognized groups.<br>
<br>
</div>I think restricting it to the desktops specified in the menu-spec makes sense.<br>
<div class="im"><br></div></blockquote><div><br></div><div>It already has non-desktop projects than that \
(such as "mozilla"). And the description ("<a name="project_group">specific upstream \
umbrella project") doesn't imply that the "umbrella project" is necessarily tied to a \
particular desktop environment. <br>
</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px \
solid rgb(204,204,204);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<br>
<br>
</div>Define ChangeLog? You mean what changed between versions?<br>
<div class="im"><br></div></blockquote><div><br></div><div>Yes, as well as the version number and date, \
probably.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);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>
<br>
</div>In this case you can specify the mimetypes in the desktop file.<br>
<div class="im"><br></div></blockquote><div><br></div><div>Yes, if you know beforehand what mimetypes \
your application will support. But this isn't always the case.<br></div><div> </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">
<div class="im">
> It might be good to have an email address for the person or mailing list<br>
> responsible for the file.<br>
<br>
</div>That's what <update_contact> is used for.<br>
<div class="im"><br></div></blockquote><div><br></div><div>Good to hear. That should probably be added \
here: <a href="http://www.freedesktop.org/software/appstream/docs/chap-AppStream-Metadata.html#sect-AppStr \
eam-Metadata-ASXML">http://www.freedesktop.org/software/appstream/docs/chap-AppStream-Metadata.html#sect-AppStream-Metadata-ASXML</a><br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div class="im"> > Screenshots are available, but what about \
videos?<br> <br>
</div>Already filed: <a href="https://github.com/hughsie/appdata-tools/issues/9" \
target="_blank">https://github.com/hughsie/appdata-tools/issues/9</a><br> <div \
class="im"><br></div></blockquote><div><br></div><div>Okay, good.<br> </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div class="im"> > Does the <id/> tag really need to have the \
.desktop extension? Can't this<br> > be specified by the type? So if it is "desktop" \
type, it can automatically<br> > add the .desktop extension.<br>
<br>
</div>No, as we'll be supporting other kinds of desktop applications in he<br>
future, e.g. glick2 bundles and that kind of thing.<br>
<div class="im"><br></div></blockquote><div><br></div><div>Couldn't you just set another type for \
those? Or, if the literal file name is not present, add a .desktop extension? Anyway, although it is \
present in the example, this should probably be made explicit in the description.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div class="im"> > For a more extreme question, is there a reason \
all this information cannot<br> > just be put into the .desktop file<br>
<br>
</div>You can't put multiline descriptions in a desktop file, or have<br>
multiple screenshots with localized captions, unless you *really*<br>
start to abuse the specification.<br>
<span class=""><font color="#888888"><br></font></span></blockquote><div><br></div></div>The \
specification can be updated, though, right? Can't new fields and valuetypes be added for those \
things? It is a choice between extending an existing spec or creating an entirely new one.<br>
</div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic