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 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" 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" 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 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 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: Can we make api.kde.org search better?
On Saturday, November 02, 2013 08:35:13 PM Albert Astals Cid wrote: > El Dissabte, 2 de novembre de 2013, a les 12:59:00, Allen Winter va escriure: > > On Saturday, November 02, 2013 12:15:15 AM Albert Astals Cid wrote: > > > Hi, yesterday i was talking with someone about the desktop file class we > > > have in KDE, he tried to find its api by going to > > > > > > api.kde.org > > > > > > and typing > > > > > > desktop > > > > > > in the Search bar. > > > > > > If you do that > > > > > > http://api.kde.org/index.php?miss=1&class=desktop > > > > > > all you get is > > > > > >No results found! > > > > > > Do you guys know if we can make the search better? > > > > A PHP person could fix the attached program so that we can search for > > ".*foo.*" (where foo is the user-specified search string) instead of simply > > "foo". > > > > that's one idea. > > > > currently foo must exactly match what's in the map files. > > > > I can provide an example map file if someone takes this on. > > Please do so, we'll find someone to take care about it, i am sure we have > some > php hacker that cares about KDE and wants to contribute :) > The map files are large. Volunteers to work on this should contact me directly and I'll work together with them and help test. -Allen
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 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 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 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 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
Review Request 113591: Reduce UDSEntry memory usage by sharing the contained QStrings if possible
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113591/ --- Review request for kdelibs and David Faure. Repository: kdelibs Description --- This patch is a subset of https://git.reviewboard.kde.org/r/113355/ (I'll continue working on the other part of that request, which can be dealt with separately, at some later point). It adds a unit test to makes sure that saving UDSEntries to a QDataStream and re-loading them works as expected, and makes use of implicit sharing of QStrings in UDSEntryPrivate::load(QDataStream &s, UDSEntry &a) to reduce the memory usage of this class (which is the major consumer of memory in Dolphin and other applications that list the contents of large directory contents with KIO). It caches the most recently loaded QString for each UDS field in a simple QVector. This works because sharable strings like, e.g., the user and the group, usually appear at the same position in the QDataStream when retrieving a large number of UDSEntries that have been stored by a kioslave. Note that I had made an earlier attempt to achieve the same thing using a QHash to look up the cached strings ( http://pastebin.kde.org/p52a24b49 ), but the QVector-based solution turns out to be faster. Diffs - kio/tests/udsentrytest.h PRE-CREATION kio/tests/udsentrytest.cpp PRE-CREATION kio/tests/CMakeLists.txt 5a1f9b5 kio/kio/udsentry.cpp 1e1f503 Diff: http://git.reviewboard.kde.org/r/113591/diff/ Testing --- kdelibs unit tests still pass. The memory usage of both Dolphin and a simple test program that uses KIO::listDir to list the contents of a large directory (see r4 of https://git.reviewboard.kde.org/r/113355/) is reduced by ~128 bytes per item according to my tests. A simple benchmark that simulates how 100,000 UDSEntries stored by kio_file are loaded (see r3 of https://git.reviewboard.kde.org/r/113355/) runs in 234 ms instead of 266 ms on my machine - it seems that growing the heap to provide space for the non-shared QStrings is more expensive than comparing all loaded QStrings with the cached values. Thanks, Frank Reininghaus
Re: Review Request 113355: Reduce UDSEntry memory usage with implicit sharing
> On Oct. 31, 2013, 2:41 p.m., Frank Reininghaus wrote: > > I see now that I have tried to put too much stuff into a single patch - > > it's too hard to digest and to understand, and the number of possibilities > > to modify different aspects of UDSEntry in a different way is just too > > large for me to test all of them. > > > > Still, I consider it a bug that every KDE application that deals directly > > or indirectly with UDSEntry wastes ~half a kilobyte of memory for every > > single file, and considering that this can be fixed by modifying just a > > single .cpp file, I would very much like to see at least a small > > improvement in the not too distant future. > > > > Maybe the best approach is to discard this review request, and open a new > > one that just adds the unit test (it never hurts to have more of them IMHO) > > and makes use of the implicit sharing of QStrings. That would at least > > bring us some of the memory savings, and it would be a rather > > straightforward change that would hopefully still be considered safe enough > > to include in kdelibs 4.12. > > > > @dfaure: I took from our discussion on the mailing list that you agree with > > the idea to reduce UDSEntry's memory usage. What do you think? > > Mark Gaiser wrote: > It's not _that_ bad.. The added unittests are big. The actual performance > improving patch isn't that big. Out of that the load(...) function is the > real complex one. > I think you should certainly commit this - as it is - to frameworks. Not > so sure for 4.12 though. The 4.12 version "should" only get bug fixes. While > this is certainly an improvement, it's not a patch that fixes any bug. On the > other hand, memory improvements are always welcome if i recall correctly. > The actual performance improving patch isn't that big. But still, it contains two different changes, which are independent of each other, and which I should have split up into two patches from the beginning. I've split out the least intrusive part into https://git.reviewboard.kde.org/r/113591/ - Frank --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113355/#review42745 --- On Oct. 26, 2013, 5:56 p.m., Frank Reininghaus wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113355/ > --- > > (Updated Oct. 26, 2013, 5:56 p.m.) > > > Review request for kdelibs. > > > Repository: kdelibs > > > Description > --- > > This patch is based on some discussions on the kfm-devel mailing list, see > http://lists.kde.org/?t=13793578483&r=1&w=2 > > Mark found out that KIO's UDSEntry class is one of the major consumers of > memory in applications which use KIO to list directories with a large number > of files, and I found a way use implicit sharing to drastically reduce the > amount of memory it needs. Many thanks to Milian for his great blog post > http://milianw.de/blog/katekdevelop-sprint-vienna-2012-take-1, without which > I would probably not have had such ideas. > > > 1. The problem > > The UDSEntry keeps all sorts of information about files which can be stored > in a string (name, user, group, etc.) or in a long long (file size, > modification time, etc.). All these data can be accessed with a uint key, and > UDSEntry returns the corresponding QString or long long in O(1) time. > Internally, it stores the data in a QHash, where Field is a > struct that has a QString and a long long member. > > The problem is that QHash needs quite a lot of memory to provide the O(1) > access, see http://doc.qt.digia.com/qq/qq19-containers.html for details, and > that the minimum capacity of a QHash seems to be 17, even though the number > of entries in a UDSEntry is often 8 in the rather typical standard kio_file > use case. > > > 2. Proposed solution > > (a) We can store the "Fields" in a QVector, which needs only very > little overhead compared to the memory that the actual "Fields" need. When > loading a UDSEntry from a QDataStream, we just append all "Fields" to this > QVector one by one. Moreover, we need a QHash, which maps each key > to the index of its Field in the QVector. This restructuring alone does not > reduce the memory usage, of course. > > (b) The key observation is that the QDataStream, which KIO::ListJob reads the > UDSEntries from, typically provides the different "Fields" in exactly the > same order. This means that the QHash is usually exactly the same > for every UDSEntry, and we can make use of implicit sharing to store only one > copy of this QHash. I've modified > > void UDSEntryPrivate::load(QDataStream &s, UDSEntry &a) > > such that it remembers the most recent QHash and jus
Re: Review Request 113355: Reduce UDSEntry memory usage with implicit sharing
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113355/ --- (Updated Nov. 3, 2013, 7 p.m.) Status -- This change has been discarded. Review request for kdelibs. Repository: kdelibs Description --- This patch is based on some discussions on the kfm-devel mailing list, see http://lists.kde.org/?t=13793578483&r=1&w=2 Mark found out that KIO's UDSEntry class is one of the major consumers of memory in applications which use KIO to list directories with a large number of files, and I found a way use implicit sharing to drastically reduce the amount of memory it needs. Many thanks to Milian for his great blog post http://milianw.de/blog/katekdevelop-sprint-vienna-2012-take-1, without which I would probably not have had such ideas. 1. The problem The UDSEntry keeps all sorts of information about files which can be stored in a string (name, user, group, etc.) or in a long long (file size, modification time, etc.). All these data can be accessed with a uint key, and UDSEntry returns the corresponding QString or long long in O(1) time. Internally, it stores the data in a QHash, where Field is a struct that has a QString and a long long member. The problem is that QHash needs quite a lot of memory to provide the O(1) access, see http://doc.qt.digia.com/qq/qq19-containers.html for details, and that the minimum capacity of a QHash seems to be 17, even though the number of entries in a UDSEntry is often 8 in the rather typical standard kio_file use case. 2. Proposed solution (a) We can store the "Fields" in a QVector, which needs only very little overhead compared to the memory that the actual "Fields" need. When loading a UDSEntry from a QDataStream, we just append all "Fields" to this QVector one by one. Moreover, we need a QHash, which maps each key to the index of its Field in the QVector. This restructuring alone does not reduce the memory usage, of course. (b) The key observation is that the QDataStream, which KIO::ListJob reads the UDSEntries from, typically provides the different "Fields" in exactly the same order. This means that the QHash is usually exactly the same for every UDSEntry, and we can make use of implicit sharing to store only one copy of this QHash. I've modified void UDSEntryPrivate::load(QDataStream &s, UDSEntry &a) such that it remembers the most recent QHash and just adds an implicitly shared copy of it to "a" if the order of the Fields has not changed. (c) Moreover, some of the QString Fields in the UDSEntries in one directory are often the same, like, e.g., the user and the group. The "load" function also remembers the most recently read values for each Field in a static QVector and just puts an implicitly shared copy into the UDSEntry if possible. 3. Possible disadvantages (a) When using the "remove" member, the new version of UDSEntry does not remove the Field from the QVector. This means that removing and adding a "Field" repeatedly would let the memory usage grow indefinitely. According to David (http://lists.kde.org/?l=kfm-devel&m=138052519927973&w=2), this doesn't matter though because no known user of UDSEntry uses its remove() member. Maybe we should remove remove (pun stolen grom David) in the frameworks branch then? (b) In principle, the old version of UDSEntryPrivate::load(QDataStream&, UDSEntry&) was reentrant. This is not the case for my changed version. Reentrancy could be restored rather easily by protecting the access to the static data with a mutex, but given that most of KIO is not supposed to be used from outside the main thread AFAIK, I don't know if this is necessary. 4. Changes since the first version of the patch which I posted in http://lists.kde.org/?l=kfm-devel&m=137962995805432&w=2 (a) Implemented the minor changes suggested by David in http://lists.kde.org/?l=kfm-devel&m=137975442807965&w=2 (b) Added a unit test to verify that storing and loading UDSEntries from a stream works even if the order of the fields is permuted, and some fields are removed or added in between. (c) Fixed a bug which was uncovered by the test: cachedUdsFields.erase(cachedUdsFields.begin() + i, cachedUdsFields.end()) instead of cachedUdsFields.erase(cachedUdsFields.begin() + i) (d) Use QVector::reserve to reserve the appropriate size for the QVector. Saves some time when loading the UDSEntry, and reduces the memory usage further. (e) Changed the type of the loop variable from quint32 to int to fix some compiler warnings. Diffs - kio/kio/udsentry.h e1c8b05 kio/kio/udsentry.cpp 1e1f503 kio/tests/CMakeLists.txt 1019312 kio/tests/simplelistjobtest.cpp PRE-CREATION kio/tests/udsentrybenchmark.cpp PRE-CREATION kio/tests/udsentrytest.h PRE-CREATION kio/tests/udsentrytest.cpp PRE-CREATION Diff: http://git.reviewboard.kde.
Re: Adopting AppData in KDE?
On 3 November 2013 17:15, Thomas Lübking wrote:
> I think everyone who read this thread was immediately aware that the "high
> quality applications" argument is "flawed" (i've actually another term in
> mind)
Sure, that might be true, but that's not what I was originally trying
to help with. 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 : > On 3 November 2013 17:15, Thomas Lübking 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
