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
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
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&#x
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 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 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 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
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
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 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
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 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
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.
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
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 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 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 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
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 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 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
w and I’ll set up a meeting and we
can talk and discuss details. Thanks.
Richard Hughes
On 22 February 2012 11:30, Christoph Feck wrote:
> Our "color management KDE dude" is Kai-Uwe Behrmann from Oyranos
> team. See "git/playground/graphics/kolor-manager" for what is already
> available.
I gave up on working with Kai-Uwe a long time ago. Oyranos and colord
are competing frameworks t
On 4 August 2011 07:27, George Spelvin wrote:
> I think what is needed is a series of more specific alternate names in
> a .desktop file, with more levels than the current GenericName and Name.
I think the KDE system settings desktop file just needs an addition of:
OnlyShowIn=KDE;
Richard.
29 matches
Mail list logo
