On Tue, Nov 5, 2013 at 6:21 PM, Richard Hughes hughsi...@gmail.com wrote:
On 5 November 2013 17:12, Todd toddr...@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
On Nov 5, 2013 6:42 PM, Richard Hughes hughsi...@gmail.com wrote:
On 5 November 2013 17:37, Todd toddr...@gmail.com 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
On Tue, Nov 5, 2013 at 9:49 PM, Matthias Klumpp matth...@tenstral.netwrote:
2013/11/5 Todd toddr...@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
On Tue, Nov 5, 2013 at 1:53 PM, Matthias Klumpp matth...@tenstral.net 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:
On Wed, Nov 6, 2013 at 1:40 AM, Richard Hughes hughsi...@gmail.com 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
On 6 November 2013 03:49, T.C. Hollingsworth tchollingswo...@gmail.com wrote:
Unfortunately, the schema says the latter is invalid. Is the schema
wrong or intltool wrong?
This is what we do in GNOME:
On Wednesday, 2013-11-06, 08:40:56, Richard Hughes wrote:
On 6 November 2013 03:49, T.C. Hollingsworth tchollingswo...@gmail.com
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
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, I
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 for
On 6 November 2013 08:55, Kevin Krammer kram...@kde.org 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:
pThis is what the color management program does:/p
On Wednesday, 2013-11-06, 12:55:40, Richard Hughes wrote:
On 6 November 2013 08:55, Kevin Krammer kram...@kde.org 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
On 6 November 2013 20:51, T.C. Hollingsworth tchollingswo...@gmail.com 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,
On 4 November 2013 21:29, Weng Xuetian wen...@gmail.com 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
Sven Brauch svenbra...@googlemail.com 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
On Monday, November 04, 2013 08:58:22 PM Richard Hughes wrote:
On 4 November 2013 20:56, Weng Xuetian wen...@gmail.com 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
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
On Tuesday, November 5, 2013 08:28:08 Richard Hughes wrote:
On 4 November 2013 21:29, Weng Xuetian wen...@gmail.com 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
On 5 November 2013 12:06, Aaron J. Seigo ase...@kde.org wrote:
plasmapkg -i pathtopackage
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 ase...@kde.org wrote:
plasmapkg -i pathtopackage
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
On 5 November 2013 12:18, Aaron J. Seigo ase...@kde.org 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
On Tuesday, November 5, 2013 12:57:28 Richard Hughes wrote:
On 5 November 2013 12:18, Aaron J. Seigo ase...@kde.org 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
2013/11/5 Aaron J. Seigo ase...@kde.org:
On Tuesday, November 5, 2013 12:57:28 Richard Hughes wrote:
On 5 November 2013 12:18, Aaron J. Seigo ase...@kde.org wrote:
why do you need to know this? can AppStream not call external tools to do
the installation?
The way AppStream is generated in
On Nov 5, 2013 12:49 PM, Weng Xuetian wen...@gmail.com wrote:
On Monday, November 04, 2013 08:58:22 PM Richard Hughes wrote:
On 4 November 2013 20:56, Weng Xuetian wen...@gmail.com wrote:
Some questions:
1. What about non-application case?
In GNOME we only consider an application to
On 5 November 2013 17:12, Todd toddr...@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.
I think it would be good too
On Nov 5, 2013 5:18 PM, Todd toddr...@gmail.com wrote:
On Nov 5, 2013 12:49 PM, Weng Xuetian wen...@gmail.com wrote:
On Monday, November 04, 2013 08:58:22 PM Richard Hughes wrote:
On 4 November 2013 20:56, Weng Xuetian wen...@gmail.com wrote:
Some questions:
1. What about
On 5 November 2013 17:37, Todd toddr...@gmail.com 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
On 5 November 2013 18:42, Todd toddr...@gmail.com 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
2013/11/5 Todd toddr...@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
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
2013/11/5 Matthias Klumpp matth...@tenstral.net:
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
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 notm...@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
2013/11/4 Rex Dieter rdie...@math.unl.edu:
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
Richard Hughes hughsi...@gmail.com 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
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
написане Sat, 02 Nov 2013 16:38:48 +0200, Richard Hughes
hughsi...@gmail.com:
On 2 November 2013 14:34, Matthias Klumpp matth...@tenstral.net 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
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
On Sunday 03 November 2013 12:49:52 henry miller wrote:
Richard Hughes hughsi...@gmail.com 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
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
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 christ...@maxiom.de 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 christ...@maxiom.de:
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
On 4 November 2013 20:56, Weng Xuetian wen...@gmail.com 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
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 aa...@kde.org 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
On 3 Nov 2013 11:59, Albert Astals Cid aa...@kde.org 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
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 aa...@kde.org 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
On 3 November 2013 12:32, Albert Astals Cid aa...@kde.org 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
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 where
On 3 November 2013 13:30, Sven Brauch svenbra...@googlemail.com 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
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
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
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
On 3 November 2013 14:04, Felix Rohrbach f...@gmx.de 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
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
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 aa...@kde.org 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
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
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 aa...@kde.org wrote:
I am all for listing high quality applications, it's just
that this just
On 3 November 2013 17:15, Thomas Lübking thomas.luebk...@gmail.com 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
2013/11/3 Richard Hughes hughsi...@gmail.com:
On 3 November 2013 17:15, Thomas Lübking thomas.luebk...@gmail.com 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
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 failed me,
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 jl...@kde.org 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
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
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 for
2013/11/2 Aaron J. Seigo ase...@kde.org:
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
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 currently
On 2 November 2013 11:00, Yuri Chornoivan yurc...@ukr.net 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
2013/11/2 Richard Hughes hughsi...@gmail.com:
On 2 November 2013 11:00, Yuri Chornoivan yurc...@ukr.net 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
On 2 November 2013 14:34, Matthias Klumpp matth...@tenstral.net 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
On 2 November 2013 09:50, Richard Hughes hughsi...@gmail.com 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.
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
On 2 November 2013 15:10, Yuri Chornoivan yurc...@ukr.net wrote:
Depends on the format, have you got any examples of what it looks like?
An example attached.
Well, strong isn't a recognised tag (See
http://people.freedesktop.org/~hughsient/appdata/#description) but
using xml:lang=foo is
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 look
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
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
On 2 November 2013 19:33, Albert Astals Cid aa...@kde.org 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?
On Saturday 02 November 2013 19:48:01 Richard Hughes wrote:
On 2 November 2013 19:33, Albert Astals Cid aa...@kde.org 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
On Sat, Nov 2, 2013 at 8:48 PM, Richard Hughes hughsi...@gmail.com wrote:
On 2 November 2013 19:33, Albert Astals Cid aa...@kde.org 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
On 2 November 2013 20:00, Harald Sitter sit...@kde.org 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
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
2013/11/2 Richard Hughes hughsi...@gmail.com:
On 2 November 2013 20:00, Harald Sitter sit...@kde.org 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
2013/11/2 Nicolás Alvarez nicolas.alva...@gmail.com:
2013/11/2 Richard Hughes hughsi...@gmail.com:
On 2 November 2013 20:00, Harald Sitter sit...@kde.org wrote:
We want to showcase high quality applications with active upstream
maintainers.
Who's doing the quality review?
Well, if an
84 matches
Mail list logo
