Re: Adopting AppData in KDE?
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 desktops specified in the menu-spec makes sense. It already has non-desktop projects than that (such as mozilla). And the description (specific upstream umbrella project) doesn't imply that the umbrella project is necessarily tied to a particular desktop environment. 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? Yes, as well as the version number and date, probably. 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. Yes, if you know beforehand what mimetypes your application will support. But this isn't always the case. 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. Good to hear. That should probably be added here: http://www.freedesktop.org/software/appstream/docs/chap-AppStream-Metadata.html#sect-AppStream-Metadata-ASXML Screenshots are available, but what about videos? Already filed: https://github.com/hughsie/appdata-tools/issues/9 Okay, good. 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. 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. 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. 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.
Re: Adopting AppData in KDE?
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 and we can talk about possible ideas there. 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. 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. I know, but this may be a good opportunity to see if there are any improvements that can be made to the existing desktop file spec as well. 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. But there is still the question of whether the extension should be hard-coded our based on the type. 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? How is it any different in principle from putting it in an xml file? Besides the fact that you can't put translations in the xml file. And there is no reason there couldn't be a second, supplemental file for things like a description that might be too long to fit comfortably in the main file or might not be safely parsed by software expecting an old version of the spec. There wouldn't be any disadvantage here compared to the xml file since you would still need an additional file, it would probably even be simpler since you would only need one additional file rather than one per language. I think the main issues this would resolve are redundancy, and that this information might be useful outside of app stores.
Re: Adopting AppData in KDE?
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 limiting it to only a few recognized groups. This is another gatekeeper issue: no project our group would have the authority to say which group is and is not acceptable. project_group allows arbitrary values already, the specs just say known values include... which is in no way a recommendation. And I am not planning to change that ;-) That isn't clear from the description. I also think sleeping multiple groups and/or sub-groups. KDE at least had sub-groups like KDE edu, KDE multimedia, and calligra. I think it would be good for apps to be able to identify themselves as belonging to one of these groups. I could also see an application providing, say, gnome/KDE integration that could benefit from belonging to both groups. I think this would be overly confusing for users. Just say KDE-Edu or KDE-Multimedia would make some sense... But in all cases, the applications are part of the KDE umbrella project. Mozilla also has a Mozilla Messaging department, but it is still listed as Mozilla. I am not sure of what value adding subgroups would bring to the users... Amarok is a multimedia program under the KDE umbrella, but it is not a KDE-multimedia app. People who want to install the full Calligra suite would probably want to get a list of all Calligra applications, not a list of all KDE applications. I am not sure how it would be confusing, the app store could list all applications under a particular umbrella, as well as groups under that umbrella. 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 (that is something that bothers me about YaST, you can only view a change log after the app is installed). It needs to be in a reasonably consistent format so the app store can extract the changes for the most recent version, the date of the last release, and the most recent version number. The Android app store provides this information, for example. This is already done via PackageKit for the connected package. Including upstream information would require extra logic for parsing version numbers of every distribution, and it would require additional caches for chagelogs. I like the idea, but having distributor's changelogs is nicer at time. That would still require standardizing distributor's changelogs. It also will be insanely difficult to get all app authors to write a machine-readable changelog and change the changelogs they are writing already. Any more difficult than getting them to write appdata files? 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? As with the add-ons I mentioned previously, the app-store can either atomically download these plugins or allow the user to download them. The details would be left up to the implementation I assume. This is slready done, some implementations exist :-) Okay, it doesn't seem to be widely used though. For a more extreme question, is there a reason all this information cannot just be put into the .desktop file, or an additional .desktop file? Why does this have to be an xml file? It seems like a lot of the information is either parsed from the .desktop file or identical to the .desktop file. Why can't we just extend the .desktop file spec, or include a modified special-purpose .desktop file, to handle the missing bits? This will also solve issues like translation. The nested screenshots are not possible with desktop-file-layout, as well as the long-description co. Not in the current standard, the question is what is the advantage is of creating an entirely new standard with a lot of redundant information over just extending the existing standard?.
Re: Adopting AppData in KDE?
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: http://lists.kde.org/?l=kde-i18n-docm=138353976230003w=2 There's a bit of a problem though, that Yuri pointed on on kde-i18n-doc: On Mon, Nov 4, 2013 at 11:34 PM, Yuri Chornoivan yurc...@ukr.net wrote: Using appdata.its from Richard's page [1] leads to translation by paragraph for multi paragraph descriptions, like this (I run it as itstool -i appdata.its -j inkscape.appdata.xml -o translated.xml uk.mo) description pSomething/p p xml:lang=ukBlah-blah/p /description intltool translates this as description pSomething/p /description description xml:lang=uk pBlah-blah/p /description Unfortunately, the schema says the latter is invalid. Is the schema wrong or intltool wrong? If we have to do it by paragraph, having scripty merge the translations back into the original XML is going to be ugly... 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 generator to do the translation, the gettext files would have to be shipped with the same package, which might not always be the case, if you have language-packages. So I don't think this would work. Definitely not for KDE, we ship all our translations separately from the main package for stuff in the SC. 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? Are there other suggestions on how to make trabslating AppData files easier for KDE? -T.C.
Re: Adopting AppData in KDE?
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 extractor tools to read in the translations into the big giant AppStream XML; no magic needed in the software centers, nor would there be any need for users to have to have the package that has these .mo files installed, which kind of defeats the purpose. 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. The gettext module built in to Python can read in translations from arbitrary domains in arbitrary languages sourcing locale files from arbitrary directories no sweat, so this would be a fairly simple patch to fedora-appstream. (I'm happy to resubmit this suggestion in patch form too, BTW; just wanted to make sure it was something you were interested in implementing, first. ;-) I was originally going to suggest we do something like this but with seperate application xml:lang=foo XML fragments instead of po files, just to make things simpler in the appstream extractor, but after looking at what it took to get such XML output from KDE po files I discovered that the gettext goop to implement this in fedora-appstream itself isn't really any more complicated than the etree goop to suck it out of those XML fragments instead. Doing it this way also has the side effect of ensuring that translators never need to deal with XML, ever. In general I think being able to ship translations separately would be a big improvement to the i18n story for all the software centers that implement this spec. It has more benefits than just aiding KDE in implementing it. For instance, in Fedora we're probably going to be stuck with having AppData included as SourceN files in SRPMs for quite some time. At the moment, translation of those is pretty much impossible. Hooking a bunch of random SRPMs up to Transifex would suck, as would trying to merge back translations into the XML files in Fedora dist-git in some automated fashion. But with something like this it would be fairly easy to extract all the appdata.xml files shipped as additional sources in SRPMs, dump it in Fedora's transifex instance, and get them back out and working in GNOME Software and Apper with minimal difficulty. 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. You could say that hey, obviously upstream doesn't support that language very well, so including it in the app center in that locale is pretty useless, which would be true to some extent, but that ignores multilingual users who prefer to use their computer in their native language but are happy to use an app in English if it's awesome enough. (There are a lot of English-only dev tools, for instance. I'd hate to lose would-be free software contributors just because they prefer their desktop to be in their native tongue.) Adding a show me a mishmash of Esperanto and English plz checkbox is really a terrible option, so if we want to have complete coverage of translated application data in the future—and I think we really do—we're going to have to have infrastructure for distro translators to pick up the slack, and this would be a big head start. -T.C.
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 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 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. This sounds more like a problem in translator tooling, commit hooks and CI integration. Anyway, couldn't you still generate the XML with language selectors on the main elements themselves? Since you already put markup-less strings into the file, why not just add the language attribute to, e.g. desscription, and then fill the tags with content? Do you expect to support partial translations? I.e. one paragraph translated, followed by an untranslated one? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Adopting AppData in KDE?
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 could add a type=plasmoid / gnome-shell-extension to the AppStream spec (we'd still have to solve the icon-source case, but that's rather trivial). Bodega can have different stores that can be 99% the same except some little detail, like a category only present in a store and not the others, this was done to give each device its own store. So stores are done in a way that the definition of a store takes very little space in the database and is very fast to clone (and if the same category is in multiple stores items in it stay in sync between stores) cheers, Marco Martin
Re: Adopting AppData in KDE?
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 the package manager and giving some way to allow desktops to provide a desktop-specific UI, I think AppStream makes loads of sense. For everything else, it’s going to be “round pegs, square holes”. The filtering of items is done in the wrong place, the ability to handle things that aren’t applications is limited, etc. To me, AppStream is something to extend apper and such tools with. If we want a way to distribute general content in a context relevant manner, Bodega is actually designed for this. I understand the AppStream devels are probably quite excited about what they’ve got going on (I would be, too, if I were them), but KDE needs to make intelligent choices as to what makes sense for our use cases, and AppStream is not that thing. -- Aaron J. Seigo
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 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 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. Hmm, well the GB tranlator could just copy the string. It just looked a lot like HTML and certain things don't make the same sense in all languages, e.g. b does not necessarily apply to east asian glyphs and translators would need to be able to change that to something else. But I guess you don't have any actual markup in there, so no need to allow translators to change it. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
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?
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 to formally state that I agree with this.
Re: Adopting AppData in KDE?
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 desktop-level choice tho. 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. What I care is a app center doesn't only have application, it somehow should contains plugin to other application, for example, a browser plugin, a widget on desktop. And it makes sense if they don't have desktop file. Can AppData handle such case? 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. appdata-validate is preferable minimum size is about 600px, I guess an 22px tray icon isn't visible enough on that. Is it possible for an application not providing any screenshot? Regards, Xuetian
Re: Adopting AppData in KDE?
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 actually have an window, or a big enough window can be put in screenshot? Like a minimal media player stay in tray. On Saturday, November 02, 2013 09:27:18 AM John Layt wrote: 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 to answer them, so please cc him on replies. The AppData justification, file format and tools are documented at [1]. AppData and AppStream are slowly being adopted by various distros for use in their software installers and app stores. The AppData metadata file supplements the .desktop file by having a long description of an app, links to some screenshots, and the app home page, which get dispalyed in the app installer. The description can also be localized. While distro's could generate and maintain this data for themselves, to do so would be very time consuming for them, may not present the app in the best way possible, and would quickly get outdated. It makes a lot of sense for apps to create and maintain this metadata for themselves, presenting themselves in the best way possible, which all the distros can then reuse in their installer applications. As far as I'm aware, AppData and/or AppStream is either used or scheduled to be used by default in Gnome Software Centre, Apper, Fedora, and OpenSuse, and optionally in several other distros, so is not a distro specific intiative. I think there's even OBS integration happening. If anyone knows more or thinks differently please let us know. 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 Fedora 20 for Gnome (Fedora KDE will use Apper). Currently apps that don't provide AppData are ranked lower in search results in Gnome Software, but from Gnome 3.14 such apps will not be listed at all [2]. This means that without an AppData file KDE apps will eventually not be visible to Gnome users in their default app installer. Currently Gnome has 50% of apps covered and is coordinating an effort for full coverage [3], but KDE has only 1%. Obviously individual apps are free to add these files [4], but from a KDE-wide perspective we need to discuss if we want to officially adopt this as a requirement, and if we want to provide a more coordinated and standardized solution. What do people think? If we do adopt it, the two obvious issues to me are localization and screenshots. Ideally scripty would be hooked up to generate the translation files, but as they are an XML format it may need a bit of work. Scripty would also need the AppData file to be in a standard location in each repo. The screenshots need to be hosted by the app (at least initially, Fedora copy the screenshots to their own server later to save load), so we may want to have somewhere common on the KDE infrastructure for that. I'd also suggest defining a file naming standard including the app name and version number in the screenshot name. Taking a slight step-back, I wonder if there is a need for a more generic KDE metadata file in each KDE repo that describes even more 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? One obvious question is how this might relate to Bodega if KDE chooses to switch to that? What does Gnome shipping their own official App Store mean for cross-distro/cross-desktop app store efforts and do we need to start working on our own now, or will Bodega fill that need for us? Cheers! John. [1] http://people.freedesktop.org/~hughsient/appdata/ [2] http://blogs.gnome.org/hughsie/ [3] https://wiki.gnome.org/GnomeGoals/AppDataGnomeSoftware [4] https://git.reviewboard.kde.org/r/113531/
Re: Adopting AppData in KDE?
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 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 plasmapkg -i pathtopackage -- Aaron J. Seigo
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 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 between major versions, as it already has (admittedly in a backwards-compatible manner) between 4.x and 5.x due to the deprecation of ksycoca4. that is why plasmapkg is provided in the first place. why do you need to know this? can AppStream not call external tools to do the installation? -- Aaron J. Seigo
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 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 from App Data, then? * Take the binary rpm file * Explode it somewhere (without installing it) * Parse the contents * Write a file of metadata and a tarfile of icons the corresponding steps for a plasma package would be: * take the compressed package file * unzip it somewhere (without installing it) * parse the metadata.desktop file in the root * optionally look for icons in the root * write a file of metadata and a tarfile of icons it’s just a zip file. :) http://techbase.kde.org/Development/Tutorials/Plasma/PackageOverview -- Aaron J. Seigo
Re: Adopting AppData in KDE?
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 Fedora is we: ok ... this is separate from App Data, then? Yes. I wrote about that: http://blog.tenstral.net/2013/11/appstream-clarifications.html AppData is just a new (but very good) source to provide data for the AppStream generator. The case of installing Plasmoids would actually be handled by something like Listaller (but I think even for that it would be out of scope, since plasmapkg already exists - this might make some sense to implement it in KDE software-centers only and enhance the AppStream data with an application type (like type=plasmoid)) Cheers, Matthias
Re: Adopting AppData in KDE?
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 have a desktop file without NoDisplay=true. That's probably a desktop-level choice tho. 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. What I care is a app center doesn't only have application, it somehow should contains plugin to other application, for example, a browser plugin, a widget on desktop. And it makes sense if they don't have desktop file. Can AppData handle such case? Would it make sense to have this explicitly defined in the spec? An application can list itself as supporting certain add-on categories, and an add-on can identify itself as belonging to one or more such categories. So, for example plasma workspaces could accept widgets, wallpapers, runners, desktop effects, kwin scripts, shells, etc. Then the app center could provide a way to list all add-ons of a particular type for a particular app. How this would be represented would depend on the app center implementation. It wouldn't strictly be necessary for the application to explicitly define its add-on categories, but doing so guarantees naming is consistent. For example it avoids some apps using widget, some using applet, and some using plasmoid. I know the android play store has something like this as well, where an application can open a special limited play store that only lists add-ons for itself, add-ons that may or may not be listed separately in the play store as well. I don't know the details of how this is decided by the app, though.
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 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 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. 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. What I care is a app center doesn't only have application, it somehow should contains plugin to other application, for example, a browser plugin, a widget on desktop. And it makes sense if they don't have desktop file. Can AppData handle such case? Would it make sense to have this explicitly defined in the spec? An application can list itself as supporting certain add-on categories, and an add-on can identify itself as belonging to one or more such categories. So, for example plasma workspaces could accept widgets, wallpapers, runners, desktop effects, kwin scripts, shells, etc. Then the app center could provide a way to list all add-ons of a particular type for a particular app. How this would be represented would depend on the app center implementation. It wouldn't strictly be necessary for the application to explicitly define its add-on categories, but doing so guarantees naming is consistent. For example it avoids some apps using widget, some using applet, and some using plasmoid. I know the android play store has something like this as well, where an application can open a special limited play store that only lists add-ons for itself, add-ons that may or may not be listed separately in the play store as well. I don't know the details of how this is decided by the app, though. Looking at the spec, I have a few suggestions: 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 project our group would have the authority to say which group is and is not acceptable. I also think sleeping multiple groups and/or sub-groups. KDE at least had sub-groups like KDE edu, KDE multimedia, and calligra. I think it would be good for apps to be able to identify themselves as belonging to one of these groups. I could also see an application providing, say, gnome/KDE integration that could benefit from belonging to both groups. 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 (that is something that bothers me about YaST, you can only view a change log after the app is installed). It needs to be in a reasonably consistent format so the app store can extract the changes for the most recent version, the date of the last release, and the most recent version number. The Android app store provides this information, for example. 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? As with the add-ons I mentioned previously, the app-store can either atomically download these plugins or allow the user to download them. The details would be left up to the implementation I assume. It might be good to have an email address for the person or mailing list responsible for the file. That way people know who to go to regarding issues with it. This would be particularly important if downstreams will be providing their own files when upstream doesn't do so. Screenshots are available, but what about videos? 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. For a more extreme question, is there a reason all this information cannot just be put into the .desktop file, or an additional .desktop file? Why does this have to be an xml file? It seems like a lot of the information is either parsed from the .desktop file or identical to the .desktop file. Why can't we just extend the .desktop file spec, or include a modified special-purpose .desktop file, to handle the missing bits? This will also solve issues like translation.
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?
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 project our group would have the authority to say which group is and is not acceptable. project_group allows arbitrary values already, the specs just say known values include... which is in no way a recommendation. And I am not planning to change that ;-) I also think sleeping multiple groups and/or sub-groups. KDE at least had sub-groups like KDE edu, KDE multimedia, and calligra. I think it would be good for apps to be able to identify themselves as belonging to one of these groups. I could also see an application providing, say, gnome/KDE integration that could benefit from belonging to both groups. I think this would be overly confusing for users. Just say KDE-Edu or KDE-Multimedia would make some sense... But in all cases, the applications are part of the KDE umbrella project. Mozilla also has a Mozilla Messaging department, but it is still listed as Mozilla. I am not sure of what value adding subgroups would bring to the users... 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 (that is something that bothers me about YaST, you can only view a change log after the app is installed). It needs to be in a reasonably consistent format so the app store can extract the changes for the most recent version, the date of the last release, and the most recent version number. The Android app store provides this information, for example. This is already done via PackageKit for the connected package. Including upstream information would require extra logic for parsing version numbers of every distribution, and it would require additional caches for chagelogs. I like the idea, but having distributor's changelogs is nicer at time. It also will be insanely difficult to get all app authors to write a machine-readable changelog and change the changelogs they are writing already. 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? As with the add-ons I mentioned previously, the app-store can either atomically download these plugins or allow the user to download them. The details would be left up to the implementation I assume. This is slready done, some implementations exist :-) It might be good to have an email address for the person or mailing list responsible for the file. That way people know who to go to regarding issues with it. This would be particularly important if downstreams will be providing their own files when upstream doesn't do so. Screenshots are available, but what about videos? Richard wants to target that in a later revision of AppData 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. In theory, yes - but I am not sure if it makes sense to change the spec for this detail - maybe we can do that in a later revision. :-) For a more extreme question, is there a reason all this information cannot just be put into the .desktop file, or an additional .desktop file? Why does this have to be an xml file? It seems like a lot of the information is either parsed from the .desktop file or identical to the .desktop file. Why can't we just extend the .desktop file spec, or include a modified special-purpose .desktop file, to handle the missing bits? This will also solve issues like translation. The nested screenshots are not possible with desktop-file-layout, as well as the long-description co. Cheers, Matthias -- Debian Developer | Freedesktop-Developer KDE-Developer| GNOME-Contributor I welcome VSRE emails. See http://vsre.info/
Re: Adopting AppData in KDE?
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 generator to do the translation, the gettext files would have to be shipped with the same package, which might not always be the case, if you have language-packages. So I don't think this would work. Are there other suggestions on how to make trabslating AppData files easier for KDE? Cheers, Matthias
Re: Adopting AppData in KDE?
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 from. The problem is that, in order for the AppStream generator to do the translation, the gettext files would have to be shipped with the same package, which might not always be the case, if you have language-packages. So I don't think this would work. Are there other suggestions on how to make trabslating AppData files easier for KDE? Well the .desktop files have the translations inside it, I think the same could be applied to AppData. Best, -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com
Re: Adopting AppData in KDE?
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. just to throw in another idea, since assets have pretty much all that data, those metatada files could be generated from existing asset data as well, even tough for all assets that aren't a package in a repository becomes kinda a pointless exercise at this stage... 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 application. on the other hand a bit that may be useful for us is the part of installing from repositories and a semi-automated import of assets based on the metadata of existing applications Cheers, Marco Martin
Re: Adopting AppData in KDE?
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 application. on the other hand a bit that may be useful for us is the part of installing from repositories and a semi-automated import of assets based on the metadata of existing applications The installation bit is handled by Listaller, another project making use of some AppStream facilities and providing cross-distro app packages. However, this does not solve the non-application cases. Some time ago, I was asked to include that in Listaller's scope, but I decided against it at that time, because it looked like something which should better be handled per-desktop. Ideally, Bodega would combine data from lots of different sources and display them in an user-friendly way. Thanks to PackageKit, nobody has to care about the details of PM anymore when writing apps like this, thanks to AppStream, metadata about applications is available to display them nicely, and Listaller might add cross-distro software sources to the list (for that case, GNOME is cooking up Glick2, which is technically different). 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 could add a type=plasmoid / gnome-shell-extension to the AppStream spec (we'd still have to solve the icon-source case, but that's rather trivial). Cheers, Matthias -- Debian Developer | Freedesktop-Developer KDE-Developer| GNOME-Contributor I welcome VSRE emails. See http://vsre.info/
Re: Adopting AppData in KDE?
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 trouble finding any) My googling failed me, but a colleague pointed out: http://www.freedesktop.org/wiki/Distributions/Distributions/AppStream/Software/ http://www.freedesktop.org/software/appstream/releases/ Jup, due to spam on the XDG wikis, distributions.fd.o was moved to a new location, which might still confuse Google. I created a small FAQ about AppStream last night, which might be helpful to clarify a few things regarding AppData/AppStream: http://blog.tenstral.net/2013/11/appstream-clarifications.html Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Adopting AppData in KDE?
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 as required) rather than a quick hack that just works with one desktop on one distribution. 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 addition while appdata claims to be distribution/gnome, it really is a Fedora thing and few other distribution packages use it, thus violating KDEs no patches for on distribution only. Is appdata good or bad? I say bad, not on technial grounds, but social: the effort to standardise something that should be standardised was not done. It meets Fedoras needs, but what about debian? What about netbed. What about... Yes standardization is a lot of effort, that is because getting a good compromise for everyone is hard. KDE should in my opinion refuse appdata in hopes that the next time someone has a great idea they remember appdata failed (or took too long to catch on) because it failed presue standardization early. If someone has a better idea how to stop developers from this anti-social behavor I'm open to it so I can consider appdata on technial merits like it should be. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: Adopting AppData in KDE?
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 to answer them, so please cc him on replies. Hi, 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]? 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? 3. Is it technically possible to have appdata.xml in repo translated by scripty based on KDE desktop- POs (just like KDE .desktop files)? 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? Is it yet another almost-standard for RPM/GNOME distributions? Thanks in advance for your answers. Best regards, Yuri [1] https://code.google.com/p/audacity/source/browse/audacity-src/trunk#trunk%2Fhelp [2] https://translations.launchpad.net/ddtp-ubuntu/+translations [3] http://www.debian.org/international/l10n/ddtp The AppData justification, file format and tools are documented at [1]. AppData and AppStream are slowly being adopted by various distros for use in their software installers and app stores. The AppData metadata file supplements the .desktop file by having a long description of an app, links to some screenshots, and the app home page, which get dispalyed in the app installer. The description can also be localized. While distro's could generate and maintain this data for themselves, to do so would be very time consuming for them, may not present the app in the best way possible, and would quickly get outdated. It makes a lot of sense for apps to create and maintain this metadata for themselves, presenting themselves in the best way possible, which all the distros can then reuse in their installer applications. As far as I'm aware, AppData and/or AppStream is either used or scheduled to be used by default in Gnome Software Centre, Apper, Fedora, and OpenSuse, and optionally in several other distros, so is not a distro specific intiative. I think there's even OBS integration happening. If anyone knows more or thinks differently please let us know. 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 Fedora 20 for Gnome (Fedora KDE will use Apper). Currently apps that don't provide AppData are ranked lower in search results in Gnome Software, but from Gnome 3.14 such apps will not be listed at all [2]. This means that without an AppData file KDE apps will eventually not be visible to Gnome users in their default app installer. Currently Gnome has 50% of apps covered and is coordinating an effort for full coverage [3], but KDE has only 1%. Obviously individual apps are free to add these files [4], but from a KDE-wide perspective we need to discuss if we want to officially adopt this as a requirement, and if we want to provide a more coordinated and standardized solution. What do people think? If we do adopt it, the two obvious issues to me are localization and screenshots. Ideally scripty would be hooked up to generate the translation files, but as they are an XML format it may need a bit of work. Scripty would also need the AppData file to be in a standard location in each repo. The screenshots need to be hosted by the app (at least initially, Fedora copy the screenshots to their own server later to save load), so we may want to have somewhere common on the KDE infrastructure for that. I'd also suggest defining a file naming standard including the app name and version number in the screenshot name. Taking a slight step-back, I wonder if there is a need for a more generic KDE metadata file in each KDE repo that describes even more 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? One obvious question is how this might relate to Bodega if KDE chooses to switch to that? What does Gnome shipping their own official App Store mean for cross-distro/cross-desktop app store efforts and do we need to start working on our own now, or will Bodega fill that need for us? Cheers! John. [1] http://people.freedesktop.org/~hughsient/appdata/ [2] http://blogs.gnome.org/hughsie/ [3]
Re: Adopting AppData in KDE?
написане 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 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. An example attached. Yuri?xml version=1.0 encoding=UTF-8? application id type=desktopmarble.desktop/id licenceCC0/licence description pstrongMarble/strong is a Virtual Globe and World Atlas that you can use to learn more about the Earth./p p xml:lang=ukstrongMarble/strong â вÑÑÑÑалÑний глобÑÑ Ñа аÑÐ»Ð°Ñ ÑвÑÑÑ, за Ð´Ð¾Ð¿Ð¾Ð¼Ð¾Ð³Ð¾Ñ Ñкого ви можеÑе вивÑаÑи ÐемлÑ./p /description screenshots screenshot type=defaulthttp://docs.kde.org/stable/en/kdeedu/marble/quick-1.png/screenshot screenshothttp://docs.kde.org/stable/en/kdeedu/marble/routing-1.png/screenshot /screenshots url type=homepagehttp://edu.kde.org/applications/all/marble/url updatecontactmarble-de...@kde.org/updatecontact /application
Re: Adopting AppData in KDE?
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 details, but as long as it is used by AppStream as well, it is cool for me! :) Lukas El Domingo 03 noviembre 2013 06:44:56 Àlex Fiestas escribió: 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). signature.asc Description: This is a digitally signed message part.
Re: Adopting AppData in KDE?
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 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. 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 addition while appdata claims to be distribution/gnome, it really is a Fedora thing and few other distribution packages use it, thus violating KDEs no patches for on distribution only. 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. Sven
Re: Adopting AppData in KDE?
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 users won't be using it to install stuff, so what we can try to control is Apper and Muon. For the record Apper will be supporting AppData and AppStream, but by default I'll choose to do what Ubuntu Software Center does which is hide packages that aren't listed as applications, with a tip that the search matched packages too. This is what I believe to be the best option since I don't like the idea of opening a terminal to install devel libs even if the developer is supposed to be a bit smarter... Apper already supports AppStream but it's clearly not in a nice fashion, as soon as I port it to Qt5/QML it will be comparable to a real Software Center. That being said I think something to worry is that we need to change something or not, the sooner we spot a weak point the better since changin specs we all know it's a mess! Also if KDE people decide not to support AppData and AppStream it is just sad as Apper will end up listing only GNOME apps as applications... Best, -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com
Re: Adopting AppData in 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
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?
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 ;-) Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
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?
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 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. 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. Cheers, Albert 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?
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 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. As already other people proved in this thread, having appdata means nothing about quality, it just means whoever released the app caved to your threat of removing the app from the package manager if it does not have that magic file. The fact that you keep repeating it, does makes not it true. I am all for listing high quality applications, it's just that this just doesn't help. Cheers, Albert 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 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 you can't easily install Krita in distributions that ship GNOME, and you can't easily install Inkscape in distributions that ship KDE. That's a horrible situation, because a lot of people do that as of today. It would further widen the (technical) gap between the desktop environments, instead of encouraging people to select the best application for what they want to do regardless of what toolkit it uses (which I consider a somewhat idiotic criterion). There would be lots of confused users in internet forums asking for why $application is not available any more, and we'd be sitting there explaining how to jump through hoops to still install it. Thus I would claim that this is not an acceptable option. Quality control should happen at the packager level. Broken applications should not be available in the distribution's main repository. And distributions should make the choice which application is good enough for their users, not a desktop environment. Besides, as said multiple times, this spec does not provide any kind of quality control worth mentioning anyways. The level of quality control it achieves is on par with looking at the date of the last commit in the repository. For the same reasons, in my opinion, not showing packages in a package manager which don't provide screenshots because they don't look pretty is a bad choice. Of course this is your decision though. In any case, it's a very bad precondition for discussing the new specification for the reasons Albert mentioned. 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. I don't see the point. Either it becomes so mainstream that you effectively need to have it; then every maintainer of a crappy application will just add it (to put it bluntly). Just imagine it would be part of an IDEs template for a new application -- nobody would not have it. 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). Greetings, Sven
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?
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 not really helpful. Something like counting the commits in the last x months would be much more significant. Personally, I think it's a good idea to have something like AppData, but as a way to let an application present itself, not as something applications are forced to use. Felix Am 03.11.2013 14:24, schrieb Richard Hughes: 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?
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.org/applications/ i.e http://websvn.kde.org/trunk/www/sites/www/applications/apps/bomber.json?view=markup - http://kde.org/applications/games/bomber/ images are all at http://kde.org/images/screenshots/APPNAME.png I fully support app developers helping keep this up to date and given we already have this information, the idea of writing a small script to convert this to the relevant XML (which to me seems a sensible spec) should be simple enough. That means we get Gnome app centre support, and if Muon want to use that spec - that'd be great too. David
Re: Adopting AppData in 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 manager. Still, if KDE would go with its own thing it would be unnecessarily painful. I just wanted to say that KDE doing its own thing is a kind of virtual option since nobody would profit from it. We're probably getting into a fight over uninteresting details here, sorry for bringing them up. I just wanted to make two points, which are - looking for this metadata file is not a good way to ensure quality - I like the spec but I do not like the way it is presented to KDE. On Sunday 03 November 2013 15:04:16 Felix Rohrbach wrote: Personally, I think it's a good idea to have something like AppData, but as a way to let an application present itself, not as something applications are forced to use. Exactly. Greetings, Sven
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 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).
Re: Adopting AppData in KDE?
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 linked to the above comment? - I would allow for icon to be a remote path. An icon set like Oxygen won't have icons for every single app that we'd want to show in a store and I think it would be wrong to do so. - There's some attributes used in the example are not documented. ie. width + height on the screenshot (which seems pointless anyway when you're explicitly setting an aspect ratio in the spec) the url element in the example has type=homepage which is not documented. - You've documented how the XML fits in with Gnome's i18n tools, which I don't think is the right approach in a freedesktop.org page. That should list the final intended output (file names/format), the gnome page should list how to use the gnome i18n. Regards David
Re: Adopting AppData in KDE?
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 sodipodi, cinepaint or arora any time soon. But you said anyone can write one and submit it to Fedora for submission, you also said they're pretty trivial to write, so why do you think I (or someone else) can not write one for sodipodi and submit it? Cheers, Albert 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?
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/trunk/www/sites/www/applications) Generated from the existing KDE metadata that makes our websites. Tasks not solved: - The current KDE system only has one screenshot per app, we should expand that (which we'll benefit from too \o/) - We don't have a summary field - Some apps are missing there - The questions in my last email - Our screenshots are not the correct aspect ratio, and some are quite out of date - Google Code In is a good way to fix this. If you want to mentor a task on fixing this please ping me on the SOK mentor list.
Re: Adopting AppData in 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 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. But you said anyone can write one and submit it to Fedora for submission, you also said they're pretty trivial to write, so why do you think I (or someone else) can not write one for sodipodi and submit it? 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) Qualification/certification requires a trustworthy instance, not some formalized README. And the presence of an AppData description does neither indicate that the app is actually maintained (not now and certainly not in the long run, not even if you'd pervert the idea of a standard and alter it once a month), nor does the absence indicate that the app is of low quality (by measure of update frequency, 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!!!) The one and only point of forcing the apps to support AppData in order to be available is to enforce the AppData standard. If google videosearch would only find youtube videos, there'd be not the slightest doubt about that being a move in order to enforce (or at least encourage) distribution via youtube and certainly not to assure high quality videos - of cats... The important questions to ask and answer (well, is it usable) * does it presently qualify as standard at all? (not as long as it states particular tools - like gnome i18n, as claimed by David) * what are the benefits of this particular standard over pot. competitors? * what are the deficits of this particular standard? * who is in control of the standard? * what are the benefits in controlling the standard? * 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? * in case, by what technique (expert review, voting, etc.), ie. who becomes the gatekeeper? No serious answer to the above could include buzz like high quality or awesome. Cheers, Thomas
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?
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 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. The point isn't that it explains gnome only and it should also explain KDE i18n. The point is that such information doesn't belong to the standard. The standard shouldn't tell you how to use the tools to generate the file. David Edmundson explained this issue better than me already. -- Nicolás
Re: Adopting AppData in KDE?
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 support... -- Rex
Re: Adopting AppData in KDE?
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, but a colleague pointed out: http://www.freedesktop.org/wiki/Distributions/Distributions/AppStream/Software/ http://www.freedesktop.org/software/appstream/releases/ -- rex
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?
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 description in the description field? -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: Adopting AppData in KDE?
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 cross-distro/cross-desktop app store efforts and do we need to start working on our own now, or will Bodega fill that need for us? This is an area of understandable confusion, but Bodega and AppStream do rather very different things. AppStream is a way to present a more modern interface to packages in the OS vendor’s repositories. (Theoretically, 3rd party repos too.) It is rather unhelpful for non-package-manager-packages, for non-application content types or for use as an in-app system. Last I looked, AppStream has as a goal utilizing OCS for user interface. OCS theoretically supports payment for items, but this process is not only woefully underspecificed in OCS (as in: not documented at all) it does not provide for an open market but a centralized warehouse+storefront conglomeration just like all the proprietary app stores out there. Given that the only complete implementation of OCS available is proprietary, I don’t think this is a surprise. 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. AppStream is very focused on the needs of desktop Linux. There is *nothing* wrong about that in the least, but it leaves mobile, embedded and server use cases (not to mention more general web based ones) unserviced. Bodega addresses all of the above. There are a variety of potential collaboration points for Bodega and AppStream, including (and probably not limited to): * Bodega being able to process AppStream data files as a way to import applications as assets in the warehouse. This would be similar to how we handle Project Gutenberg’s book catalog, for instance. * AppStream could use Bodega as a way to provide the user participation side of things: ratings, comments, user submissions, etc. If Bodega and AppStream do continue on without collaborating, which is a valid option, there really will be very little in the way of overlap between the two and I hope over time we can make it clear that they are really not comparable systems. -- Aaron J. Seigo
Re: Adopting AppData in KDE?
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 shipping their own official App Store mean for cross-distro/cross-desktop app store efforts and do we need to start working on our own now, or will Bodega fill that need for us? This is an area of understandable confusion, but Bodega and AppStream do rather very different things. AppStream is a way to present a more modern interface to packages in the OS vendor’s repositories. (Theoretically, 3rd party repos too.) It is rather unhelpful for non-package-manager-packages, for non-application content types or for use as an in-app system. Last I looked, AppStream has as a goal utilizing OCS for user interface. [...] 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 use of OCS for AppStream. This still needs to be discussed with the others, but I would rather like to use an improved OCS or a completely new API for the AppStream RatingsReview features (as well for maybe payments, but that's a different issue). AppStream is very focused on the needs of desktop Linux. There is *nothing* wrong about that in the least, but it leaves mobile, embedded and server use cases (not to mention more general web based ones) unserviced. Can you please clarify what AppStream is missing for mobile? Bodega addresses all of the above. There are a variety of potential collaboration points for Bodega and AppStream, including (and probably not limited to): * Bodega being able to process AppStream data files as a way to import applications as assets in the warehouse. This would be similar to how we handle Project Gutenberg’s book catalog, for instance. * AppStream could use Bodega as a way to provide the user participation side of things: ratings, comments, user submissions, etc. If Bodega and AppStream do continue on without collaborating, which is a valid option, there really will be very little in the way of overlap between the two and I hope over time we can make it clear that they are really not comparable systems. I like collaboration ;-) I still need to learn about Bodega, but e.g. AppStream could adopt the ratings reviews parts. The only thing which AppStream always needs to care of is being distro- and desktop-agnostic. Speaking of which: Would a libappstream-qt be helpful? The current AppStream library uses GObject/GLib, which can be used without problems from any Qt app - I didn't create a Qt wrapper library, because I didn't find it useful. However, it might be something we want for KDE, if more projects start to make use of AppStream (right now, Apper is the only thing using it) On topic: I wanted to create a Wiki page about AppData in KDE and the propose to adopt it ;-) It might still be worth to create one to clarify the questions raised above. Cheers, Matthias
Re: Adopting AppData in KDE?
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 question the use of OCS for AppStream. This still needs to be discussed with the others, but I would rather like to use an improved OCS or a completely new API for the AppStream RatingsReview features (as well for maybe payments, but that's a different issue). That’s a challenge I see with the AppStream design when it comes to being useful as a true ‘app store’ (let alone any other kind of store): the 95% of the support needed to make such a thing is missing. AppStream is good for its intended use case imho, don’t get me wrong; I just don’t think the use case is very interesting in the larger context. It’s a solution very focused on the needs of Linux distributions (and it does that well!), but that’s not really what people want, need or expect from a system these days. So as a better package manager viewer, I think AppStream is fantastic. I do think something like Bodega would be a lot more relevant to the modern day use cases, though. 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. AppStream is very focused on the needs of desktop Linux. There is *nothing* wrong about that in the least, but it leaves mobile, embedded and server 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 application. -- Aaron J. Seigo
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?
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 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. This would indeed be an issue for KDE... 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. 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 ;-) This might solve all translation issues, but it's not XML-ish, of course. Ubuntu does this for their .desktop-file-based Software Centers. 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. ... they're of course used as fallback though PackageKit, but that's it ;-) 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. I can confirm that :-) Cheers, Matthias
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 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 technical level (I have implemented part of it) and I would not recommend to use it as a basis for any new project, at least not without *significant* revision. Most of the requests have severe design flaws, especially there's usually an arbitrary number (e.g. 12 screenshots) of items allowed for which there are 12 different tags called screenshot1, screenshot2 etc. which makes everything a pain. This pattern is in like every request. Greetings, Sven
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 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 best. In the case of Krita I would say: * Oxygen widget style * Krita dark color scheme * KWin color scheme adjusted to take the same color scheme For us in KDE I would suggest that we set up rules on how the screenshot has to be taken, it's impressive how wrong people can use ksnapshot ;-) (I have seen screenshots with KSnapshot capturing itself during the fade-out animation also very common is to capture the transition period between active/inactive app). Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: Adopting AppData in KDE?
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 your app to the user: use what makes it look best. In the case of Krita I would say: * Oxygen widget style * Krita dark color scheme * KWin color scheme adjusted to take the same color scheme For us in KDE I would suggest that we set up rules on how the screenshot has to be taken, it's impressive how wrong people can use ksnapshot ;-) (I have seen screenshots with KSnapshot capturing itself during the fade-out animation also very common is to capture the transition period between active/inactive app). It was easyish for me... I don't have any effects enabled. Here is the current shot: http://heap.kogmbh.net/downloads/krita_appdata_1.png I excluded the window decorations, btw -- maybe also something to discuss. Boud
Re: Adopting AppData in KDE?
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 Fedora 20 for Gnome (Fedora KDE will use Apper). Currently apps that don't provide AppData are ranked lower in search results in Gnome Software, but from Gnome 3.14 such apps will not be listed at all [2]. 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? Cheers, Albert
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 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 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. This is what baffled me a bit too. Selecting applications which adhere to this standard doesn't seem like a very good way to select high-quality applications to me. Assuming KDE would say no, we don't like this standard, we want to do it differently you would lock all KDE apps out of your software installer? That being said, I do like the idea and I also like the specification. I'd like it to be adopted. Just my two cents ;) Greetings, Sven
Re: Adopting AppData in KDE?
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 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. Who's doing the quality review? HS
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: Adopting AppData in KDE?
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 that's just because the spec is new. In three years the presence of such a file will indicate exactly nothing, or will it? Greetings, Sven
Re: Adopting AppData in KDE?
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 file then that's a good indication it's at least alive. That sounds like an argument in favor of changing the standard frequently and requiring the latest version; apps implementing the latest version are clearly active! -- Nicolás
Re: Adopting AppData in KDE?
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 upstream ships a valid .desktop file and a valid AppData file then that's a good indication it's at least alive. That sounds like an argument in favor of changing the standard frequently and requiring the latest version; apps implementing the latest version are clearly active! There are some things I would like to see changed in the AppData spec, but changing it is not the point ;-) The point is that the AppData spec provides us with sufficient data to present applications to the user in a nice way. In theory, AppStream was designed to be used without AppData, so there are not many limitations when not using AppData. However, AppData greatly enhances the metadata shown by software-centers, and is therefore very useful to have. Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
