Re: Adopting AppData in KDE?
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: https://git.gnome.org/browse/gnome-software/tree/data/appdata/org.gnome.Software.appdata.xml.in gets translated by intltool into http://people.freedesktop.org/~hughsient/temp/org.gnome.Software.appdata.xml -- so we have a document structure like: description p Software allows you to find and install new applications and system extensions and remove existing installed applications. /p p xml:lang=cs Aplikace Software umožňuje vyhledávat a instalovat aplikace a systémová rozšíření a odebírat stávající nainstalované aplikace. /p /description 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 because most translators hate translating XML tags. And if one translator does something slightly wrong, the whole document becomes invalid. For instance, asking the translators to translate this source string: pThis is the list of features:/pulliMassive color database/li/ul If they translate this as: pThis is the list of features:/pulliMassive colour database/li/ul This fails hard when the document is installed (as in, fails to parse, and so doesn't get used). Most translators won't validate the resulting XML document before translating. In GNOME we'd ask them to translate This is the list of features: and Massive color database which is much more sane and basically impossible to get wrong. If you have a translation tool that is able to somehow rebuild the tag structure and only ask the translators to actually translate the prose then I suppose supporting something like description xml:lang=cs in AppData makes sense, but only if it takes more than one translator replacing p with «p» to screw things up. Could we just ship the .mo files in /usr/share/app-info/locale or so and just have the extractors copy those files unconditionally (e.g. regardless of the existence of a .desktop file) when trawling through packages? 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. I also don't think the extractor tools (from desktop+appdata-AppStream metadata) are going to be able to switch locale like that, and reading the gmo files manually isn't something I'd look forward to implementing. Richard.
Re: Adopting AppData in KDE?
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 ulliIt's awesome/li/ul And translating that to en_GB, I only need to translate the first paragraph (color - colour). The same thing happens all the time with the other languages based on other languages, e.g. pt_BR and that kind of thing. Richard.
Re: Adopting AppData in KDE?
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, controlled and modified by the maintainers, and translated by the upstream translators. I'm only accepting files into fedora-appstream that have been sent upstream while we're waiting for a new upstream release. For instance: https://github.com/hughsie/fedora-appstream/commit/27d56216e1c3e0f0613734e80735583ccbd2b774 dump it in Fedora's transifex instance, and get them back out and working in GNOME Software and Apper with minimal difficulty. No, this isn't a Fedora problem, this is an upstream feature. If we hide all the translations in Fedora then we're no better than canonical with the Ubuntu Software Center application data. Also, I suspect that you don't want GNOME Software in other languages to be a hairball of that language and English forever, so you're probably going to want to turn off display of apps that aren't translated at some point. That wasn't in my plans, no. Richard.
Re: Adopting AppData in KDE?
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 application. Then I suppose it makes sense to ship an AppData file. How does a plasmoid register itself as available? I'll likely have to create a plasmoid.py helper in the appstream extractor code. Can AppData handle such case? Sure. The only thing not covered in AppData for this case is an icon, but that would be a very easy adjustment to the specification. Is it possible for an application not providing any screenshot? Sure, screenshots are a nice-to-have not mandatory. Richard.
Re: Adopting AppData in KDE?
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.
Re: Adopting AppData in KDE?
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 contents * Write a file of metadata and a tarfile of icons Ricahrd
Re: Adopting AppData in KDE?
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 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? 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. 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. Screenshots are available, but what about videos? Already filed: https://github.com/hughsie/appdata-tools/issues/9 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. 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. Richard.
Re: Adopting AppData in KDE?
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 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. I don't think AppData can help you there. 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. Patches welcome :) The website source is in the appdata-tools repo as well. 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. Can you give an example of how you would squish a 3 paragraph, 100 word description with a few bullet points (translated into 7 languages) into a desktop file? Richard.
Re: Adopting AppData in KDE?
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 it needs discussing. But there is still the question of whether the extension should be hard-coded our based on the type. There's no question. The full ID is the basename of the primary thing used to generate the data. Fonts have full IDs ending in .ttf for instance. How is it any different in principle from putting it in an xml file? You really can. It's very easy to do in GNOME, and we've been doing it for years. it would probably even be simpler since you would only need one additional file rather than one per language. Err, this is the compiled (i.e. what's installed, rather than what's in the repo) file for gnome-software: http://people.freedesktop.org/~hughsient/temp/org.gnome.Software.appdata.xml I think the main issues this would resolve are redundancy, and that this information might be useful outside of app stores. AppData was designed for app stores. Richard.
Re: Adopting AppData in KDE?
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.
Re: Adopting AppData in KDE?
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 have an window, or a big enough window can be put in screenshot? Like a minimal media player stay in tray. I guess do the best you can and use the stock KDE fonts, wallpapers and that kind of thing wherever possible. Richard.
Re: Adopting AppData in KDE?
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 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. KDE is free to ignore AppData if it chooses, although I think a large number of people think the metadata is worthwhile to add. Richard
Re: Adopting AppData in KDE?
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 an application high quality, but we can probably say the opposite is true in about 2-3 years. Richard
Re: Adopting AppData in KDE?
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 true at all. Krita and Inkscape are two of the killer apps I'd love to feature more prominently in GNOME Software. Quality control should happen at the packager level. I don't agree. Packages are just an implementation detail, as gnome-software supports webapps and will soon support other staticly linked packages like listaller and glick2. distributions should make the choice which application is good enough for their users, not a desktop environment. I know for a fact that a lot of the GNOME developers use and love a lot of KDE software, so I don't know why there is any kind of issue here. Of course this is your decision though. Or it does not become mainstream; then you will end up excluding a lot of high-quality applications for no reason (think e.g. Blender). Blender already has an AppData file in fedora-appstream, which has also been submitted upstream for the next release. Richard
Re: Adopting AppData in KDE?
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 file. I've written ~80 AppData files myself and sent nearly all of them upstream already. I've now got a few volunteers doing the same thing to all manner of upstreams. Imho it's a matter of respect to discuss a standard beforehand with a community. And this threat to exclude apps, well... 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) rather than a quick hack that just works with one desktop on one distribution. Richard
Re: Adopting AppData in KDE?
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 to help with. AppData was written to make a kickass application installer, not as any way to validate how awesome an app might or might not be. I think this thread has diverged from that original message, which may be somewhat my fault. some essential CLI tools would have to be considered utter crap, because they work the way they are since a decade - and they do not even provide screenshots!!!) Sure, we're not showing any CLI tools that don't include a desktop file in gnome-software. People wanting to install CLI apps are more than capable of using the CL to find them and install them. Apper still shows packages in KDE. * 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 desktop requires it. If you send me a website patch with an example on how to localize the XML file on KDE, I'd merge it. * what are the benefits of this particular standard over pot. competitors? I think I've covered that in http://people.freedesktop.org/~hughsient/appdata/ * what are the deficits of this particular standard? I'm not sure I'm the ideal person to ask :) * who is in control of the standard? Me I guess. * what are the benefits in controlling the standard? I'm not sure on how to answer that. * What are the goals? Is it actually supposed to become a gatekeeper (high quality applications at best, you use what i tell you/walled garden at worst) tool? No. That's a tiny ancillary featurette that we're using for GNOME. We might decide in the future that an app can't be featured if it has no screenshots. I don't know yet. There is no gatekeeper or walled garden. * in case, by what technique (expert review, voting, etc.), ie. who becomes the gatekeeper? I'm not super interested in doing that at all. It's likely the ratings is controlled by the distro and desktop, but I'm hoping to not get too involved in that as it's so political. Richard
Re: Adopting AppData in KDE?
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 21, and 3.14.x in Fedora 22, so the hard requirement of AppData files isn't going to be for a long while yet (at least a year). useful info, like module, maintainer, reviewboard, bugzilla, last stable release number, frameworks tier, forums, irc channel, userbase, mailing list, etc, that AppData and projects.xml and inqlude and any other required metadata files could all be automatically generated from? I'm actually interested in including these extra fields in the AppData spec; the original specification is deliberately small in scope to avoid overwhelming people interested in adding an AppData file. Future versions of the spec will add more information such as a donate URL, an IRC channel link, mailing list etc. For instance, there is an open bug for donations here: https://github.com/hughsie/appdata-tools/issues/7 and I'd be very open to spec improvement ideas. Richard
Re: Adopting AppData in KDE?
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 en_GB or en_US, but that's only a tiny proportion of the desktop Linux users these days. It's certainly better than nothing, but if you don't speak English it's not helpful at all. 2. AppData in GNOME packages is filled with translations while compiling/packaging the application. Can it be somehow aligned with KDE idea of storing translations in separate repo? I'm not sure how KDE does this on a technical level, but I'm sure you could merge the XML file together somehow if you didn't want the xml.in intltool method. 3. Is it technically possible to have appdata.xml in repo translated by scripty based on KDE desktop- POs (just like KDE .desktop files)? No clue on this, sorry. 4. What is planned to do with Debian/Ubuntu DDTP translations [2, 3]? Is there any plans to adopt it for Canonical Software Centre/Muon with some kind of backend? No, packages are a different problem to applications. In the case you have multiple applications shipped in one package you want separate descriptions, not one description that's a mix of the two. Plus, if we want non-packaged applications (for instance listaller, glick2 or click bundles) then the concept of a package description looses all meaning. Is it yet another almost-standard for RPM/GNOME distributions? There's nothing inherently GNOME or RPM specific about this at all in my opinion. Richard.
Re: Adopting AppData in KDE?
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 Richard doesn't have objections ;-) Depends on the format, have you got any examples of what it looks like? Richard.
Re: Adopting AppData in KDE?
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. It's packaged in Fedora in the appdata-tools package. You can use appdata-validate to check the format and style of the XML files to make sure they get used by the software centers and the metadata extractors. Richard [1] https://github.com/hughsie/appdata-tools
Re: Adopting AppData in KDE?
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 exactly what intltool produces as an output format. Richard.
Re: Adopting AppData in KDE?
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? We want to showcase high quality applications with active upstream maintainers. There's no point us showing 5000 application where half don't work or are abandonware. Also, I'm hoping AppData does become a standard. It's already used by over 200 projects. Richard
Re: Adopting AppData in KDE?
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 alive. For the featured and picks we have in gnome-software this is chosen by the design team, and is of course desktop (and possibly distro) specific. Richard.
Re: Color Managing KDE
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 frameworks that have *very* different design ideologies. I've written a lot in the past on why I think Oyranos is the wrong approach, which I'll not write again here. From my biased point of view, in just over one year, colord has gone from concept to being included on nearly all distros by default. It's pulled in as multiple things like GTK and CUPS as a dependency. It's my firm belief that color management should be usable by real people without having to install or configure anything. I'm offering to help hackers in the KDE community build simple GUI code on top of colord. You guys get a color management system that works, and I get more users using my stuff. It's a win-win situation. Richard.
Re: Formal complaint concerning the use of the name System Settings by GNOME
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: OnlyShowIn=KDE; Richard.
