Hi,
I've been asked by Richard Hughes from Gnome and Fedora to raise the
profile of using AppData metadata within KDE. I know very little
about this area myself, but thought it was worthwhile raising on the
list for discussion. If you have any questions about AppData then
Richard would be happy
On 2 November 2013 09:27, John Layt wrote:
> The new Gnome Software
> Centre in Gnome 3.12 which uses AppData will become the default
> installer in Fedora 20 for Gnome (Fedora KDE will use Apper).
Slight correction. We're shipping gnome-software 3.10.x in Fedora 20,
3.12.x in Fedora 21, and 3.14
Okay... Couple of questions:
* screenshot: which theme/color scheme should be used (btw, for Krita, on
Gnome3, Plastique is hard-coded, because other themes are broken.)
* license: is that the license of the appdata file or of the application?
* How much of marketing and how much of dry descripti
On Saturday, November 2, 2013 09:27:18 John Layt wrote:
> One obvious question is how this might relate to Bodega if KDE chooses
> to switch to that?
The same files could be used to generate asset descriptions for use with
Bodega.
>What does Gnome shipping their own official "App
> Store" mean
2013/11/2 Aaron J. Seigo :
> On Saturday, November 2, 2013 09:27:18 John Layt wrote:
>> One obvious question is how this might relate to Bodega if KDE chooses
>> to switch to that?
>
> The same files could be used to generate asset descriptions for use with
> Bodega.
>
>>What does Gnome shipping th
On Saturday, November 2, 2013 14:35:10 Matthias Klumpp wrote:
> > OCS is, generally, horribly designed. I am even hesitant to use the word
> > ‘design’ in combination with OCS. It is really that bad, and why we did
> > not
> > use it for Bodega.
>
> I agree with that, and this is the reason why I
On 2 November 2013 11:00, Yuri Chornoivan wrote:
> 1. AppData files are tailored for intltool/its-tool processing (tags with
> underscores). What do you think about adding untranslatable by design appdata
> files like it was done for Audacity [1]?
Well, this is fine if you speak en_GB or en_US,
On 2 November 2013 11:53, Boudewijn Rempt wrote:
> * screenshot: which theme/color scheme should be used (btw, for Krita, on
> Gnome3, Plastique is hard-coded, because other themes are broken.)
For a KDE app, I suppose Plastique --
http://people.freedesktop.org/~hughsient/appdata/#screenshots
ba
2013/11/2 Richard Hughes :
> On 2 November 2013 11:00, Yuri Chornoivan wrote:
>> 1. AppData files are tailored for intltool/its-tool processing (tags with
>> underscores). What do you think about adding untranslatable by design
>> appdata files like it was done for Audacity [1]?
>
> Well, this i
On 2 November 2013 13:35, Matthias Klumpp wrote:
>> OCS is, generally, horribly designed. I am even hesitant to use the word
>> ‘design’ in combination with OCS. It is really that bad, and why we did not
>> use it for Bodega.
> I agree with that, and this is the reason why I currently question the
On 2 November 2013 14:34, Matthias Klumpp wrote:
> Yes, scripty could do that. It would make the files less readable an
> probably very huge, but it is certainly possible. I could imagine
> allowing PO files as translation sources, which are referenced from
> the XML, as long as Richard doesn't ha
On 2 November 2013 09:50, Richard Hughes wrote:
> https://github.com/hughsie/appdata-tools/issues/7 and I'd be very open
> to spec improvement ideas.
Apologies for replying to my own mail, but I forgot to mention the
appdata-tools repo[1] which has the appdata-validate command. It's
packaged in F
On Saturday 02 November 2013 14:37:02 Richard Hughes wrote:
> Well, I've not done any technical review of the OCS code, but in
> Fedora I've chosen to use fedora-tagger for ratings and comments. It's
> not hardcoded and I'd be open to doing something else.
I have worked with OCS in the past on a te
On 2 November 2013 15:10, Yuri Chornoivan wrote:
>> Depends on the format, have you got any examples of what it looks like?
> An example attached.
Well, isn't a recognised tag (See
http://people.freedesktop.org/~hughsient/appdata/#description) but
using xml:lang="foo" is exactly what intltool p
On Saturday 02 November 2013 12:53:14 Boudewijn Rempt wrote:
> Okay... Couple of questions:
>
> * screenshot: which theme/color scheme should be used (btw, for Krita, on
> Gnome3, Plastique is hard-coded, because other themes are broken.)
You want to sell your app to the user: use what makes it lo
On Sat, 2 Nov 2013, Martin Graesslin wrote:
On Saturday 02 November 2013 12:53:14 Boudewijn Rempt wrote:
Okay... Couple of questions:
* screenshot: which theme/color scheme should be used (btw, for Krita, on
Gnome3, Plastique is hard-coded, because other themes are broken.)
You want to sell y
El Dissabte, 2 de novembre de 2013, a les 09:27:18, John Layt va escriure:
> Some recent developments make this a fairly high priority for apps
> that wish to target a cross-desktop audience. The new Gnome Software
> Centre in Gnome 3.12 which uses AppData will become the default
> installer in Fe
On 2 November 2013 19:33, Albert Astals Cid wrote:
> What's the point in having an installer that hides more than half of the apps
> in the world that don't ship a file that is not a standard and doesn't seem to
> me it was developed as a standard? How is this useful to the end user?
We want to s
On Saturday 02 November 2013 19:48:01 Richard Hughes wrote:
> On 2 November 2013 19:33, Albert Astals Cid wrote:
> > What's the point in having an installer that hides more than half of the
> > apps in the world that don't ship a file that is not a standard and
> > doesn't seem to me it was develo
On Sat, Nov 2, 2013 at 8:48 PM, Richard Hughes wrote:
> On 2 November 2013 19:33, Albert Astals Cid wrote:
>> What's the point in having an installer that hides more than half of the apps
>> in the world that don't ship a file that is not a standard and doesn't seem
>> to
>> me it was developed
On 2 November 2013 20:00, Harald Sitter wrote:
>> We want to showcase high quality applications with active upstream
>> maintainers.
> Who's doing the quality review?
Well, if an upstream ships a valid .desktop file and a valid AppData
file then that's a good indication it's at least alive. For t
On Saturday 02 November 2013 20:05:11 Richard Hughes wrote:
> > Who's doing the quality review?
> Well, if an upstream ships a valid .desktop file and a valid AppData
> file then that's a good indication it's at least alive.
I don't understand that. It's a good indication it's alive right now, but
On 2 November 2013 20:11, Sven Brauch wrote:
> I don't understand that. It's a good indication it's alive right now, but
> that's just because the spec is new. In three years the presence of such a
> file will indicate exactly nothing, or will it?
That's kinda true I guess. We will be adding thin
2013/11/2 Richard Hughes :
> On 2 November 2013 20:00, Harald Sitter wrote:
>>> We want to showcase high quality applications with active upstream
>>> maintainers.
>> Who's doing the quality review?
>
> Well, if an upstream ships a valid .desktop file and a valid AppData
> file then that's a good
2013/11/2 Nicolás Alvarez :
> 2013/11/2 Richard Hughes :
>> On 2 November 2013 20:00, Harald Sitter wrote:
We want to showcase high quality applications with active upstream
maintainers.
>>> Who's doing the quality review?
>>
>> Well, if an upstream ships a valid .desktop file and a vali
El Dissabte, 2 de novembre de 2013, a les 19:48:01, Richard Hughes va
escriure:
> On 2 November 2013 19:33, Albert Astals Cid wrote:
> > What's the point in having an installer that hides more than half of the
> > apps in the world that don't ship a file that is not a standard and
> > doesn't see
On 3 Nov 2013 11:59, "Albert Astals Cid" wrote:
> I've never created a standard so I can't comment on how to do it
properly, but
> writing it and then "threatening" to exclude from package managers those
that
> don't adopt it doesn't seem to be a way to start a discussion to me
This is what we've
El Diumenge, 3 de novembre de 2013, a les 12:22:52, Richard Hughes va
escriure:
> On 3 Nov 2013 11:59, "Albert Astals Cid" wrote:
> > I've never created a standard so I can't comment on how to do it
>
> properly, but
>
> > writing it and then "threatening" to exclude from package managers those
On 3 November 2013 12:32, Albert Astals Cid wrote:
> I am all for listing "high quality applications", it's just that this just
> doesn't help.
Sure it does. We're not going to get AppData files for sodipodi,
cinepaint or arora any time soon. I don't think _having_ an AppData
file makes an applic
On Sunday 03 November 2013 12:22:52 Richard Hughes wrote:
> This is what we've decided to do in GNOME, KDE is free to decide any policy
> it wants. We've decided that 500 high quality applications are better than
> 3000 broken ones.
Assuming KDE did that, then we would end up with a situation wher
On 3 November 2013 13:30, Sven Brauch wrote:
> Assuming KDE did that, then we would end up with a situation where you can't
> easily install Krita in distributions that ship GNOME, and you can't easily
> install Inkscape in distributions that ship KDE.
I don't think that's true at all. Krita and
Richard, do you realize how you sound like?
"Nice application you have there, would be a shame if something would...
happen to it."
Imho it's a matter of respect to discuss a standard beforehand with a
community. And this threat to exclude apps, well...
Also, using this as a sign of quality is n
The whole discussion of whether gnome excludes apps without app-data
will improve the quality of those listed is sort of a moot topic.
We could do with this having this sort of metadata available for all KDE apps;
and in fact we already maintain this sort of data to build the pages
at http://kde.
On Sunday 03 November 2013 13:50:05 Richard Hughes wrote:
> I don't think that's true at all. Krita and Inkscape are two of the
> killer apps I'd love to feature more prominently in GNOME Software.
Yes, and of course both applications would do anything it takes to get listed
in the package manage
On 3 November 2013 14:04, Felix Rohrbach wrote:
> "Nice application you have there, would be a shame if something would...
> happen to it."
Not at all. If something as important as Krita didn't ship an AppData
file in Fedora 22, we'd just write one ourselves and put it in the
Fedora srpm file. I'
On Sunday 03 November 2013 15:09:13 David Edmundson wrote:
> That means we get Gnome app centre support, and if Muon want to use
> that spec - that'd be great too.
As far as I know Muon-packagekit is already using it (ot it s planned at
least).
Spec comments:
- The spec says to link to a .desktop file for the application.
This is typically installed with the application (or it is in KDE apps
anyway), I'm confused as to how this is intended to work.
- I would include project icon and project license in the file format.
Maybe this is link
El Diumenge, 3 de novembre de 2013, a les 13:24:40, Richard Hughes va
escriure:
> On 3 November 2013 12:32, Albert Astals Cid wrote:
> > I am all for listing "high quality applications", it's just that this just
> > doesn't help.
>
> Sure it does. We're not going to get AppData files for sodipod
Attached is an appdata xml file for every kde project.
http://static.davidedmundson.co.uk/kde_appdata.zip (note, I have not
tested these in anything)
and the script to generate it
http://static.davidedmundson.co.uk/appdata_generator.txt
(requires an "svn checkout
svn://anonsvn.kde.org/home/kde/
On Sonntag, 3. November 2013 16:28:56 CEST, Albert Astals Cid wrote:
El Diumenge, 3 de novembre de 2013, a les 13:24:40, Richard Hughes va
escriure:
On 3 November 2013 12:32, Albert Astals Cid wrote:
I am all for listing "high quality applications", it's just
that this just
doesn't help.
Su
On 3 November 2013 17:15, Thomas Lübking wrote:
> I think everyone who read this thread was immediately aware that the "high
> quality applications" argument is "flawed" (i've actually another term in
> mind)
Sure, that might be true, but that's not what I was originally trying
to help with. AppD
2013/11/3 Richard Hughes :
> On 3 November 2013 17:15, Thomas Lübking wrote:
>> * does it presently qualify as "standard" at all? (not as long as it states
>> particular tools - like gnome i18n, as claimed by David)
>
> Well, it's my standard, and I'm happy to do the extra work if any
> other desk
Matthias Klumpp wrote:
> The current
> AppStream library uses GObject/GLib, which can be used without
> problems from any Qt app
this one? https://gitorious.org/appstream/
Are there any formal releases/tarballs? (I'm having trouble finding any)
It appears apper needs this to enable appstream
Rex Dieter wrote:
> Matthias Klumpp wrote:
>
>> The current
>> AppStream library uses GObject/GLib, which can be used without
>> problems from any Qt app
>
> this one? https://gitorious.org/appstream/
>
> Are there any formal releases/tarballs? (I'm having trouble finding any)
My googling fa
2013/11/4 Rex Dieter :
> Rex Dieter wrote:
>
>> Matthias Klumpp wrote:
>>
>>> The current
>>> AppStream library uses GObject/GLib, which can be used without
>>> problems from any Qt app
>>
>> this one? https://gitorious.org/appstream/
>>
>> Are there any formal releases/tarballs? (I'm having trou
Richard Hughes wrote:
>
>Please don't portray me as a modern-day highwayman as I'm really just
>trying to build an awesome application installer for GNOME. It's two
>orders of magnitude harder to actually write a shared standard and ask
>other desktops to adopt it (making changes as required) ra
> Hi,
>
> I've been asked by Richard Hughes from Gnome and Fedora to raise the
> profile of using AppData metadata within KDE. I know very little
> about this area myself, but thought it was worthwhile raising on the
> list for discussion. If you have any questions about AppData then
> Richard w
написане Sat, 02 Nov 2013 16:38:48 +0200, Richard Hughes
:
On 2 November 2013 14:34, Matthias Klumpp wrote:
Yes, scripty could do that. It would make the files less readable an
probably very huge, but it is certainly possible. I could imagine
allowing PO files as translation sources, which a
On Sunday 03 November 2013 12:49:52 henry miller wrote:
> Let me rewritte the above into a FAQ format:
> Q: Why does KDE not ship appdata files
> A: the maintainers of appdata have admited they have no interest in
> standards, thus KDE has no formal ability to get things we need changed.
> In addi
Hey! :)
We (Muon) currently use AppStream in the PackageKit-Plugin, which is about to
be merged into master.
Adopting AppData would give us a lot more data about applications, which would
be awesome, as we currently lack e.g. long application descriptions.
I don't really care much about spec d
On Sunday 03 November 2013 12:49:52 henry miller wrote:
> Richard Hughes wrote:
> >Please don't portray me as a modern-day highwayman as I'm really just
> >trying to build an awesome application installer for GNOME. It's two
> >orders of magnitude harder to actually write a shared standard and ask
Oh my this is a really long thread...
GNOME Software Center can show/hide
any applications they want, they can even
just choose to hide all KDE/Qt apps just
for the sake of not liking them.
AppData and AppStream have to some
extend little to do with GNOME Software
Center on our land, most KDE
Hi,
what would be nice to have is information about which MIME types an
application can read and write.
Christoph Feck (kdepepo)
KDE Quality Team
On 4 November 2013 17:32, Christoph Feck wrote:
> what would be nice to have is information about which MIME types an
> application can read and write.
This is already in the .desktop file, and is thus extracted into the
AppStream metadata.
Richard.
2013/11/4 Christoph Feck :
> Hi,
>
> what would be nice to have is information about which MIME types an
> application can read and write.
Take a look at the AppStream spec:
http://www.freedesktop.org/software/appstream/docs/chap-AppStream-Metadata.html#sect-AppStream-Metadata-ASXML
;-)
Cheers,
On 4 November 2013 20:56, Weng Xuetian wrote:
> Some questions:
> 1. What about non-application case?
In GNOME we only consider an application to have a desktop file
without NoDisplay=true. That's probably a desktop-level choice tho.
> 2. What if an application doesn't actually have an window, o
On 4 November 2013 21:29, Weng Xuetian wrote:
> It's not about NoDisplay, plasmoids is a kind of widgets on KDE desktop, it
> also use desktop file to store metadata, though it's not sit in
> share/applications but some kde private folder. But each small widget is like
> an small application.
The
Sven Brauch wrote:
>Let's not make a fight of this. I think the point that some people
>(including
>me) didn't find the strategy for creating a standard quite optimal was
>made,
>and we should drop it now and focus on discussing the adoption of the
>specification.
>
I want to formally state
On Monday, November 04, 2013 08:58:22 PM Richard Hughes wrote:
> On 4 November 2013 20:56, Weng Xuetian wrote:
> > Some questions:
> > 1. What about non-application case?
>
> In GNOME we only consider an application to have a desktop file
> without NoDisplay=true. That's probably a desktop-level
Some questions:
1. What about non-application case?
KDE plasmoid, and some kcm worked as a plugin in system setttings, some of
them also present a desktop, which doesn't theoratically an application, but I
think should be able to install from app center.
2. What if an application doesn't actuall
On Tuesday, November 5, 2013 08:28:08 Richard Hughes wrote:
> On 4 November 2013 21:29, Weng Xuetian wrote:
> > It's not about NoDisplay, plasmoids is a kind of widgets on KDE desktop,
> > it
> > also use desktop file to store metadata, though it's not sit in
> > share/applications but some kde pr
On 5 November 2013 12:06, Aaron J. Seigo wrote:
> plasmapkg -i
Sure, but what does that do? Does that copy a file in a special
directory or something?
Richard.
On Tuesday, November 5, 2013 12:08:57 Richard Hughes wrote:
> On 5 November 2013 12:06, Aaron J. Seigo wrote:
> > plasmapkg -i
>
> Sure, but what does that do?
it should be of no concern to the installer. what it does is an implementation
detail. it may even change between major versions, as i
On 5 November 2013 12:18, Aaron J. Seigo wrote:
> why do you need to know this? can AppStream not call external tools to do the
> installation?
The way AppStream is generated in Fedora is we:
* Take the binary rpm file
* Explode it somewhere (without installing it)
* Parse the contents
* Write a
On Tuesday, November 5, 2013 12:57:28 Richard Hughes wrote:
> On 5 November 2013 12:18, Aaron J. Seigo wrote:
> > why do you need to know this? can AppStream not call external tools to do
> > the installation?
>
> The way AppStream is generated in Fedora is we:
ok ... this is separate from App D
2013/11/5 Aaron J. Seigo :
> On Tuesday, November 5, 2013 12:57:28 Richard Hughes wrote:
>> On 5 November 2013 12:18, Aaron J. Seigo wrote:
>> > why do you need to know this? can AppStream not call external tools to do
>> > the installation?
>>
>> The way AppStream is generated in Fedora is we:
>
On Nov 5, 2013 12:49 PM, "Weng Xuetian" wrote:
>
> On Monday, November 04, 2013 08:58:22 PM Richard Hughes wrote:
> > On 4 November 2013 20:56, Weng Xuetian wrote:
> > > Some questions:
> > > 1. What about non-application case?
> >
> > In GNOME we only consider an application to have a desktop fi
On 5 November 2013 17:12, Todd wrote:
> For , 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.
> I think it would be good too either have a change log tag o
On Nov 5, 2013 5:18 PM, "Todd" wrote:
>
>
> On Nov 5, 2013 12:49 PM, "Weng Xuetian" wrote:
> >
> > On Monday, November 04, 2013 08:58:22 PM Richard Hughes wrote:
> > > On 4 November 2013 20:56, Weng Xuetian wrote:
> > > > Some questions:
> > > > 1. What about non-application case?
> > >
> > > In
On 5 November 2013 17:37, Todd wrote:
>> Define ChangeLog? You mean what changed between versions?
> Yes, as well as the version number and date, probably.
I'd be open to ideas about this. Can you file an issue and we can talk
about possible ideas there.
>> In this case you can specify the mimet
On 5 November 2013 18:42, Todd wrote:
> Okay, but if this is going to be a separate file with outs own spec then it
> is probably outside the scope of this project. But the two efforts could be
> coordinated.
Well, I'm not saying it's out of scope for AppData, I'm simply saying
it needs discussi
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
Hi!
In order to solve the translation-issues: I think KDE could very well
use Scripty to insert translations into the AppData files. However, I
am currently thinking about adding a new element to specify a
gettext-domian to fetch trabslations from. The problem is that, in
order for the AppStream ge
2013/11/5 Matthias Klumpp :
> Hi!
> In order to solve the translation-issues: I think KDE could very well
> use Scripty to insert translations into the AppData files. However, I
> am currently thinking about adding a new element to specify a
> gettext-domian to fetch trabslations from. The problem
On Saturday 02 November 2013 15:06:26 Aaron J. Seigo wrote:
> On Saturday, November 2, 2013 14:35:10 Matthias Klumpp wrote:
> What I see as truly invaluable in AppStream is standardizing the metadata
> for Free software applications. It is something Bodega will undoubtedly
> benefit from as well.
2013/11/5 Marco Martin :
> [...]
>> > > 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 app
On 6 November 2013 03:49, T.C. Hollingsworth wrote:
> Unfortunately, the schema says the latter is invalid. Is the schema
> wrong or intltool wrong?
This is what we do in GNOME:
https://git.gnome.org/browse/gnome-software/tree/data/appdata/org.gnome.Software.appdata.xml.in
gets translated by int
On Wednesday, 2013-11-06, 08:40:56, Richard Hughes wrote:
> On 6 November 2013 03:49, T.C. Hollingsworth
wrote:
> > If we have to do it by paragraph, having scripty merge the
> > translations back into the original XML is going to be ugly...
>
> The reasons I chose to do it this way were mainly
On Wednesday 06 November 2013 00:04:47 Matthias Klumpp wrote:
> 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,
On Wednesday, November 6, 2013 00:04:47 Matthias Klumpp wrote:
> Plasmoids might make sense to be only displayed on KDE
...
> Extensions on KDE). If these things would be treated as applications
This is honestly an area where I don’t see much point in pushing AppStream
further.
As a front-end fo
On 6 November 2013 08:55, Kevin Krammer wrote:
> Do you expect to support partial translations? I.e. one paragraph translated,
> followed by an untranslated one?
Sure, we support that. Imagine the following paragraphs in locale C:
This is what the color management program does:
It's awesome
And
On Wednesday, 2013-11-06, 12:55:40, Richard Hughes wrote:
> On 6 November 2013 08:55, Kevin Krammer wrote:
> > Do you expect to support partial translations? I.e. one paragraph
> > translated, followed by an untranslated one?
>
> Sure, we support that. Imagine the following paragraphs in locale C
On 6 November 2013 20:51, T.C. Hollingsworth wrote:
> For instance, in Fedora we're probably going to be stuck with having
> AppData included as SourceN files in SRPMs for quite some time.
No, if this is the case then I've failed. I want the AppData files to
live upstream, controlled and modified
On Tue, Nov 5, 2013 at 6:21 PM, Richard Hughes wrote:
> On 5 November 2013 17:12, Todd wrote:
> > For , 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
> se
On Nov 5, 2013 6:42 PM, "Richard Hughes" wrote:
>
> On 5 November 2013 17:37, Todd wrote:
> >> Define ChangeLog? You mean what changed between versions?
> > Yes, as well as the version number and date, probably.
>
> I'd be open to ideas about this. Can you file an issue and we can talk
> about po
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.
On Tue, Nov 5, 2013 at 1:53 PM, Matthias Klumpp wrote:
> Hi!
> In order to solve the translation-issues: I think KDE could very well
> use Scripty to insert translations into the AppData files.
I wrote a draft patch to do this already:
http://lists.kde.org/?l=kde-i18n-doc&m=138353976230003&w=2
T
On Wed, Nov 6, 2013 at 1:40 AM, Richard Hughes wrote:
> I'm not sure how well this will work, at least in gnome-software we
> allow the user to match on a keyword cache using the "C" name, and
> also the UTF8 and normalized versions of their current locale.
Nah, I meant for the extractor tools to
88 matches
Mail list logo
