On 4 August 2011 07:27, George Spelvin li...@horizon.com 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:
On 22 February 2012 11:30, Christoph Feck christ...@maxiom.de 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
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
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
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 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 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 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 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
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 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
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 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
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.
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
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
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 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 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 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
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 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 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,
25 matches
Mail list logo