Re: Distros and QtWebEngine
2015-04-20 23:41 GMT+02:00 Thomas Lübking : > On Montag, 20. April 2015 23:02:34 CEST, Sune Vuorela wrote: > >> Let's just try to follow that thru. >> >> A new QuigleyImageView pulls in a new Qt. The newer Qt breaks somehow >> Plasma, >> because relying on internals. Then a newer Plasma is pulled in. THat ... > > > You can apply that on really *anything* - the obvious (claimed) failure is > "Qt breaks somehow Plasma" because either > a) a client relied on undocumented behavior (client bug) or > b) a foundation broke documented API/ABI/Behavior (foundation bug) > > Also your list implies that one never can update KDE, because that breaks > GNOME, requires a kernel update and whatnot. (Taking my Debian developer hat) Yes, stuff like that happens and is absolutely common - that's why we have a development cycle, where we tune the distribution to have all parts working well together. If we make a huge update on one part, we might end up breaking more things than we solve issues. >> Unfortunately, I haven't really used my imagination here. > > That implies the Linux SW stack is crap. Point taken. Well, it's not crap, but... ;-) Different upstreams care for different things: Some care very much for backward compatibility and never break API or ABI. Others, however, break API/ABI with every single release, remove features and add new ones or even decide to rewrite the whole application. They might also drop support for lower versions of dependency X at any time. I don't say this behaviour is bad, but it makes it impossible to plan for changes, and to be 100% certain that a change does not break other unrelated software. When we release a new version of Debian, users expect the current feature set to remain stable, so they can tune their workflow to it and be sure it does not randomly break because a software decided to e.g. remove command-line flag which became unsupported upstream. The same way, the quick webbrowser updates are a huge issue in the enterprise. In order to keep the whole thing we call a "distribution" sane, we have a set of rules, like "do not duplicate code in the archive". This ensures that we do not need to patch the same thing over and over again, in case there is a security hole in the respective code block. So, in summary: The free software stack is a mess, and distributors align it to produce a working compilation of software. This is simply because there is no central authority coordinating the development of Mesa, Plasma, GNOME, GCC, systemd, etc., so incompatibilities can arise at any time. Cheers, Matthias
Re: Notes from the Phabricator BoF
2015-07-31 11:41 GMT+02:00 Ben Cooksley : > On Fri, Jul 31, 2015 at 8:42 AM, Kevin Kofler wrote: >> Luigi Toscano wrote: >>> Feedback on Phabricator gathered outside the BoF from people who could not >>> attend: >> >> Were there no complaints about the fact that you can still not view anything >> at all without logging in? > > This has now been corrected. Unfortunately the old default policy for > issues, etc. was set to "All Users" rather than "Public" so we'll have > to migrate the existing tasks and reviews over to that at some point. > New ones should be properly set to public though You can use the conduit API to automatically set stuff to public, or batch-process the tasks to change their visibility. > unless people > explicitly override (please don't). You could remove permission to override this setting, or only give it to a specific group of people ;-) Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Notes from the Phabricator BoF
2015-08-01 13:54 GMT+02:00 Ben Cooksley :
> On Sat, Aug 1, 2015 at 11:48 PM, Matthias Klumpp
> wrote:
>> 2015-07-31 11:41 GMT+02:00 Ben Cooksley :
>>> On Fri, Jul 31, 2015 at 8:42 AM, Kevin Kofler
>>> wrote:
>>>> Luigi Toscano wrote:
>>>>> Feedback on Phabricator gathered outside the BoF from people who could not
>>>>> attend:
>>>>
>>>> Were there no complaints about the fact that you can still not view
>>>> anything
>>>> at all without logging in?
>>>
>>> This has now been corrected. Unfortunately the old default policy for
>>> issues, etc. was set to "All Users" rather than "Public" so we'll have
>>> to migrate the existing tasks and reviews over to that at some point.
>>> New ones should be properly set to public though
>>
>> You can use the conduit API to automatically set stuff to public, or
>> batch-process the tasks to change their visibility.
>
> Already checked the batch change functionality - it lacks the power to
> change visibility / permissions on tasks (unless I missed something).
> In terms of the Conduit API - I expected that to be the case, just
> don't have a script to hand to do it just yet :)
See the attached script for how to do it ;-) You will need to create a
bot user, generate an API token and install the certificate using
Arcanist before using it.
(and you will also need to adjust it to fit the KDE Phabricator needs,
of course)
>>> unless people
>>> explicitly override (please don't).
>>
>> You could remove permission to override this setting, or only give it
>> to a specific group of people ;-)
>
> Hmm, where is this permission found? I haven't yet found one that
> allows you to restrict the ability to override default permissions,
> and it's one i'd rather like to find (I know Spaces does have some
> capability in this department though).
Maniphest Settings --> Edit Policies --> Set "Can Edit Task Policies"
to team which should be able to do it, our just to Administrators to
forbid others to change the default.
Hope that helps :-)
Cheers,
Matthias
--
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/
#!/usr/bin/python3
import urllib.request
import json
import os
import sys
import subprocess
PHAB_URL= "http://tracker.tanglu.org";
CONDUIT_TOKEN="api-BLAHBLAH12345678"
def call_conduit(cmd, json_data):
arcanist_cmd = ["arc", "call-conduit", "--conduit-uri", PHAB_URL, "--conduit-token", CONDUIT_TOKEN, cmd]
process = subprocess.Popen(arcanist_cmd, stdout=subprocess.PIPE, stdin=subprocess.PIPE, stderr=subprocess.PIPE)
process.stdin.write(bytes(json_data, 'UTF-8'))
process.stdin.close()
process.wait()
stderr = process.stderr.read()
stdout = process.stdout.read()
if stderr:
print("ERROR:")
print(stderr)
sys.exit(2)
rdata = None
try:
rdata = json.loads(stdout.decode('utf-8'))
except:
print("ERROR:")
print(stdout)
sys.exit(3)
if rdata['error']:
if rdata['error'] != "ERR-NO-EFFECT":
print("ERROR:")
print(rdata['errorMessage'])
sys.exit(1)
return rdata
def main():
max_tid = 12
for tid in range(1, max_tid):
fdata = dict()
fdata['id'] = tid
fdata['viewPolicy'] = "public"
json_data = json.dumps(fdata)
call_conduit("maniphest.update", json_data)
print("Processed %i" % (tid))
if __name__ == "__main__":
main()
Re: web server for appstream metadata screenshots
2016-06-08 18:27 GMT+02:00 Burkhard Lück : > Am Mittwoch, 8. Juni 2016, 12:45:13 CEST schrieb Nicolás Alvarez: >> 2016-06-08 8:33 GMT-03:00 Friedrich W. H. Kossebau : >> > [...] >> > Not sure though what a stable url would be like, given people planning to >> > rework kde.org (and thus those app catalog pages), so perhaps relying on >> > the current screenshot urls used by kde.org/applications is not perfect. >> The screenshots on kde.org/applications are stored in SVN and they are >> the main reason why I couldn't migrate that website to Git. I would >> prefer if you don't add even more there... > > www/sites/www/screenshots (svn) has 176 pngs > > websites/edu-kde-org/ (git) has 1287 pngs > > master kf5 / doc[s] (git) folders have 2079 pngs > > master kde4 / doc[s] (git) folders have 1702 pngs > > I do not understand why the 176 pngs in www/sites/www/screenshots are a > problem for migration to git IMHO these screenshots should be separated out into a different Git repository, and the original website should link to them. Reason is that that way, application maintainers in KDE can easily update their screenshots, without needing to write to the website repo. Also, separating these media files out just seems sane design to me. In terms of "binary files in Git are a bad idea", separating the media out would allow the website to migrate to Git, and the media files could be maintained with for example Git-Annex[1]. Git-Annex is an awesome tool, which would likely fit our needs here while having a flat learning courve. Cheers, Matthias [1]: https://git-annex.branchable.com/ -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: web server for appstream metadata screenshots
2016-06-12 6:46 GMT+02:00 Yuri Chornoivan : > [...] > > I might misunderstand the whole thing. If it is, just ignore this message. > > The typical size of AppData screenshot is ~100 kB. Let's say that there are > ~1000 users that use Discover features to explore KDE applications in a > release day. They can overview ~10 screenshots in average. This will be 1 GB > of traffic + load on Phabricator to resolve commits.kde.org links (if files > are stored in git). Well, most distributions cache screenshots on their own and serve them from their infrastructure (Debian, Fedora, Ubuntu and OpenSUSE do that), while only a few use the upstream-provided URLs directly (I am only aware of Arch right now). Caching stuff allows distros to provide resized thumbnails for smaller downloads and also allows blocking certain screenshots from showing up in the software-center retroactively (e.g. in case someone added non-free copyrighted material there, and we realize that only later). This is just FYI, I still think a Git-Annex $whatever based repository of screenshots is better than hotlinking them into Phabricator or Quickgit. Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: web server for appstream metadata screenshots
2016-06-12 20:29 GMT+02:00 Albert Astals Cid : > [...] > Noone is suggesting hotlinking into Phabricator or Quickgit. And noone is > doign that either (unless someone has proof otherwise). I was commenting on this: 2016-06-08 23:37 GMT+02:00 Ben Cooksley : > On Thu, Jun 9, 2016 at 4:32 AM, Yuri Chornoivan wrote: >> написане Wed, 08 Jun 2016 19:27:23 +0300, Burkhard Lück >> : >> >>> Am Mittwoch, 8. Juni 2016, 12:45:13 CEST schrieb Nicolás Alvarez: >>> [...] >>> I do not understand why the 176 pngs in www/sites/www/screenshots are a >>> problem for migration to git >> >> Hi, >> >> I might be wrong, but is the hotlinking to Phabricator/Git files >> (screenshots in this case) a good thing? > > Hotlinking to any repository browser (whether Phabricator, Quickgit, > WebSVN or anything else) on KDE infrastructure is not supported under > any circumstance. Our web servers are configured to block some forms > of this already. > > Repository browsers are extremely expensive resource wise, compared to > static file serving, and one can expect something like Appstream > metadata to receive quite a few hits, therefore something properly > setup for this should be done. > [...] Specifically I was referring to the "might receive quite a few hits" stance. I am not saying that linking to repo browsers is a good idea (quite the contrary, as stated in my previous mail), but the hits on AppStream content might be much fewer than sysadmins expect due to distribution-internal data caching. (Btw, I have seen people linking to screenshots in Git repos, but those were no KDE projects.) -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: web server for appstream metadata screenshots
2016-06-14 0:34 GMT+02:00 Albert Astals Cid : > [...] > You can not have all of these three: > * Free commit to screenshots used by appstream Create a Git/$whatever repository just for screenshots somewhere, and make its contents available on the web, e.g. via static.kde.org / screenshots.kde.org, etc. > * Shared screenshots between www and appstream Have www embed screenshots from the xyz.kde.org server, instead of keeping them with the other www-related files in SVN. This also allows www to migrate to Git more easily, unless there are other large files stored in there. > * Protected contents in www Since people will only have access to the screenshots repo, www can stay protected and writable only by a smaller group. Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: web server for appstream metadata screenshots
2016-06-14 1:03 GMT+02:00 Albert Astals Cid : > El dimarts, 14 de juny de 2016, a les 0:54:06 CEST, Matthias Klumpp va > escriure: >> 2016-06-14 0:34 GMT+02:00 Albert Astals Cid : >> > [...] >> > >> > You can not have all of these three: >> > * Free commit to screenshots used by appstream >> >> Create a Git/$whatever repository just for screenshots somewhere, and >> make its contents available on the web, e.g. via static.kde.org / >> screenshots.kde.org, etc. >> >> > * Shared screenshots between www and appstream >> >> Have www embed screenshots from the xyz.kde.org server, instead of >> keeping them with the other www-related files in SVN. This also allows >> www to migrate to Git more easily, unless there are other large files >> stored in there. > > You realize this breaks the "protected contents in www" if everyone can upload > files to xyz.kde.org and they magically show up in www, right? Well, they would only show up on a subdomain, and not be visible immediately on the main website. You can also use a pre-commit check in Git to allow only .png images up to a certain size, to prevent people from uploading other stuff to the repository. That doesn't prevent anyone from replacing all KDE screenshots with cute cat pictures of course, but I do trust the KDE community on that :) Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: How to install icons for multiple themes
2017-04-20 11:30 GMT+02:00 Milian Wolff : > [...] > Hey Albert, > > sorry for the delay and thanks for the response. The above makes me wonder > about the functionality of ecm_install_icons. As it stands, it is completely > broken for anything but the hicolor theme, don't you agree? I would say we > should fix it there, somehow... > > It is very unfortunate that the themes can come up with their own path > mapping... Indeed - unfortunately it's to late to change that now :-/ > How do other applications deal with this situation? Should the apps only > install hicolor, and the other per-theme icons be submitted to the > corresponding icon themes? That's exactly how this is intended to work, anything except the hicolor/locolor default themes is essentially expected to be self-contained. Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: How to install icons for multiple themes
2017-04-21 12:33 GMT+02:00 Kevin Kofler : > [...] > I think it would really be helpful to make Breeze match the de-facto > standard directory hierarchy. I asked for this a while back (and also to have PNG additional to SVG icons for rendering speed improvements) and the bug report was closed without comment. And since the spec allows themes to define arbitrary layouts, there is technically nothing wrong with the Breeze theme. In any case, ecm_install_icons makes assumptions which are not guaranteed to be true... -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: freedesktop.org meeting again?
Am Mo., 11. Feb. 2019 um 00:06 Uhr schrieb Aleix Pol : > > On Sat, Feb 9, 2019 at 1:32 PM David Faure wrote: >> >> Is anyone interested in participating in a technical meeting with other >> desktop environments? >> >> I did that years ago and this is how we came up with various shared >> specifications, but at this point it might be more useful for people working >> on other things to attend. Oh, nice that this is happening again! I would be very interested in attending, but I am already working on cross-desktop stuff and less on "pure" KDE projects (so as a KDE delegate I might not be the best choice). Cheers, Matthias >> -- Forwarded Message -- >> >> Subject: freedesktop.org meeting again? >> Date: mercredi 6 février 2019, 15:27:32 CET >> From: Agustin Benito Bethencourt >> To: Lennart Poettering , David Faure , >> de...@desrt.ca >> >> Dear Allison, David and Lennart, >> >> this mail has as a goal to evaluate the interest you would have in meeting >> again like you guys did in 2013 and 2014 in Nuremberg, Germany, hosted again >> by SUSE, this time during the openSUSE Conference[1], that will take place >> from May 24th to May 26th. >> >> If the dates, location matches your availability and there is interest in >> having this working sessions, I would be happy to coordinate the logistics >> and >> invite those who you think it should be present.. SUSE and openSUSE >> representatives are very interested in hosting this activity once again. >> >> What do you think? Who else should be at the event? >> >> [1] https://events.opensuse.org/conference/oSC19 >> > > It could be an interesting event to have indeed. Maybe it would make sense to > piggy-back on something more on-topic like XDC or LAS? > Or is SUSE especially interested? > > Aleix -- I welcome VSRE emails. See http://vsre.info/
Re: Adopting AppData in KDE?
2013/11/2 Aaron J. Seigo : > 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 Ratings&Review 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?
2013/11/2 Richard Hughes : > On 2 November 2013 11:00, Yuri Chornoivan wrote: >> 1. AppData files are tailored for intltool/its-tool processing (tags with >> underscores). What do you think about adding untranslatable by design >> appdata files like it was done for Audacity [1]? > > Well, this is fine if you speak en_GB or en_US, 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?
2013/11/2 Nicolás Alvarez : > 2013/11/2 Richard Hughes : >> On 2 November 2013 20:00, Harald Sitter wrote: We want to showcase high quality applications with active upstream maintainers. >>> Who's doing the quality review? >> >> Well, if an upstream ships a valid .desktop file and a valid AppData >> file then that's a good indication it's at least alive. > > 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/
Re: Adopting AppData in KDE?
2013/11/4 Rex Dieter : > 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?
2013/11/4 Christoph Feck : > 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?
2013/11/5 Aaron J. Seigo : > On Tuesday, November 5, 2013 12:57:28 Richard Hughes wrote: >> On 5 November 2013 12:18, Aaron J. Seigo wrote: >> > why do you need to know this? can AppStream not call external tools to do >> > the installation? >> >> The way AppStream is generated in Fedora is we: > > 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?
2013/11/5 Todd : > [...] > Looking at the spec, I have a few suggestions: (I assume you mean the AppStream spec) > For , 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 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 Marco Martin : > [...] >> > > 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: Qt 5.3 to log all debug/warning/error messages to journald on systemd systems
2014/1/21 Martin Gräßlin : > On Monday 20 January 2014 14:40:17 Thiago Macieira wrote: >> See subject. We're trying to decide whether we should enable journald by >> default on Linux distributions that carry it. If we do, it means any >> application that is not launched from a terminal would automatically write >> to journald instead. >> >> KDE applications are the largest users of qDebug today. >> >> If we changed the default, it would mean ~/.xsession-errors would probably >> become rather empty. Is that ok for KDE? > I like this +1 That would be pretty awesome, especially because journalctl has some nice filtering capabilities. As long as it can be disabled by people not using the journal (or don't want these things in their syslog if the journal forwards them), I also don't think anyone could complain about it :-) Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Qt 5.3 to log all debug/warning/error messages to journald on systemd systems
2014/1/21 Thiago Macieira :
> On terça-feira, 21 de janeiro de 2014 13:55:15, Sebastian Kügler wrote:
>> One thing that may concern me is how to clean the system from debugging
>> messages then. Sometimes applications go rogue on qDebug() (recent example
>> the message from QPainter in Qt5, which has just been fixed), so the
>> journal will end up pretty big, and also in the home directory.
>>
>> I like how it's easy to delete all that spam with just one file. I would not
>> quite like it to end up on my / partition, since that one is usually pretty
>> small, and it can prevent the system from booting when the journal is
>> filled up.
>
> Most people don't know how to clean ~/.xsession-errors either. The best and
> easiest way to clean it is to log out and then log in again. Deleting the file
> is *not* enough, since it stays existing until the last application using it
> exits.
>
> The correct way to shrink the file while running is:
>
> echo > ~/.xsession-errors
>
> But no, I don't know how to clean the journal log. That's a good question.
You could use the journald configuration to set the journal to an
exact/relative size (by default it takes 10% of the disk space).
A hardcore method to clean it would be
find /var/log/journal -name "*.journal~" -exec rm {} \;
which should wipe the whole journal (caution, I never tried that!)
Cheers,
Matthias
--
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/
Re: KDM + ConsoleKit + Logind
2014-02-17 13:55 GMT+01:00 Lukáš Tinkl : > Dne 17.2.2014 11:51, Harald Sitter napsal(a): > >> Ahoys >> >> I was looking for some input on KDM+CK in a Logind world. When a >> system is using Logind I guess KDM+CK doesn't do much useful, so the >> question arose whether distributions with such a lineup should build >> without CK support. In short: >> >> If the rest of the system uses Logind, should KDM be built without CK >> support? >> >> Would building without CK support reduce user functionality, and if so >> aren't we then essentially requiring distributions that use KDM to >> continue using CK until Plasma Next comes along? (we are not >> communicating this very if this is the case). > Hi, > I'm not entirely sure about kdm but for the rest of the code in > kde-workspace (kworkspace, powerdevil et co.), login1 support is fairly > complete and preferred over CK. We are using a KDE 4.11 systemd running on pure logind in Tanglu without any reported issues. KDM has multiseat patches applied, which were taken from[1]. We also adjusted some other dependencies, but that was just minor work on the packaging. So yes, you can use KDM with logind, but I am not sure that using it at all will make sense long-term, since KDM is dead now. Cheers, Matthias [1]: https://git.reviewboard.kde.org/r/112294/diff/
Lokalization for KDE AppStream AppData files
Hi! I am working on bringing AppData to KDE. AppData is a XML-based metadata format to enhance information displayed about applications in software-centers. It, for example, includes long descriptions of an application, homepage links, donation-links, screenshot-info and some other information about the application. AppStream is a Freedesktop project enabling us to build cross-distro software centers. GNOME is already making heavy use of it for their GNOME-Software application, and KDE also uses it already in Apper and probably Muon soon. One challenge for KDE is how to handle localizations for AppData information. I would propose the following: * KDE applications ship an .appdata.xml.in file, containing the raw, untranslated data. * We extend messages.sh to scan the XML file and return the found strings to the generic pot file, which is then translated by our localization teams as usual. * At build-time, we use intltool[1] to merge the translation with the AppData file, then install it into it's target directory. This is basically it. The only thing KDE projects need to do is to edit their Messages.sh and depend on intltool to merge localization. I could also provide a cmake macro for doing that to extra-cmake-modules, if needed. Do you have comments or suggestions on this? I would later add it to the wiki page I'm doing to describe how KDE projects which want to use AppData can easily use it. Kind regards, Matthias Links: [1]: http://freedesktop.org/wiki/Software/intltool/ AppStream: http://www.freedesktop.org/wiki/Distributions/AppStream/ AppData: http://people.freedesktop.org/~hughsient/appdata/ greetings to people who watched my FOSDEM talk ;-) -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Lokalization for KDE AppStream AppData files
2014-02-20 19:33 GMT+01:00 Martin Graesslin : > On Thursday 20 February 2014 18:54:32 Matthias Klumpp wrote: >> Hi! >> I am working on bringing AppData to KDE. AppData is a XML-based >> metadata format to enhance information displayed about applications in >> software-centers. It, for example, includes long descriptions of an >> application, homepage links, donation-links, screenshot-info and some >> other information about the application. >> AppStream is a Freedesktop project enabling us to build cross-distro >> software centers. GNOME is already making heavy use of it for their >> GNOME-Software application, and KDE also uses it already in Apper and >> probably Muon soon. >> One challenge for KDE is how to handle localizations for AppData >> information. I would propose the following: >> * KDE applications ship an .appdata.xml.in file, containing the >> raw, untranslated data. >> * We extend messages.sh to scan the XML file and return the found >> strings to the generic pot file, which is then translated by our >> localization teams as usual. >> * At build-time, we use intltool[1] to merge the translation with the >> AppData file, then install it into it's target directory. >> This is basically it. The only thing KDE projects need to do is to >> edit their Messages.sh and depend on intltool to merge localization. I >> could also provide a cmake macro for doing that to >> extra-cmake-modules, if needed. >> Do you have comments or suggestions on this? >> I would later add it to the wiki page I'm doing to describe how KDE >> projects which want to use AppData can easily use it. > > Why can't scripty update the xml file like it does with the .desktop files? > I'm > a little bit afraid of a more complicated build process as the translations > life in a different repository and I assume most devs don't have them around > at > all. Technically, this would of course work as well, but it needs work on Scripty (should be relatively simple to implement though). Also, the translated files can grow pretty large, because they contain translated long descriptions, which is very messy to work with compared to having one source file with the raw, untranslated data[1]. > Would that work for distributions? Don't they build the language data > separately? For applications which don't ship .po files with their release package, we have no choince other than including the translation directly (or shipping the Gettext data together with the application it belongs to). Cheers, Matthias [1]: Take the GEdit AppData as an example: http://paste.kde.org/pq2iajyku - this one contains only one translated field. -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Lokalization for KDE AppStream AppData files
2014-02-21 2:02 GMT+01:00 Aleix Pol : > [...] > > I'm very happy to see you pushing this forward. Muon will be supporting this > format from the next released version (to some extent) and I'm sure this > will increase over time. Great! Please keep in mind that the format is not meant to be processed directly, but instead an intermediate Xapian database is used. GNOME does not use it because the library for accessing the db was not ready in time and it only had to run on Fedora anyway at that time. I will hopefully have time to work on the database stuff this weekend. > Regarding localization, Albert is the man here. If he says it's done in a > way, you do it this way. ;-) > More seriously though, I agree that it's doesn't make much sense to have it > generated at build time, since this would require having all translations > installed. Maybe we can figure out a mechanism appdata -> po -> appdata like > in the desktop files. It works great there for desktop files, and it's the > exact same use-case. I have a compromise to offer, which will be necessary anyway in a way, since to-be-localized entries in our XML files would have to be prefixed with an underscore, so merging stuff back into the original file does not work (unless we duplicate data there, which is ugly). So, new suggestion: * Project author creates file project.appdata.xml.in, containing the raw data which has to be translated. * Scripty processes that file and commits a project.appdata.xml file in the same directory where the previous one was, containing all localizations. If one is already there, the file is updated. * We simply install the localized file and keep the other one as template That solution would work, I would be happy with it and hopefully Albert as well :-) If not, please make an alternative suggestion. Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Lokalization for KDE AppStream AppData files
2014-02-23 15:44 GMT+01:00 Albert Astals Cid : > El Divendres, 21 de febrer de 2014, a les 16:48:01, Matthias Klumpp va > escriure: >> 2014-02-21 2:02 GMT+01:00 Aleix Pol : >> > [...] >> I have a compromise to offer, which will be necessary anyway in a way, >> since to-be-localized entries in our XML files would have to be >> prefixed with an underscore, so merging stuff back into the original >> file does not work (unless we duplicate data there, which is ugly). >> So, new suggestion: >> * Project author creates file project.appdata.xml.in, containing the >> raw data which has to be translated. >> * Scripty processes that file and commits a project.appdata.xml file >> in the same directory where the previous one was, containing all >> localizations. If one is already there, the file is updated. >> * We simply install the localized file and keep the other one as template >> That solution would work, I would be happy with it and hopefully >> Albert as well :-) If not, please make an alternative suggestion. > > Why do you need two files instead of one file like we do for .desktop files? All translatable items are prefixed with an underscore, for example: <_p> Software allows you to find and install new applications and system extensions and remove existing installed applications. If we merge back translations into the same file, we would have to provide the same item twice (with and w/o underscore), which is ugly. Also, having one file to edit which is not full of translation data is easier, because you can spot the stuff you have to edit immediately. By providing a list of translatable items, you could in theory merge stuff into one file as well. I think itstool can do that. In that case, we would have a special-case solution for AppStream AppData in Scripty. Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Lokalization for KDE AppStream AppData files
2014-02-23 16:28 GMT+01:00 Kevin Krammer : > On Sunday, 2014-02-23, 16:13:46, Matthias Klumpp wrote: >> 2014-02-23 15:44 GMT+01:00 Albert Astals Cid : >> > El Divendres, 21 de febrer de 2014, a les 16:48:01, Matthias Klumpp va >> > >> > escriure: >> >> 2014-02-21 2:02 GMT+01:00 Aleix Pol : >> >> > [...] >> >> >> >> I have a compromise to offer, which will be necessary anyway in a way, >> >> since to-be-localized entries in our XML files would have to be >> >> prefixed with an underscore, so merging stuff back into the original >> >> file does not work (unless we duplicate data there, which is ugly). >> >> >> >> So, new suggestion: >> >> * Project author creates file project.appdata.xml.in, containing the >> >> >> >> raw data which has to be translated. >> >> >> >> * Scripty processes that file and commits a project.appdata.xml file >> >> >> >> in the same directory where the previous one was, containing all >> >> localizations. If one is already there, the file is updated. >> >> >> >> * We simply install the localized file and keep the other one as >> >> template >> >> >> >> That solution would work, I would be happy with it and hopefully >> >> Albert as well :-) If not, please make an alternative suggestion. >> > >> > Why do you need two files instead of one file like we do for .desktop >> > files? >> All translatable items are prefixed with an underscore, for example: >> <_p> >> Software allows you to find and install new applications and system >> extensions and remove existing installed applications. >> > > Which part of the chain causes this requirement? > Is the database builder looking for this to check which parts of the document > it has to check for translations? It is used as fallback if there is no translation available for the current language. If there is no localized description, the original English one is added to the database instead. -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Lokalization for KDE AppStream AppData files
2014-02-23 16:37 GMT+01:00 Kevin Krammer : > On Sunday, 2014-02-23, 16:31:37, Matthias Klumpp wrote: >> 2014-02-23 16:28 GMT+01:00 Kevin Krammer : >> > On Sunday, 2014-02-23, 16:13:46, Matthias Klumpp wrote: >> >> 2014-02-23 15:44 GMT+01:00 Albert Astals Cid : >> >> > El Divendres, 21 de febrer de 2014, a les 16:48:01, Matthias Klumpp va >> >> > >> >> > escriure: >> >> >> 2014-02-21 2:02 GMT+01:00 Aleix Pol : >> >> >> > [...] >> >> >> >> >> >> I have a compromise to offer, which will be necessary anyway in a way, >> >> >> since to-be-localized entries in our XML files would have to be >> >> >> prefixed with an underscore, so merging stuff back into the original >> >> >> file does not work (unless we duplicate data there, which is ugly). >> >> >> >> >> >> So, new suggestion: >> >> >> * Project author creates file project.appdata.xml.in, containing the >> >> >> >> >> >> raw data which has to be translated. >> >> >> >> >> >> * Scripty processes that file and commits a project.appdata.xml file >> >> >> >> >> >> in the same directory where the previous one was, containing all >> >> >> localizations. If one is already there, the file is updated. >> >> >> >> >> >> * We simply install the localized file and keep the other one as >> >> >> template >> >> >> >> >> >> That solution would work, I would be happy with it and hopefully >> >> >> Albert as well :-) If not, please make an alternative suggestion. >> >> > >> >> > Why do you need two files instead of one file like we do for .desktop >> >> > files? >> >> >> >> All translatable items are prefixed with an underscore, for example: >> >> <_p> >> >> >> >> Software allows you to find and install new applications and system >> >> extensions and remove existing installed applications. >> >> >> >> >> > >> > Which part of the chain causes this requirement? >> > Is the database builder looking for this to check which parts of the >> > document it has to check for translations? >> >> It is used as fallback if there is no translation available for the >> current language. If there is no localized description, the original >> English one is added to the database instead. > > I see. > If you don't mind, what was the reason for chosing this approach? Wouldn't it > have also been possible to fall back to the sibling without the lang > attribute as a base instead? Ah, I think we are talking about different things ;-) The process is: 1) Developer writes XML with some tags prefixed with an underscore 2) intltool scans the input-XML for stuff with an underscore, localizes the tag and adds both the localized tag as well as the original tag (without underscore!) to the output XML The result is a file which is localized. The underscore is just used in the template to select elements which are translated (because some aren't, for example the icon name). The database builder (or the AppStream data generator in that case) checks for the output file, not the template to generate it.
Re: Lokalization for KDE AppStream AppData files
2014-02-23 16:43 GMT+01:00 Albert Astals Cid : > El Diumenge, 23 de febrer de 2014, a les 16:31:37, Matthias Klumpp va > escriure: >> 2014-02-23 16:28 GMT+01:00 Kevin Krammer : >> > On Sunday, 2014-02-23, 16:13:46, Matthias Klumpp wrote: >> >> 2014-02-23 15:44 GMT+01:00 Albert Astals Cid : >> >> > El Divendres, 21 de febrer de 2014, a les 16:48:01, Matthias Klumpp va >> >> > >> >> > escriure: >> >> >> 2014-02-21 2:02 GMT+01:00 Aleix Pol : >> >> >> > [...] >> >> >> >> >> >> I have a compromise to offer, which will be necessary anyway in a way, >> >> >> since to-be-localized entries in our XML files would have to be >> >> >> prefixed with an underscore, so merging stuff back into the original >> >> >> file does not work (unless we duplicate data there, which is ugly). >> >> >> >> >> >> So, new suggestion: >> >> >> * Project author creates file project.appdata.xml.in, containing the >> >> >> >> >> >> raw data which has to be translated. >> >> >> >> >> >> * Scripty processes that file and commits a project.appdata.xml file >> >> >> >> >> >> in the same directory where the previous one was, containing all >> >> >> localizations. If one is already there, the file is updated. >> >> >> >> >> >> * We simply install the localized file and keep the other one as >> >> >> template >> >> >> >> >> >> That solution would work, I would be happy with it and hopefully >> >> >> Albert as well :-) If not, please make an alternative suggestion. >> >> > >> >> > Why do you need two files instead of one file like we do for .desktop >> >> > files? >> >> >> >> All translatable items are prefixed with an underscore, for example: >> >> <_p> >> >> >> >> Software allows you to find and install new applications and system >> >> extensions and remove existing installed applications. >> >> >> >> >> > >> > Which part of the chain causes this requirement? >> > Is the database builder looking for this to check which parts of the >> > document it has to check for translations? >> >> It is used as fallback if there is no translation available for the >> current language. If there is no localized description, the original >> English one is added to the database instead. > > Which database? Who adds it to that database? The data flow is like this: Upstream (KDE!) writes an AppData file. The distributor extracts that AppData file, together with the icon and desktop file and generates AppStream XML out of that, or DEP-11 YAML or AppInstall data, which gets shipped to the users. On the user's machine, a small PackageKit plugin will generate a database out of that which in turn is used by the Software Center applications to display application data. Maybe thet will also get a bit easier to understand when looking at these graphics: https://gitorious.org/appstream/appstream/source/efbe92c92e62282a50f6d73a82dff3fca4f438fb:docs/sources/images/libappstream_architecture.png https://gitorious.org/appstream/appstream/source/efbe92c92e62282a50f6d73a82dff3fca4f438fb:docs/sources/images/architecture.png (AppData is - like a desktop file - a source of information about upstream's aoolication in order to present more data in a software center) -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Lokalization for KDE AppStream AppData files
2014-02-23 17:35 GMT+01:00 Albert Astals Cid : > El Diumenge, 23 de febrer de 2014, a les 17:04:22, Matthias Klumpp va > escriure: >> 2014-02-23 16:37 GMT+01:00 Kevin Krammer : >> > On Sunday, 2014-02-23, 16:31:37, Matthias Klumpp wrote: >> >> 2014-02-23 16:28 GMT+01:00 Kevin Krammer : >> >> > On Sunday, 2014-02-23, 16:13:46, Matthias Klumpp wrote: >> >> >> 2014-02-23 15:44 GMT+01:00 Albert Astals Cid : >> >> >> > El Divendres, 21 de febrer de 2014, a les 16:48:01, Matthias Klumpp >> >> >> > va >> >> >> > >> >> >> > escriure: >> >> >> >> 2014-02-21 2:02 GMT+01:00 Aleix Pol : >> >> >> >> > [...] >> >> >> >> >> >> >> >> I have a compromise to offer, which will be necessary anyway in a >> >> >> >> way, >> >> >> >> since to-be-localized entries in our XML files would have to be >> >> >> >> prefixed with an underscore, so merging stuff back into the >> >> >> >> original >> >> >> >> file does not work (unless we duplicate data there, which is ugly). >> >> >> >> >> >> >> >> So, new suggestion: >> >> >> >> * Project author creates file project.appdata.xml.in, containing >> >> >> >> the >> >> >> >> >> >> >> >> raw data which has to be translated. >> >> >> >> >> >> >> >> * Scripty processes that file and commits a project.appdata.xml >> >> >> >> file >> >> >> >> >> >> >> >> in the same directory where the previous one was, containing all >> >> >> >> localizations. If one is already there, the file is updated. >> >> >> >> >> >> >> >> * We simply install the localized file and keep the other one as >> >> >> >> template >> >> >> >> >> >> >> >> That solution would work, I would be happy with it and hopefully >> >> >> >> Albert as well :-) If not, please make an alternative suggestion. >> >> >> > >> >> >> > Why do you need two files instead of one file like we do for >> >> >> > .desktop >> >> >> > files? >> >> >> >> >> >> All translatable items are prefixed with an underscore, for example: >> >> >> <_p> >> >> >> >> >> >> Software allows you to find and install new applications and >> >> >> system >> >> >> extensions and remove existing installed applications. >> >> >> >> >> >> >> >> > >> >> > Which part of the chain causes this requirement? >> >> > Is the database builder looking for this to check which parts of the >> >> > document it has to check for translations? >> >> >> >> It is used as fallback if there is no translation available for the >> >> current language. If there is no localized description, the original >> >> English one is added to the database instead. >> > >> > I see. >> > If you don't mind, what was the reason for chosing this approach? Wouldn't >> > it have also been possible to fall back to the sibling without the >> > lang attribute as a base instead? >> >> Ah, I think we are talking about different things ;-) >> The process is: >> 1) Developer writes XML with some tags prefixed with an underscore > > Why? is this an intltool limitation? > >> 2) intltool scans the input-XML for stuff with an underscore, >> localizes the tag and adds both the localized tag as well as the >> original tag (without underscore!) to the output XML >> The result is a file which is localized. The underscore is just used >> in the template to select elements which are translated (because some >> aren't, for example the icon name). >> The database builder (or the AppStream data generator in that case) >> checks for the output file, not the template to generate it. > > So you plan to integrate intltool with scripty? And we're basically > accomodating the workflow to intltool limitation? Yes to the first one, to the second one I think it's actually an advantage to have the non-localized source separated from the localized result. But if you can't live with that at all, I could also look into itstool, which can handle a definition for translatable elements (which would have to be included in Scripty). -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Lokalization for KDE AppStream AppData files
2014-02-23 18:34 GMT+01:00 Albert Astals Cid : > El Diumenge, 23 de febrer de 2014, a les 18:11:14, Matthias Klumpp va > escriure: >> 2014-02-23 17:35 GMT+01:00 Albert Astals Cid : >> > El Diumenge, 23 de febrer de 2014, a les 17:04:22, Matthias Klumpp va >> > >> > escriure: >> >> 2014-02-23 16:37 GMT+01:00 Kevin Krammer : >> >> > On Sunday, 2014-02-23, 16:31:37, Matthias Klumpp wrote: >> >> >> 2014-02-23 16:28 GMT+01:00 Kevin Krammer : >> >> >> > On Sunday, 2014-02-23, 16:13:46, Matthias Klumpp wrote: >> >> >> >> 2014-02-23 15:44 GMT+01:00 Albert Astals Cid : >> >> >> >> > El Divendres, 21 de febrer de 2014, a les 16:48:01, Matthias >> >> >> >> > Klumpp >> >> >> >> > va >> >> >> >> > >> >> >> >> > escriure: >> >> >> >> >> 2014-02-21 2:02 GMT+01:00 Aleix Pol : >> >> >> >> >> > [...] >> >> >> >> >> >> >> >> >> >> I have a compromise to offer, which will be necessary anyway in >> >> >> >> >> a >> >> >> >> >> way, >> >> >> >> >> since to-be-localized entries in our XML files would have to be >> >> >> >> >> prefixed with an underscore, so merging stuff back into the >> >> >> >> >> original >> >> >> >> >> file does not work (unless we duplicate data there, which is >> >> >> >> >> ugly). >> >> >> >> >> >> >> >> >> >> So, new suggestion: >> >> >> >> >> * Project author creates file project.appdata.xml.in, >> >> >> >> >> containing >> >> >> >> >> the >> >> >> >> >> >> >> >> >> >> raw data which has to be translated. >> >> >> >> >> >> >> >> >> >> * Scripty processes that file and commits a project.appdata.xml >> >> >> >> >> file >> >> >> >> >> >> >> >> >> >> in the same directory where the previous one was, containing all >> >> >> >> >> localizations. If one is already there, the file is updated. >> >> >> >> >> >> >> >> >> >> * We simply install the localized file and keep the other one >> >> >> >> >> as >> >> >> >> >> template >> >> >> >> >> >> >> >> >> >> That solution would work, I would be happy with it and hopefully >> >> >> >> >> Albert as well :-) If not, please make an alternative >> >> >> >> >> suggestion. >> >> >> >> > >> >> >> >> > Why do you need two files instead of one file like we do for >> >> >> >> > .desktop >> >> >> >> > files? >> >> >> >> >> >> >> >> All translatable items are prefixed with an underscore, for > example: >> >> >> >> <_p> >> >> >> >> >> >> >> >> Software allows you to find and install new applications and >> >> >> >> system >> >> >> >> extensions and remove existing installed applications. >> >> >> >> >> >> >> >> >> >> >> > >> >> >> > Which part of the chain causes this requirement? >> >> >> > Is the database builder looking for this to check which parts of the >> >> >> > document it has to check for translations? >> >> >> >> >> >> It is used as fallback if there is no translation available for the >> >> >> current language. If there is no localized description, the original >> >> >> English one is added to the database instead. >> >> > >> >> > I see. >> >> > If you don't mind, what was the reason for chosing this approach? >> >> > Wouldn't >> >> > it have also been possible to fall back to the sibling without the >> >> > lang attribute as a base instead? >&g
Re: Lokalization for KDE AppStream AppData files
2014-02-23 22:01 GMT+01:00 Albert Astals Cid : > [...] > http://websvn.kde.org/trunk/l10n-kde4/scripts/ > > http://websvn.kde.org/*checkout*/trunk/l10n-kde4/scripts/notes/scripty-map.xmi > contains a 4 year old umbrello file by Chani that gives a high level overview > of how it works. > > Any question you have, just ask me. > > Also, since this is related to XML<->po extraction/merging you may want to > read http://lists.kde.org/?t=13877224546&r=1&w=2 since it seems your and > Burkhard's goals are pretty similar and we could perfectly use the same tool > here. Thanks you! Hmm, apparently itstool repeats every translated element if you execute it on an already translated file: When using join mode, it’s common to maintain a monolingual version of the file along with translations in PO files, and to build the multilingual file that gets shipped.[...] Translation units nested in other translation units are not repeated in join mode; their translated content is merged into the top-level translation unit, and that element is repeated. (http://itstool.org/documentation/basic-usage/) This is really bad... I will search for a workaround, but if there is none creating that separate file is the easiest way to go. The alternatives need the translation in the source package and/or are specific to Docbook XML. Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Lokalization for KDE AppStream AppData files
Hi again! I talked to some people, and it looks like merging the translation back into one file using existing tools is not possible. So it would be hacking a custom solution or not merge everything into one file. I don't want to write additional code if doesn't have a strong advantage. So, I would like to ask if my previous suggestion, projects create an .appdata.xml.in file and the l10n-script commits localization back as .appdata.xml into the same directory, would be an acceptable solution. I don't see disadvantages of this. Some XML-localization code exists, but that is Docbook-specific and can't easily be reused for that kind of translation (as far as I can see, it also requires l10n data to be present before the localized XML can be built) Cheers, Matthias
Re: Lokalization for KDE AppStream AppData files
2014-02-25 16:15 GMT+01:00 Thomas Lübking : > Notice that I don't care much about i18n at all (so i don't intend nor could > argue), just curious: > > > On Dienstag, 25. Februar 2014 15:13:07 CEST, Matthias Klumpp wrote: >> >> Hi again! >> I talked to some people, and it looks like merging the translation >> back into one file using existing tools is not possible. > > > From what i understood the issue is that intltool needs a _prefixed tag to > separate translatable from untranslatable elements. Yes > Would not (assuming x to be some invalid lang ID - i do not > care about i18n...) be sufficient in that regard? > Is intltool really incapable of selecting a specialized lang as translation > source? Well, it's not how that XML stuff is translated... Also, we need a translation template/fallback-tag for each localized tag, so it is absolutely a sane thing to do. There also is itstool, which resceives a definition of translatable elements in order to translate XML, which is pretty neat. However, it expects an untranslated XML-file as input and returns the tramslated version. If you give it a translated file, it duplicates tags there (which is even documented), and there seems to be no option to turn it off. All people I asked either asked why I couldn't simply store the template somewhere or why I would want to translate a translated file ;-) So, it appears there is no "standard" way to handle this case, and I see no disadvantage in having Scripty commit a trsnalted file as separate file. It's a bit... magic and people should be aware of that when they add AppData, but apart from that I don't see disadvantages. If someone writes an XML translator which does whatever needed to translate translated files, I'd be happy with that as well, but I think doing that would be a waste of time. Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Lokalization for KDE AppStream AppData files
2014-02-25 18:56 GMT+01:00 Kevin Krammer : > On Tuesday, 2014-02-25, 18:45:52, Matthias Klumpp wrote: >> 2014-02-25 16:15 GMT+01:00 Thomas Lübking : >> > Notice that I don't care much about i18n at all (so i don't intend nor >> > could argue), just curious: >> > >> > On Dienstag, 25. Februar 2014 15:13:07 CEST, Matthias Klumpp wrote: >> >> Hi again! >> >> I talked to some people, and it looks like merging the translation >> >> back into one file using existing tools is not possible. >> > >> > From what i understood the issue is that intltool needs a _prefixed tag to >> > separate translatable from untranslatable elements. >> >> Yes >> >> > Would not (assuming x to be some invalid lang ID - i do not >> > care about i18n...) be sufficient in that regard? >> > Is intltool really incapable of selecting a specialized lang as >> > translation >> > source? >> >> Well, it's not how that XML stuff is translated... Also, we need a >> translation template/fallback-tag for each localized tag, so it is >> absolutely a sane thing to do. >> There also is itstool, which resceives a definition of translatable >> elements in order to translate XML, which is pretty neat. > > So itstool at least allows the template file to be a valid file? Yes, it will be just like a not-localized AppData file :-) -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Lokalization for KDE AppStream AppData files
2014-02-25 20:38 GMT+01:00 Kevin Krammer : > On Tuesday, 2014-02-25, 20:32:49, Albert Astals Cid wrote: >> El Dimarts, 25 de febrer de 2014, a les 20:24:12, Kevin Krammer va escriure: >> > On Tuesday, 2014-02-25, 20:16:57, Albert Astals Cid wrote: >> > > El Dimarts, 25 de febrer de 2014, a les 15:13:07, Matthias Klumpp va >> > >> > escriure: >> > > > Hi again! >> > > > I talked to some people, and it looks like merging the translation >> > > > back into one file using existing tools is not possible. So it would >> > > > be hacking a custom solution or not merge everything into one file. >> > > > I don't want to write additional code if doesn't have a strong >> > > > advantage. So, I would like to ask if my previous suggestion, projects >> > > > create an .appdata.xml.in file and the l10n-script commits >> > > > localization back as .appdata.xml into the same directory, would be an >> > > > acceptable solution. >> > > >> > > And then people will go and edit the english version in .appdata.xml and >> > > the translations will get out of sync. >> > >> > script/theothertool could probably add an XML comment, something like >> > "this >> > is a generate file, do not edit, edit source file xyz instead". >> >> It could, as well as it could work on a single file, but does it do that? > > No idea, but prepending a comment sounds easy compared to the other thing :) > > And the workflow of both intltool and itstool suggest that they always > consider their output to be fully generated and not editable so they should > really have the option of writing such a warning. > Just like UIC does or MOC. Only developers should have to edit that file - translators will translate the po file which is used by itstool/intltool to translate the XML. And I consider developers to be smart enough to edit the source-file and not the generated one (print a warning somewhere might be a good idea anyway...) Itstool has a nice summary of the workflow described here: http://itstool.org/documentation/basic-usage/ -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Lokalization for KDE AppStream AppData files
2014-02-25 21:51 GMT+01:00 Kevin Krammer : > On Tuesday, 2014-02-25, 21:36:27, Albert Astals Cid wrote: >> El Dimarts, 25 de febrer de 2014, a les 21:15:36, Matthias Klumpp va > escriure: >> > 2014-02-25 20:38 GMT+01:00 Kevin Krammer : > >> > > And the workflow of both intltool and itstool suggest that they always >> > > consider their output to be fully generated and not editable so they >> > > should >> > > really have the option of writing such a warning. >> > > Just like UIC does or MOC. >> > >> > Only developers should have to edit that file - translators will >> > translate the po file which is used by itstool/intltool to translate >> > the XML. And I consider developers to be smart enough to edit the >> > source-file and not the generated one (print a warning somewhere might >> > be a good idea anyway...) >> >> You're overestimating people. >> >> > Itstool has a nice summary of the workflow described here: >> > http://itstool.org/documentation/basic-usage/ >> >> I don't care about that, we have a workflow, if your tool doesn't support >> our worflow, your tool is wrong. If that is your final statement, I will write the AppData recommendation without any translation support for KDE. There is no tool available which does what you want, and I can't take the task to write one (I also consider it useless, but that's unrelated). Having untranslated AppData is better than no AppData. > It seems the tools available from other communities with similar needs do not > match our needs closely enough. > We'll probably have to create a tool that fits our needs then. That would work, ov course :-) Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Lokalization for KDE AppStream AppData files
2014-02-25 21:49 GMT+01:00 Kevin Krammer : > On Tuesday, 2014-02-25, 21:15:36, Matthias Klumpp wrote: >> 2014-02-25 20:38 GMT+01:00 Kevin Krammer : > >> > And the workflow of both intltool and itstool suggest that they always >> > consider their output to be fully generated and not editable so they >> > should >> > really have the option of writing such a warning. >> > Just like UIC does or MOC. >> >> Only developers should have to edit that file - translators will >> translate the po file which is used by itstool/intltool to translate >> the XML. > > Well, my understanding was that nobody will edit that file. Developers would > edit the template, translators would edit po files and the tool generates the > appdata file, no? Yes, that is the workflow. The generated file would just be committed to the Git repo. >> And I consider developers to be smart enough to edit the >> source-file and not the generated one (print a warning somewhere might >> be a good idea anyway...) > > It is always good to have an additional hint. Usually tools that generate > output that is overwritten everytime the tool runs generate such a warning > header. > I had kind of assumed that intltool and itstool would do the same since their > output is, as far as my unterstanding was, not meant to be edited. > >> Itstool has a nice summary of the workflow described here: >> http://itstool.org/documentation/basic-usage/ > > It seems to recommend the "generated file" approach: > "When using join mode, it’s common to maintain a monolingual version of the > file along with translations in PO files, and to build the multilingual file > that gets shipped." Jup - I haven't found someone yet who has translation merged in the XML (and I searched for that, so we could use whatever they would use, but nobody does it, apparently). > Couldn't hurt for it to have an option to generate a warning into as well. A > lot of tools that produce such "overwrite" content do. That would be trivial - if the tool doesn't support it, we could postprocess the generated file and add it. > Anyway, prepending a comment could even be done by script that runs the tool I > guess. :-) Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Lokalization for KDE AppStream AppData files
2014-02-25 22:57 GMT+01:00 Thomas Lübking : > On Dienstag, 25. Februar 2014 22:22:36 CEST, Matthias Klumpp wrote: >> >> 2014-02-25 21:51 GMT+01:00 Kevin Krammer : >>> >>> On Tuesday, 2014-02-25, 21:36:27, Albert Astals Cid wrote: ... >> >> If that is your final statement, I will write the AppData >> recommendation without any translation support for KDE. There is no >> tool available which does what you want, and I can't take the task to >> write one (I also consider it useless, but that's unrelated). > > > Recap: > the desired action is to have > > file.xml > - > foo bar > > and turn that into > > file.xml > - > foo bar > foo bar > föö bär > le fó et la bàr > el fobarro No, it takes foo bar and turns that into foo bar foo bar föö bär le fó et la bàr el fobarro > intltool/itstool /can/ select "foo bar" as translation > source, correct? The only use or, in intltool's case every tag prefixed with an underscore, like <_p>. > It creates a .po file for the translators and can write back an xml file > (from the .po), but only /extend/ "foo bar", not merge with > existing translations - correct? If you thow in a translated file, they will duplicate the translated tag, right. > So the outstanding task would be to kick all pre-translated > elements before running the pass which writes the translated xml file? Yes, that would basically recreate the original input file :-) > That frankly sounds like an xmlstarlet one-liner... is that the problem? How would that look like? That would be really cool :-) (I never worked with xmlstarlet) >> Having untranslated AppData is better than no AppData. > > *LOL* - i'll bring that argument next time i want to introduce a visual > string in a minor release ... :-P Given that Fedora wants to kick out all apps without AppData from their software center, that might be a relevant issue ;-) Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Lokalization for KDE AppStream AppData files
2014-02-25 23:41 GMT+01:00 Thomas Lübking : > On Dienstag, 25. Februar 2014 23:20:18 CEST, Matthias Klumpp wrote: >> >> No, it takes >> foo bar >> and turns that into >> foo bar >> foo bar >> föö bär >> le fó et la bàr >> el fobarro > > > I thought, plain would *not* to be translated? > However, same procedure. They won't be translated, but will still be in the resulting XML file. > [...] > You can also select subpaths (//* globs) > $ xml ed -d "//*/div[@align!='center']/*[@lang]" /path/to/appdata.xml This looks good! Let's see if I can come up with something useful... (Scripty is a bit confusing, still) > -- OT > >> Given that Fedora wants to kick out all apps without AppData from >> their software center > > You mean I should simply stress my point with a gun? > Seriously, i'd just ignore such attempts to threaten by "we will ship a > crippled package manager that does not show your software". > It's not a very scary "threat" (they'll probably get bug reports), > inacceptable style and certainly no base to start any discussion. Well, it's not a threat. I am no Fedora guy and don't care at all about what they show or not show in their software centers. But it's a point to be aware of, and even untranslated metadata is already helpful to display applications in any software center. -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Lokalization for KDE AppStream AppData files
2014-02-26 0:14 GMT+01:00 Kevin Krammer : > On Tuesday, 2014-02-25, 23:20:18, Matthias Klumpp wrote: >> 2014-02-25 22:57 GMT+01:00 Thomas Lübking : > >> > Recap: >> > the desired action is to have >> > >> > file.xml >> > - >> > foo bar >> > >> > and turn that into >> > >> > file.xml >> > - >> > foo bar >> > foo bar >> > föö bär >> > le fó et la bàr >> > el fobarro >> >> No, it takes >> foo bar >> and turns that into >> foo bar >> foo bar >> föö bär >> le fó et la bàr >> el fobarro > > That looks fine. > Basically like for .desktop files, which also adds the translated entries > after the source entry. > >> Given that Fedora wants to kick out all apps without AppData from >> their software center, that might be a relevant issue ;-) > > My understanding was that this only impacts the GNOME software thingy. > It is not a general rule all package manager frontends on Fedora have to > follow. But I could have misunderstood something. This affects the AppStream data they are generating - if they don't ship that data, all AppStream-based software centers are affected - the SC application itself doesn't know at all where the data comes from (and that's a good thing!). However, the official recommendation is to include everything which has a .desktop-file and/or AppData file. -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Lokalization for KDE AppStream AppData files
Quick question: Should the AppData info be merged into the application's main po file, ot should it have a app_appdata extra po file (just like .desktop files)? I also can't really test the code I write (at least not working together) (the scripty sources are a bit confusing on what gets executed when and which script calls what - although the Umbrello diagram helps a lot!), so I will submit a patch to reviewboard soonish, to see if it's usable. Cheers, Matthias
AppStream Upstream Metadata: The next steps
Hi there! It has been a while simce the last AppStream metadata thread, and I have been busy upstream with adjusting the spec for future needs. But now I have some good news for you! I finally managed to create an initial draft of the metadata spec for KDE on the Techbase Wiki: http://techbase.kde.org/MetaInfo It is not yet complete and I expect some changes in future, but it would already be great if you could comment on it, so we can clarify possible problems. Especially KDE-specific guidelines would be nice (= how do we want KDE applications to be presented?) I also worked a bit on the translation side - to be honest, that stuff has been ready for quite some time, but I have problems to integrate it with Scripty (l10n-script) at the proper place, because I simply don't know to integrate it properly. Scripts is a confusing collection of scripts, and if you don't use it, it's hard to understand it. So far, I created two small bash scripts to translate AppStream upstream metadata: extract_metainfo.sh: This script generates .pot files from metadata XML files found in a project. Just cd to the directory you want the resulting pot files to be stored in, then call the script and point it at the project's source tree you want to be searched for the XML files. merge_metainfo.sh: The script merges translation back into the XML files. Simply cd to a directory which stores .mo files with the translated data and call the script with the project's source dir as first parameter. These scripts illustrate how translation of the XML can be done in KDE. I would kindly ask the l10n-script developers to take a look at it any maybe integrate it at the proper places, because they know the code way better than I do. The scripts can be found at: http://people.freedesktop.org/~mak/appstream/kde-asmetadata-l10n.tar.gz (I also included a demo XML file) I wanted to post that to Reviewboard, but couldn't find a project for Scripty. To answer a few questions before they arise: ~~~ "Why does the XML specification described at the KDE Wiki look different from what I have seen in GNOME before?" The KDE pages use the new specification described in AppStream 0.6, which has a much bigger scope than the previous specification, which was just designed for applications. GNOME started with the old application-only spec and will soon migrate to the new one. At KDE, we can start of 0.6 directly. Implementation of this is going on quickly and will soon be complete. ~~~ "I am confused about the AppStream metadata naming!" No worries, here's some information that might help: AppStream distro metadata: This metadata is shipped by distributions as substrate for software-center applications. It is a XML spec defined in AppStream, and often referred to as "AppStream data". The data is generated from AppStream upstream metadata: This is the stuff we ship in KDE. It is small XML files stored in /usr/share/appdata which describe software components shipped with the individual software package. It contains lots of metadata to present an application or component to the user. AppData: AppData is upstream metadata. Simple as that. Component: A component is the basic unit AppStream works with. A component can be an application, a font, a codec etc. Most components are things we want to show in a software-center, but it is also possible to define metadata which just helps the operating system to find missing software components in the archives in a distro-agnostic way. "Can we have a component-type for KDE specific things? For example to show Plasmoids in a software-center, or even display them as downloadable in GHNS?" Of course! If someone wants to help with defining additional components, please get in touch with me. And that's it for now :-) Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: AppStream Upstream Metadata: The next steps
2014-04-18 20:50 GMT+02:00 Burkhard Lück : > Am Freitag, 18. April 2014, 16:25:40 schrieb Matthias Klumpp: > >> These scripts illustrate how translation of the XML can be done in >> KDE. I would kindly ask the l10n-script developers to take a look at >> it any maybe integrate it at the proper places, because they know the >> code way better than I do. >> The scripts can be found at: >> http://people.freedesktop.org/~mak/appstream/kde-asmetadata-l10n.tar.gz >> (I also included a demo XML file) >> I wanted to post that to Reviewboard, but couldn't find a project for >> Scripty. > > Quoting my comment on https://git.reviewboard.kde.org/r/117609/ > > Please have a look at the recent changes in > http://websvn.kde.org/trunk/l10n-kde4/scripts/?sortby=date#dirlist > > extract-xml.sh > update_translations > fillxmlfrompo.py > > These changes are about a similar problem, ectracting strings for translation > from mimetype xml files and fill the xml files with the translations. Some of these files already existed back in the days. From what I've seen, the code takes the mime-xml, extracts interesting tag () performs some hacks so intltool likes it ( => <_comment/>) and then does similar stuff my examples do (but with intltool instead of itstool, which IMHO is mot really nice for this purpose (I love intltool otherwise!)). I also don't fully understand the need for XmlMessages.sh in the source tree... So, because of this and especially because of: # Note to developers: # there are not many comments in this code to avoid to slow down the code # So please look also in the svn log to have comments about the code I would need help from someone experienced with the l10n workflow and especially the l10n code to integrate the changes - that stuff is really hard to understand if you don't know the details and if there are zero comments explaining things[1]. The UML helps a little bit, but it still leaves lots of questions. I think with the scripts above it's trivial for someone who knows the code to call them from the appropriate places and make the necessary adjustments ;-) Cheers, Matthias [1]: Maybe long-term it would make sense to attempt a Python rewrite of this? (there are currently bits of C++, Python, Perl, Sh and Bash in this - Esp. calls like "g++ -O2 -march=nocona -o apply scripts/applycontext.cpp" in the generation code make me wonder...) -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: AppStream Upstream Metadata: The next steps
2014-04-21 21:05 GMT+02:00 Burkhard Lück : > Am Freitag, 18. April 2014, 21:11:10 schrieben Sie: >> 2014-04-18 20:50 GMT+02:00 Burkhard Lück : >> > Am Freitag, 18. April 2014, 16:25:40 schrieb Matthias Klumpp: >> >> These scripts illustrate how translation of the XML can be done in >> >> KDE. I would kindly ask the l10n-script developers to take a look at >> >> it any maybe integrate it at the proper places, because they know the >> >> code way better than I do. >> >> >> >> The scripts can be found at: >> >> http://people.freedesktop.org/~mak/appstream/kde-asmetadata-l10n.tar.gz >> >> >> >> (I also included a demo XML file) >> >> I wanted to post that to Reviewboard, but couldn't find a project for >> >> Scripty. >> > > Please use https://svn.reviewboard.kde.org/groups/l10n/ for your patch Thanks! I used KDE as project and assigned it to the l10n group. Please keep in mind that this is no complete patch and needs some integration ;-) Published as: https://svn.reviewboard.kde.org/r/7106/ Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
AppStream metadata for everyone!
Hi there! Now that we got translations for AppStream upstream metadata working (see [1] for an example), the next step is to write metadata for KDE projects. I already started with that, partially auto-generating AppStream data from our project metadata service (which unfortunately need manual intervention) I initially thought to send every new metadata through Reviewboard, in order to make it visible for the maintainers, who might want to change the project's description. However, for 160+ files just for KDE applications, without counting the frameworks now (which need more love), this simply does not scale at all. Therefore, I would like to ask for feedback on the following proposal: * We announce the availability of the new metadata somewhere, so that the individual maintainers know that the data is coming, and that they may want to take a look at it when it landed in their Git master branch. * I simply go ahead and commit the files to the respective repos. Since it's just data, it shouldn't break anything. * Others adjust the initially commited files as they wish. There is a quick reference at [2], for those who want to add more data or change something. * I'll help with any questions regarding that, of course ;-) Would something like that be okay? Cheers, Matthias [1]: https://projects.kde.org/projects/kde/kdeutils/ark/repository/revisions/master/entry/app/ark.appdata.xml [2]: http://techbase.kde.org/MetaInfo -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Compatibility problems with latest GTK+ applications
2014-05-08 9:31 GMT+02:00 Martin Gräßlin : > Martin GräßlinOn Wednesday 07 May 2014 10:11:37 wrote: >> Any advice on how to handle this situation is appreciated. > > As several people responded that I should report the issues I just did that > and reported the following bug reports against GTK: > > * CSD styled windows don't react on compositing changes [1] > * Double decorated windows [2] > * CSD styled windows do not detect when re-parented to a decoration [3] > * CSD context menu ignores _NET_ALLOWED_ACTIONS [4] > * CSD context menu doesn't use _NET_DESKTOP_NAMES [5] > * CSD context menu doesn't honor _NET_DESKTOP_LAYOUT [6] > * Shadow included in CSD window [7] > * Window "disappears" when middle clicking client side decoration [8] > * Missing maximize and minimize buttons in client side decoration [9] > * Decoration buttons do not follow custom specified layout in desktop > environment [10] > * A hung GTK application cannot be closed [11] > * Context menu on window decoration is not the one of the environment [12] > * No time based drag delay on window moving [13] > * No drag delay on window resize [14] That is pretty great, thank you for taking the time! Some of these things unfortunately are design-decisions by GNOME, which I raised in IRC discussions a while ago, and where I think the interest is pretty low for fixing them (after getting some feedback on e.g. the CSD menus). However, to support the cross-desktop efforts, the GNOME people should maybe make a few compromises (e.g. make GTK+ behave differently on other DEs), especially since GTK+ is not just for GNOME but also used by other projects. Let's see what happens :-) Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Compatibility problems with latest GTK+ applications
2014-05-09 4:55 GMT+02:00 Thiago Macieira : > Em qui 08 maio 2014, às 15:01:10, Martin Gräßlin escreveu: >> On Thursday 08 May 2014 14:39:49 Matthias Klumpp wrote: >> > 2014-05-08 9:31 GMT+02:00 Martin Gräßlin : >> > > * CSD styled windows don't react on compositing changes [1] >> > > * Double decorated windows [2] >> > > * CSD styled windows do not detect when re-parented to a decoration [3] >> > > * CSD context menu ignores _NET_ALLOWED_ACTIONS [4] >> > > * CSD context menu doesn't use _NET_DESKTOP_NAMES [5] >> > > * CSD context menu doesn't honor _NET_DESKTOP_LAYOUT [6] >> > > * Shadow included in CSD window [7] >> > > * Window "disappears" when middle clicking client side decoration [8] >> > > * Missing maximize and minimize buttons in client side decoration [9] >> > > * Decoration buttons do not follow custom specified layout in desktop >> > > environment [10] >> > > * A hung GTK application cannot be closed [11] >> > > * Context menu on window decoration is not the one of the environment >> > > [12] >> > > * No time based drag delay on window moving [13] >> > > * No drag delay on window resize [14] >> > >> > That is pretty great, thank you for taking the time! Some of these >> > things unfortunately are design-decisions by GNOME, which I raised in >> > IRC discussions a while ago, and where I think the interest is pretty >> > low for fixing them (after getting some feedback on e.g. the CSD >> > menus). >> >> which of the bug reports do you consider affected by design-decisions? I did >> not even report the mismatching cursors and the missing close button for >> dialogs and similar things. > > I'd say at least 11, 12. A design decision of any CSD is that the client > controls its closing and, therefore, if the client is hung, you can't tell it > to close. You can kill the application with kill, xkill or using a global > shortcut (Alt+F4, Ctrl+Alt+Esc, etc.) As for the context menu, it can be said > it's part of the themeing: the CSD application needs to get information from > the desktop in order to draw the proper decorations. You could say that > includes what the context menu should look like. > [...] Yes,exactly these were the matter of discussion. That "GNOME apps should never crash" for #11 is of course a nice design goal, but apps can always have unexpected issues. CTL+Q and ALT+F4 isn't exactly user-friendly. But well, at least for the GMenu stuff, there was some fallback in place before, so support for other desktops might be restored in GTK+ - I still have some hope. Cheers, Matthias
Pushing AppStream upstream metadata to KDE repositories...?
Hi there! I asked this a week ago, but just got individual replies from two people who didn't want changes made to their Git master branches currently (not an issue, we handled that via pull-requests and reviewboard). So I wrote this follow-up, which might be a bit more visible ;-) Now that we got translations for AppStream upstream metadata working (see [1] for an example), the next step is to write metadata for KDE projects. I already started with that, partially auto-generating AppStream data from our project metadata service (the generated files still need some work afterwards, but it's better than nothing) I initially thought to send every new metadata through Reviewboard, in order to make it visible for the maintainers, who might want to change the project's description. However, for 160+ files just for KDE applications, without counting the frameworks now (which need more love for their metadata, I will send every data concerning a framework over Reviewboard, if I created it), this simply does not scale at all. Therefore, I would like to ask for feedback on the following proposal: * We announce the availability of the new metadata somewhere, so that the individual maintainers know that the data is coming, and that they may want to take a look at it when it landed in their Git master branch. * I simply go ahead and commit the files to the respective repos. Since it's just data, it shouldn't break anything. * Others adjust the initially commited files as they wish. There is a quick reference at [2], for those who want to add more data or change something. * I'll help with any questions regarding that, of course ;-) - if someone doesn't want this, the project can simply opt-out before, or revert the commit (but I don't see any reason for doing that, unless if someone doesn't want the application to be found ^^). Would something like that be okay? And: What is the license of texts about applications published on KDE.org? Can I simply use a permissive license like CC0 (needed in order to mix the texts in the distribution later) for them, or is there an explicit license specified somewhere? (I wasn't able to find information about that) Cheers, Matthias [1]: https://projects.kde.org/projects/kde/kdeutils/ark/repository/revisions/master/entry/app/ark.appdata.xml [2]: http://techbase.kde.org/MetaInfo P.S: As a more general question: What makes a KDE project? Do we have some guidelines for all projects which they have to follow in order to be under the KDE umbrella, or are we more like a Github for Qt projects nowadays? In case there are guidelines, we might want to add "has AppStream metadata" to them in future (when more projects have that data). -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Pushing AppStream upstream metadata to KDE repositories...?
2014-05-10 19:12 GMT+02:00 Luigi Toscano : > Matthias Klumpp ha scritto: >> Therefore, I would like to ask for feedback on the following proposal: >> * We announce the availability of the new metadata somewhere, so that >> the individual maintainers know that the data is coming, and that they >> may want to take a look at it when it landed in their Git master >> branch. >> * I simply go ahead and commit the files to the respective repos. >> Since it's just data, it shouldn't break anything. >> * Others adjust the initially commited files as they wish. There is a >> quick reference at [2], for those who want to add more data or change >> something. >> * I'll help with any questions regarding that, of course ;-) - if >> someone doesn't want this, the project can simply opt-out before, or >> revert the commit (but I don't see any reason for doing that, unless >> if someone doesn't want the application to be found ^^). > > So, I'm just one of the many contributors, but I would say that you can start > with step1 (publish the sample files somewhere). That has already been done on my Freedesktop page, but I pushed the files to a Git repository on Github just minutes ago: https://github.com/Ximion/kde-appstream-metadata-templates These files need careful integration, which I would do for the projects (of course, any help with that is highly appreciated!) >> Would something like that be okay? >> And: What is the license of texts about applications published on >> KDE.org? Can I simply use a permissive license like CC0 (needed in >> order to mix the texts in the distribution later) for them, or is >> there an explicit license specified somewhere? (I wasn't able to find >> information about that) > http://techbase.kde.org/Policies/Licensing_Policy Of course I know that page ;-) But can I asume that this data is documentation, and therefore licensed under FDL? It's not mentioned explicitly... >> P.S: As a more general question: What makes a KDE project? Do we have >> some guidelines for all projects which they have to follow in order to >> be under the KDE umbrella, or are we more like a Github for Qt >> projects nowadays? >> In case there are guidelines, we might want to add "has AppStream >> metadata" to them in future (when more projects have that data). >> > Everything hosted on kde.org is a KDE project. More generally, a KDE project > is a project which adheres to: > http://manifesto.kde.org/ Yeah, but the Manifestor is describing shared values. It is not a technical requirement. In theory, the whole GNOME project could join KDE under these circumstances ;-) Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Pushing AppStream upstream metadata to KDE repositories...?
2014-05-10 19:16 GMT+02:00 Yuri Chornoivan : > написане Sat, 10 May 2014 20:02:20 +0300, Matthias Klumpp > : > > >> * I simply go ahead and commit the files to the respective repos. >> Since it's just data, it shouldn't break anything. > > > Hi, > > Please use spellchecker and Richard's checker for this format if you do so. Well, I am the maintainer of AppStream, so I know how that stuff should look like ;-) I also have the libappstream validator in place (validates the files, of course), including a few more tests with Richard's tools. I assume the descriptions have already been spell-checked by those who wrote them in the first place, but I will quickly scan them anyway. Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Pushing AppStream upstream metadata to KDE repositories...?
2014-05-11 1:24 GMT+02:00 Alvaro Soliverez : > Hi, > For KMyMoney, just go ahead and commit the file. We'll see the > notification and adjust if needed. > > We use GPLv2+ for all our files. Great, I'll do that in a second. Just a sidenote on why using the GPL etc. is not a good idea for metadata here: The AppStream design leads to all descriptions from all packages being bundled in one single, huge XML file on the distribution side. If some stuff is GPL'ed, the whole file becomes licensed under the GPL. If now something else is licensed under a GPL-incompatible license and also needs to be in that file, distributors can't generate it without violating a license. Using non-permissive licenses also limits the use of this metadata slightly, which is not desired. As much as I love the GPL and any copylefted license (I think it's fundamentally right to use it for any software), using it for metadata is a bad idea. So, please use a permissive license for the tag, like CC0-1.0, MIT etc. (some of these licenses are listed in the AppStream spec). Distributions will read that tag and drop metadata which they can't combine with other works based on the value set there. -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Pushing AppStream upstream metadata to KDE repositories...?
2014-05-11 14:27 GMT+02:00 Albert Astals Cid : > El Diumenge, 11 de maig de 2014, a les 01:58:17, Matthias Klumpp va escriure: >> 2014-05-11 1:24 GMT+02:00 Alvaro Soliverez : >> > Hi, >> > For KMyMoney, just go ahead and commit the file. We'll see the >> > notification and adjust if needed. >> > >> > We use GPLv2+ for all our files. >> >> Great, I'll do that in a second. >> Just a sidenote on why using the GPL etc. is not a good idea for >> metadata here: The AppStream design leads to all descriptions from all >> packages being bundled in one single, huge XML file on the >> distribution side. > > Sounds like a bad design decision in the AppStream side to me. Nope. There is no way to do it differently in an efficient way. It's basically the same every distribution does for packages, just that this is an index of applications, instead of packages. Also note that the legal issues are hypothetical at time, but companies insist to play safe on that (well, and that additional bit of legal security doesn't hurt). Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Pushing AppStream data to KDE project's master branches
Hi! A while ago I posted some information about how to add AppStream data to KDE projects, in order to make the projects visible in software-centers like Apper, Muon and GNOME-Software. I also compiled AppStream data for most KDE projects from the existing information we have on the web[1]. So far, AppStream metadata adoption has been good in KDE, but we can certainly do better! Fedora is already pulling in additional metadata from external sources (giving it an impressive 42% metadata coverage for KDE apps now), which is less than ideal (e.g. the data can't be translated - but it's still better than no data). Because adding the metadata is one of these very small things one easily forgets, and because we expect project maintainers to do additional work by looking at the XML spec and thinking about a description for their project, I plan to add AppStream data to the remaining KDE projects now. This will save the project maintainers from doing extra work to get their application visible with rich metadata in software centers. If you don't want me to add stuff to your repository, please drop me a note (private email) within the next week. We are speaking of a small bit of XML, which is placed in CMAKE_INSTALL_METAINFODIR (/usr/share/appdata) - so this is not a change which could break anything (in case you still don't like it, you can always git-revert, but in that case, it might happen that distributors make up their own metadata file). For more information about this data in KDE, take a look at this blog post: http://blog.tenstral.net/2014/05/translated-appstream-metadata-for-kde.html If you want to create your own data, you are lucky: We just updated the quickstart guide, which describes how to write the data and provides some hints on how to create better data: http://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#sect-Quickstart-DesktopApps If you have any further questions/suggestions etc., let me know! Cheers, Matthias P.S: There is now a libAppstreamQt[2] available as well (used by muon so far) for very simple access to AppStream data - if your application could benefit from the data, you might want to try it! [1]: https://github.com/Ximion/kde-appstream-metadata-templates [2]: https://gitorious.org/appstream/appstream/source/master: -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Pushing AppStream data to KDE project's master branches
2014-08-03 12:20 GMT+02:00 Alex Merry :
> On Sunday 03 August 2014 01:41:29 Matthias Klumpp wrote:
>> We are speaking of a small bit of XML, which is placed in
>> CMAKE_INSTALL_METAINFODIR (/usr/share/appdata) - so this is not a
>> change which could break anything (in case you still don't like it,
>> you can always git-revert, but in that case, it might happen that
>> distributors make up their own metadata file).
>
> Are you only planning to push these to projects that depend on extra-cmake-
> modules 5.1? Because kdelibs 4.x and e-c-m 5.0 don't define an installation
> directory for appdata.
I will use the cmake variable for those projects which already depend
on extra-cmake-modules >= 5.1
> Of course, for those projects, you can just install to
> ${SHARE_INSTALL_PREFIX}/appdata.
...and use this for projects which don't :)
Cheers,
Matthias
--
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/
Re: [kde-community] Closing the kde-core-devel mailing list
2014-08-05 20:29 GMT+02:00 Albert Astals Cid : > El Dilluns, 4 d'agost de 2014, a les 20:36:44, Vishesh Handa va escriure: >> Hello people >> >> Random Idea: How about we close the k-c-d mailing list? It's main purpose >> used to be to discuss kdelibs changes, but now since we have >> kde-frameworks, the mailing list seems less useful. We already have >> kde-devel for other generic kde stuff. > > kde-core-devel main purpose may had been discuss kdelibs changes, but it has > trascended that purspose a while ago. > > Let's see email threads that were sent here that don't belong to frameworks- > devel, please tell me what list would replace k-c-d in this regard > > * Pushing AppStream data to KDE project's master branches > * KDE Applications December 2014 release: which apps are targeting Qt4/Qt5? > * Oxygen Fonts kdereview > * Default wallpapers should go in svn or git? > * Move of KXStitch to Extragear/Graphics > * Kronometer now in KDE Review > * Move of SymbolEditor to Extragear/Graphics > * Moving plasma-nm to extragear > * Talks @Akademy > * KBibTeX in KDE Review > * Freedesktop summit 2014 > * kde-workspace split incoming! > > As you see these have nothing to do with kdelibs. Sure i understand lib > development moved to frameworks-devel, that's fine, but until you have a place > to discuss core stuff I don't see why we should close our core-devel list. I agree with this - but do we have a list where we can discuss project-wide technical changes? The kde-core-devel list so far is one of the few lists where you can reach most developers to discuss some of this "global stuff". Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Muon and kde-gtk-config moved to kde/workspace - was - Re: Moving repositories in the module structure
2014-10-06 19:57 GMT+02:00 Albert Astals Cid : > El Dilluns, 6 d'octubre de 2014, a les 01:30:47, Aleix Pol va escriure: >> [...] >> I don't expect to compete with Apper. Muon Discover is a software center >> and that's the main solution I'm pushing here, as I explained in Plasma. >> Apper is a package manager. That is, a way where we can display to our >> end-users what software there's available and also lets us a couple of >> tricks to get biased. I (as Apper contributor) would disagree with that - Daniel renamed KPackageKit to Apper years ago to stress that Apper is not about packages, but especially about applications. Unlike Muon or GNOME Software, the goal for Apper is to manage packages and apps in one UI though - and of course, Apper provides the session interface for PackageKit, which Muon does not (yet?). Does Muon work well with PackageKit on !Debian-based distros? I had lots of trouble with porting the Ubuntu Software Center to PK, since PK uses a completely different paradigm and API, compared to the Aptdaemon interface the USC used, so it would have required a complete rewrite. Last time I looked at QApt, it looked slightly more similar to Aptd compared to the PK API. (I'll soon test Muon on Fedora by myself, but more from an "what can be improved in AppStream?" PoV) >> I think this is very important, because it opens an opportunity to offer >> the end-user the full KDE experience we've been talking about. So far, the >> way everyone had to expose software was by creating a (usually spin-off) >> distribution where there was tons of software pre-installed. By providing a >> software center we open channels to communicate with the user where he can >> leverage on previous' users experience, as well as our own. > > I'm not sure I understand the difference between a "Software Center" and a > "Package Manager", can you elaborate what is the difference? Software Center almost always means that it shows GUI apps instead of packages, where "app" is more tightly defined as "stuff which ship a .desktop file in share/applictions with Type=application". Package Managers display all kinds of packages on the system, including debug symbol packages and e.g. header packages. The Software Centers are generally thought to be more end-user friendly, while package managers have a technically advanced user as target audience. Cheers, Matthias
Re: _BSD_SOURCE and _GNU_SOURCE
2014-11-14 17:36 GMT+01:00 Aleix Pol : > On Fri, Nov 14, 2014 at 4:23 PM, Milian Wolff wrote: >> >> Hello all. >> >> Since recently I get spammed by warnings such as this one: >> >> >> /ssd/milian/projects/kde4/kdelibs/kdecore/network/klocalsocket_unix.cpp:22: >> /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and >> _SVID_SOURCE >> are deprecated, use _DEFAULT_SOURCE" [-Wcpp] >> # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use >> _DEFAULT_SOURCE" >> >> Why do we defined _BSD_SOURCE or _GNU_SOURCE in FindKDE4Internal.cmake? > > It's explained in kde-modules/KDECompilerSettings.cmake: > ># Enable everything in GNU libc. Any code using non-portable features ># needs to perform feature tests, but this ensures that any such features ># will be found if they exist. > > I agree it should be revisited or something, especially if those are > deprecated now in favor of _DEFAULT_SOURCE. Only adding _GNU_SOURCE should yield the expected behaviour... Or the projects could set this individually, if they need functions exposed by it (although removing it shortly might break assumptions in some programs which rely on GNU-ish behaviour of system functions, so that would be a bad idea). Regards, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Review Request 121147: Define _DEFAULT_SOURCE together with _BSD_SOURCE.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121147/#review70519 --- Looks solid to me :-) +1 - Matthias Klumpp On Nov. 17, 2014, 3:29 nachm., Milian Wolff wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/121147/ > --- > > (Updated Nov. 17, 2014, 3:29 nachm.) > > > Review request for kdelibs, Alex Merry, Aleix Pol Gonzalez, David Faure, and > Matthias Klumpp. > > > Repository: kdelibs > > > Description > --- > > This silences the following compile warnings with newer GCC versions: > > warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" > > > Diffs > - > > cmake/modules/FindKDE4Internal.cmake > 134d14f11706f5a19a9b5e069119add2ea498dde > > Diff: https://git.reviewboard.kde.org/r/121147/diff/ > > > Testing > --- > > warnings are gone! and see also: https://ghc.haskell.org/trac/ghc/ticket/9185 > which did the same. > > > Thanks, > > Milian Wolff > >
Re: revisiting the sycoca
Hi! Am Do., 8. Feb. 2024 um 15:22 Uhr schrieb Harald Sitter : > > It occurs to me that we should ponder sycoca a bit. > > Currently the sycoca contains 3 types of caches: > > - the mime cache: should in fact be unnecessary because there is > already a mime.cache in /usr/share/mime? That cache is used by pretty much everything on Linux, including Qt itself as far as I know. I do wonder though whether there is any performance impact when the user changes/overrides a mime association and whether that is what the sycoca cache handles? Even if that is the case, there should be a much better way to deal with this. > - the menu structure cache: for the most part only loaded once by > plasmashell so the caching seems a bit questionable (caveat: kopenwith > also uses the menu structure) Hmm, we'd have to measure this, but I seriously doubt that we still need this cache, as that data is parsed super quickly - and only rarely even needs to be parsed multiple times. > - the applications desktop file cache: with most metadata having moved > to json, the desktop file caching sycoca offers seems not particularly > useful any longer as it is basically just caching > /usr/share/applications and variants thereof. In practice we have very > few apps that actually start other apps (notably plasmashell) so they > could just always hold the desktop files in memory and refresh on > inotifies. There is also a new-ish mimeinfo.cache which we can hold on > to. Indeed, using %prefix/share/applications/mimeinfo.cache should result in the most performance benefit for determining which app can support what mimetypes quickly, and I don't think the rest needs a lot of caching. The thing that benefits the most from caches by far is caching icons and rendered SVG images from themes, and that isn't handled by sycoca. > All in all I am not convinced we still need the sycoca. Indeed one > huge question is why we are holding on to a bespoke cache. If files > need caching then shouldn't we cache them on an xdg level? There is of > course also the point that nobody else seems to need them cached, > calling the sycoca yet more into question. Agreed :-) > With all that in mind... how about we deprecated the sycoca? It'd > shave some 5k lines off of kservice in the long run. I think that would make a lot of sense at this point, actually :-) Best, Matthias -- I welcome VSRE emails. See http://vsre.info/
Re: Review Request: include KolorManager in kdegraphics
Hi! Colord - just to mention that - is also not a GNOME project, it's a FreeDesktop project. (Doesn't mean it's "standard", but does mean that it's not GNOME) So everyone is free to contribute to it, and the maintainer is interested in collaborating with KDE. (which he already does very nicely) There's one thing about Oryanos I'd like to mention: I wanted to find out why Oryanos is not packaged yet on many distributions. Reasons are the strange build system it uses (looks like a custom thing to me), which makes it difficult to build it on multiple architectures. It also has dependencies like Elektra, which looks dead to the public. (But is still developed, as it's maintainer says) Oryanos requires a special version of Elektra packaged. There's also some other stuff going on which needs to be clearified before Oryanos can be shipped in distributions easily. It also has some legacy stuff, like Compiz plugins - a KWin plugin would be better for KDE, IMHO ;-) On the other hand, colord has a clean codebase, less dependencies and it "just works" for GNOME. Although I don't have experience in color management, seeing the younger project replacing the older one so fast shows me that colord at least provides enough and well-working functionality for color management on Linux. Therefore, it might be a good thing for KDE to choose it. (Maybe do some tests with it first) I also want to point you to this comparison colord against Oryanos: => http://www.freedesktop.org/software/colord/faq.html#oyranos Maybe also interesting, this comment of the Oryanos maintainer (regarding the FAQ): => http://blog.tenstral.net/2012/02/wanted-kde-color-management-kcm.html/comment-page-1#comment-48661 Kind regards, Matthias Klumpp 2012/3/14 Thomas Zander : > Quoting Kai-Uwe Behrmann : >>> >>> I'm actually targeting KDE SC 4.9 as gnome-color-manager is very mature >>> and I am >>> pretty much just rewriting it with Qt/KDE libs. >> >> >> OpenICC colour experts have then a different view of maturity. > > > Kai, > > the two projects clearly have a different set of ideas about what they > should do. Which is fine. > What is not fine is write statements like the one I quoted above, you imply > bad things about Daniel personally (his view of what is mature) which makes > this a personal attack. > > In KDE we want to focus on the facts. We talk about merit. > While its fine to give an opinion on a (technical) idea, the above is not > acceptable. > > Please respect these values we hold dear here in KDE :) > -- > Thomas Zander
Re: Review Request: include KolorManager in kdegraphics
Hi! 2012/3/14 Kai-Uwe Behrmann : > Am 14.03.12, 15:54 +0100 schrieb Matthias Klumpp: >> [...] >> I also want to point you to this comparison colord against Oryanos: >> => http://www.freedesktop.org/software/colord/faq.html#oyranos > > Matthias, you help spreading false assertions here. Then please clarify these! ;-) I find the FAQ very convincing :) I also linked your commend, so everyone can read both views (and not only colord FAQ) About Elektra: The last release is from 2008, it will definitely be difficult to convince distributors to packqage it if there's no visible upstream activity. From Richard, who contaced the Elektry guy, I know Elektra is alive, but thereÄs no sign of life ^^ Please do a similar table for Oryanos vs. colord than the colord maintainer did, so we can compare them. I guess that might be helpful even for people who don't understand color management very well. Best, Matthias 2012/3/14 Kai-Uwe Behrmann : > Am 14.03.12, 15:54 +0100 schrieb Matthias Klumpp: > >> Hi! >> Colord - just to mention that - is also not a GNOME project, it's a >> FreeDesktop project. (Doesn't mean it's "standard", but does mean that >> it's not GNOME) So everyone is free to contribute to it, and the >> maintainer is interested in collaborating with KDE. (which he already >> does very nicely) >> >> There's one thing about Oryanos I'd like to mention: I wanted to find >> out why Oryanos is not packaged yet on many distributions. Reasons are >> the strange build system it uses (looks like a custom thing to me), > > > That is correct. I would appreciate any help to get that cleared, as some > packagers mentioned it to me. One offerd already a helping hand and started > converting libXcm, which is now autotooled. Oyranos might go better > cmakified. > > >> which makes it difficult to build it on multiple architectures. It > > > Which on did not work? The recent released stack compiles on i586, xf86_64, > armv7l, osX and win32, the later being not yet very functional. > > >> also has dependencies like Elektra, which looks dead to the public. >> (But is still developed, as it's maintainer says) Oryanos requires a > > > Please Oyranos, like my nick, which is oy ;-) > > >> special version of Elektra packaged. There's also some other stuff > > > Where do you get that information from? Oyranos build fine with the last > released Elektra version. For easy of build it is included in the source tar > ball. Sorry for repeating that. > > >> going on which needs to be clearified before Oryanos can be shipped in >> distributions easily. It also has some legacy stuff, like Compiz >> plugins - a KWin plugin would be better for KDE, IMHO ;-) > > > That is a different topic. But basically I agree. It is maybe for an other > thread? > > >> On the other hand, colord has a clean codebase, less dependencies and >> it "just works" for GNOME. Although I don't have experience in color >> management, seeing the younger project replacing the older one so fast >> shows me that colord at least provides enough and well-working >> functionality for color management on Linux. >> Therefore, it might be a good thing for KDE to choose it. >> (Maybe do some tests with it first) >> >> I also want to point you to this comparison colord against Oryanos: >> => http://www.freedesktop.org/software/colord/faq.html#oyranos > > > Matthias, you help spreading false assertions here. > > >> Maybe also interesting, this comment of the Oryanos maintainer >> (regarding the FAQ): >> => >> http://blog.tenstral.net/2012/02/wanted-kde-color-management-kcm.html/comment-page-1#comment-48661 > > > http://www.oyranos.org/2012/03/kde-end-to-end-colour-management/ > >> Kind regards, >> Matthias Klumpp > > > kind regards > Kai-Uwe Behrmann > -- > developing for colour management www.behrmann.name + www.oyranos.org
Re: Review Request: include KolorManager in kdegraphics
2012/3/14 Lamarque V. Souza : > Em Wednesday 14 March 2012, Sune Vuorela escreveu: > >> On 2012-03-14, Boudewijn Rempt wrote: >> > It's easy enough to package -- the opensuse packages I use work >> > perfectly >> > fine, so I cannot imagine that there are any real and relevant problems >> > for other distributions. >> Sure it can be done. but it is just useless churn if it doesn't really >> provide anything that matters to the end user that colord doesn't. > You are talking as if colord is the default standard and well used in KDE > and then out of a suden comes oyranoes trying to replace it. Colord is not > wide used in KDE and since oyranos includes a wider feature set I guess it > is more usefull for a wider range of users. As said in other e-mails colord > is required in Gnome3, so why not add oyranos to kdegraphics since other KDE > software already work with it? Colord is also integrated with many other parts of the stack. And that Oryanos includes a wider feature-set doesn't necessarily mean it's the better choice. Which other KDE software works with Oryanos already? And btw. colord is a XDG project, not a GNOME project. Yes, it was started by a GNOME developer, but this doesn't make it a GNOME project. It is developed independent from GNOME. Regards, Matthias >> I could package oyranos and the weird things it requires. but in the >> same time I_could probably fix 20 small annoyances for all users and >> package the new nice nepomuk ioslaves. What is the best use of my time? > You devide what is the best use of your time. I still commit patches to > Kopete from time to time even though I know it is going to fade away once we > move to Qt 5 (Kopete still uses Qt3Support in several places). > > > > -- > > Lamarque V. Souza > > KDE's Network Management maintainer > > http://planetkde.org/pt-br
Re: Review Request: include KolorManager in kdegraphics
2012/3/14 Alexander Neundorf : > On Wednesday 14 March 2012, Thomas Zander wrote: >> On Wednesday 14 March 2012 18.12.13 Kai-Uwe Behrmann wrote: >> > Am 14.03.12, 17:46 +0100 schrieb Thomas Zander: >> > > On Wednesday 14 March 2012 16.39.00 Boudewijn Rempt wrote: >> > >>> Colord - just to mention that - is also not a GNOME project, it's a >> > >>> FreeDesktop project. (Doesn't mean it's "standard", but does mean >> > >>> that it's not GNOME) >> > >> >> > >> Well, no, having something on freedesktop.org doesn't mean it's not a >> > >> gnome project; >> > > >> > > Little semantic confusion here :) >> > > He said it *IS* a freedesktop project. Which means it is not a gnome >> > > project, which seems to me to be true. >> > >> > It was developed specifically for Gnome Color Manager and then turned >> > into a Glib depending library. So it bears all the specifics in it's >> > concept. >> >> Notice I still maintain that we should judge a solution on merit, not on >> who pushes it. >> >> > > That said; Cups also depends on colord. And IMO that has a bigger >> > > impact than the gnome components that pull it in. >> > >> > colord print CM: >> > CUPS does not depend in any way on colord. >> >> This opinion seems to conflict with the facts stated by others. Debian for >> instance has 'rec' (recommend) colord for cups.[1] >> Notice that colord allows components to use it without linking it in at >> startup using the dbus interface for instance. >> >> > But colord depends on CUPS to >> > support it's concept of placing colord's session centric configuration >> > into each job on server side. >> >> Which makes total technical sense. No color management system will work >> 100% without support in the individual components. If Cups needs to be >> patched to support a new feature, that sounds sane to me. >> Does it not make more sense to have color management support in cups than >> cups support in the color management software? It certainly does to me :) >> >> > It does not scale well and will likely be difficult to maintain. >> >> As someone that is also a software developer, I disagree, with the reasons >> I wrote above. :-) >> >> Bottom line for me really is that a project that has been around for a year >> has managed to grow fast and get accepted widely. >> Some may argue thats because of political issues, but in the end thats not >> really relevant. The end result is still 'market' acceptance. >> >> As mentioned before, accepting kolormanager in kdegraphics is kind of a >> "no" to colord. And I think thats would be cutting our own fingers. > > The wiki page somebody pointed to mentioned that colord is linux-only, while > oyranos also works on Windows and OSX. > > If we chose colord, how does our solution for Windows and OSX look like ? > Does kolormanager work under Windows and OSX ? Do we need a Windows/OS-X solution if both already provide their own color-management, deeply integrated into the stack? (ColorSync on OS-X and ColorManager on Win) Regards, Matthias
Re: Review Request: include KolorManager in kdegraphics
2012/3/14 Kai-Uwe Behrmann : > Am 14.03.12, 21:10 +0100 schrieb Thomas Zander: >> >> On Wednesday 14 March 2012 18.12.13 Kai-Uwe Behrmann wrote: >>> >>> Am 14.03.12, 17:46 +0100 schrieb Thomas Zander: That said; Cups also depends on colord. And IMO that has a bigger impact than the gnome components that pull it in. >>> colord print CM: >>> CUPS does not depend in any way on colord. >> >> This opinion seems to conflict with the facts stated by others. Debian >> for >> instance has 'rec' (recommend) colord for cups.[1] > > CUPS is a cross platform solution. It works with colour management on osX > fine. IMO that recommendation on Debian has to do with colord in Gnome and > that colord needs compiled in support inside CUPS. No more no less. No. Cups uses the Color Management system provided by the OS. On MacOS-X it uses ColorSync, for example. Cups itself has a patch included which makes it use colord DBus-API to talk to colord. That's the reason for CUPS recommending colord on Debian. >> Notice that colord allows components to use it without linking it in at >> startup using the dbus interface for instance. > That is non relevant to the fact, that CUPS vendor colour management works > since years and without colord. It does - on MacOS-X, because it uses ColorSync there :P Regards, Matthias >>> But colord depends on CUPS to >>> support it's concept of placing colord's session centric configuration >>> into each job on server side. >> Which makes total technical sense. No color management system will work >> 100% > > > I still do not see merit in the user session in CUPS server hook concept. > I would really like to understand why it is a good design, but no one gave > so far a satisfying answere on OpenICC. Maybe it can be found here? > > Look at the details. colord is called inside CUPS server. CUPS servers can > be remote without any DBus connection, which colord relies upon. The CUPS > server is, well, a server, not client software. It takes print jobs through > a well defined communication path after lots of security checks. Now colord > breaks these security check on a local host and says to CUPS to use a > certain ICC profiles. colord needs special rights to take the user > configuration from a central DB. As long as the actual user is printing a > actual job with a actual colord profile it is fine. Laptop and one person > systems might work this way. But imagine that now on a multi user system. A > remote print jobs comes in. CUPS prints that with the profile of the local > user. These users are likely not the same person or account. That is why the > Oyranos project did reject the offer to place a similiar Oyranos hook inside > CUPS and why it is criticised inside OpenICC without sufficient answeres. > > The colord printing configuration architecture fits maybe to a one person > system like Android, provided that it uses a direct connection to the actual > printing device. Ironically Android does not allow for DBus. > > >> without support in the individual components. If Cups needs to be patched >> to >> support a new feature, that sounds sane to me. > > > There is a half new feature. The other half cuts into existing well defined > behaviour. Colour Management for vendor configured profiles resides inside > CUPS since quite some years. The rastertoprinter filters do colour > correction through the respective poppler and ghostscript filters. The CUPS > CMS configures that fine. Again CUPS does not need colord to do robust CM. > It looses robustnes through colord introduced ambiguity. See above. > > >> Does it not make more sense to have color management support in cups than >> cups >> support in the color management software? It certainly does to me :) > > > That sentence covers only part of the conditions needed to judge. See above. > > >>> It does not scale well and will likely be difficult to maintain. >> >> As someone that is also a software developer, I disagree, with the reasons >> I >> wrote above. :-) > > > My impression is, here are made assumptions that are based on abstract > ideas, which do only in parts fit to the situation. That is irritating. > > >> Bottom line for me really is that a project that has been around for a >> year >> has managed to grow fast and get accepted widely. >> Some may argue thats because of political issues, but in the end thats not >> really relevant. The end result is still 'market' acceptance. >> >> As mentioned before, accepting kolormanager in kdegraphics is kind of a >> "no" >> to colord. And I think thats would be cutting our own fingers. > > > You are broadly speculating. May I ask for what reason? > > >> 1) http://packages.debian.org/wheezy/cups >> -- >> Thomas Zander >> > > regards > Kai-Uwe Behrmann > -- > http://www.oyranos.org
Re: Review Request: include KolorManager in kdegraphics
Speaking of project activity: => https://www.ohloh.net/p/colord => https://www.ohloh.net/p/oyranos Of course there metrics are unfair to both projects (metrics always are), but they might provide some information about activity, contributors and codebase. (although I don't think we should pay too much attention on these) 2012/3/15 Lamarque V. Souza : > Em Wednesday 14 March 2012, Daniel Nicoletti escreveu: > >> >As long as you patch cups and all other applications to use. Oyranos is > >> >also a central place > >> > > >> > to do color management as far as I know, this argument is valid for >> > both. > >> > >> It is valid once it's written, once there is a line of code doing it's >> job. > >> Or we can just play politics. You say you want the best one, have you > >> tried them both? > > > > So you are saying your original argument is not valid anymore? > > > > I said I wanted the most versatile, which means one that satisfies my needs > *and* somebody else's needs. You are completey ignoring the fact that there > are people using oyranos too, it has been developed for years, do you think > it's fair to drop all that work now? I am in favor of adding support to both > colord and oyranos in kdegraphics. One way of doing that is adding support > to colord to kolor-manager, which talks has already started. > > > > And no, I have not tested either of them and how computer color management > is supposed to work for a daltonian (like me)? Even if I had tested by what > everybody already said here, nobody is an expert in color managament to > judge the merits of either project, so let's add support to both. As I wrote > before, as long as the project has a community to maintain it, I do not see > why not use it. > > > > -- > > Lamarque V. Souza > > KDE's Network Management maintainer > > http://planetkde.org/pt-br
Re: Review Request: include KolorManager in kdegraphics
2012/3/15 Alexander Neundorf : > On Thursday 15 March 2012, Alex Fiestas wrote: > ... >> In my humble opinion we should just wait and see what of them last longer >> and healthier. > > +1 I agree with that too :) Maybe wait a few months and then check the new situation. (or rediscuss the old one if nothing has changed, but I don't believe that nothing changes ^^) Cheers, Matthias
Re: Review Request: include KolorManager in kdegraphics
2012/3/16 John Layt : > On Wednesday 14 Mar 2012 15:54:54 Matthias Klumpp wrote: >> Hi! >> Colord - just to mention that - is also not a GNOME project, it's a >> FreeDesktop project. (Doesn't mean it's "standard", but does mean that >> it's not GNOME) So everyone is free to contribute to it, and the >> maintainer is interested in collaborating with KDE. (which he already >> does very nicely) > > There is no such thing as a FreeDesktop project. FreeDesktop sets standards > like desktop files, it doesn't build or choose implementations. Just because > a project chooses to use fdo facilities does not mean it has been chosen or > blessed by fdo. There is no process for fdo to do such a thing. It is a > failing of fdo that it doesn't do so, and that it doesn't stop people form > claiming to be fdo projects when they are not. /rant > > What colord is is a Red Hat project, or more exactly a Richard Hughes project > that Red Hat has allowed him to work on and Gnome has chosen to use. Hi! >From fd.o: > freedesktop.org is not a formal standards organization, though some see a > need for one that covers some of the areas we are working on. > [...] > Unlike a standards organization, freedesktop.org is a "collaboration zone" > where ideas and code are tossed around, and de facto specifications are > encouraged. If you consider this, it's perfectly sane to call stuff which is hosted on fd.o and uses fd.o namespaces (e.g. on DBus) is a Freedesktop-project. You also need to apply for a new project first and fd.o admins can reject it. Anyway, this doesn't mean Freedeskop-Projects are standard, it just means that they're on a public "collaboration-place" between desktops like KDE and GNOME. But telling it a Richard Hughes project is describing it well too :) Kind regards, Matthias
Re: Review Request: Apper on kdereview
Hi! This issue has been fixed some time ago. Thanks for the hint! :) Matthias 2012/5/23 Albert Astals Cid : > El Dilluns, 21 de maig de 2012, a les 18:31:25, Daniel Nicoletti va escriure: >> Hi, >> Apper is on playground probably since 2008, >> it's widely used nowadays so it doesn't make >> sense to keep it there anymore. >> >> So please review the code, make suggestions and such... > > AppSetup doesn't seem to be loading the apper translation catalog. > > Albert > >> >> Right now the code is at (I've asked kde sysadmin to move to >> kdereview, but afaik it will only reflect the projects url): >> https://projects.kde.org/projects/playground/sysadmin/apper/repository >> >> Thanks :D >> >> Daniel
Re: Review Request: Apper on kdereview
Hi! @Albert: Isn't this the line? https://projects.kde.org/projects/kdereview/apper/repository/revisions/master/entry/AppSetup/main.cpp#L44 (please tell me if there's something wrong ^^) @Burkhard: The files have been moved - but I think I copied the location scheme from another project, so this issue might affect other projects too. (but I'm not completely sure... everything I've checked so far is sane) So this is done :) Please tell us if there's anything left to do! ;-) Regards, Matthias 2012/5/23 Burkhard Lück : > Am Montag, 21. Mai 2012, 23:31:25 schrieb Daniel Nicoletti: >> Hi, >> Apper is on playground probably since 2008, >> it's widely used nowadays so it doesn't make >> sense to keep it there anymore. >> >> So please review the code, make suggestions and such... >> >> Right now the code is at (I've asked kde sysadmin to move to >> kdereview, but afaik it will only reflect the projects url): >> https://projects.kde.org/projects/playground/sysadmin/apper/repository >> > Apper has two man pages, the first is in /Apper, the second is in /AppSetup. > > Both are not processed by the i18n tool chain aka scripty, but of course > should be translated. > > With the splitted git repos it is already hard enough for i18n + doc team to > catch up with documentation locations, but with non predictable directories > like in apper that would be a nightmare. > > Therefore please move both man pages to a new toplevel directory doc as in all > other git/svn repos. > > Thanks. > > -- > Burkhard Lück
Re: Review Request: Apper on kdereview
Hi!
2012/5/24 Burkhard Lück :
> Am Donnerstag, 24. Mai 2012, 17:07:20 schrieb Matthias Klumpp:
>> Hi!
>> @Albert: Isn't this the line?
>> https://projects.kde.org/projects/kdereview/apper/repository/revisions/mast
>> er/entry/AppSetup/main.cpp#L44 (please tell me if there's something wrong
>> ^^)
>>
> Afaik the insertCatalog() call is done too early and won't work.
Too early? (I thought too late :P)
> [...]
> So I'd use:
> KAboutData aboutData("appsetup-kde", "apper", ...
Changed as you suggested.
>> @Burkhard: The files have been moved - but I think I copied the
>> location scheme from another project, so this issue might affect other
>> projects too. (but I'm not completely sure... everything I've checked
>> so far is sane)
>>
> Yuri added apper/doc to scripty's workflow, man pages will be processed
> tomorrow morning.
Great!
Many thanks! :)
Re: [RFC] Merging LightDM into KDE Workspaces (forwarded from plasma-devel)
2012/8/22 Albert Astals Cid : > El Dimecres, 22 d'agost de 2012, a les 13:58:57, David Edmundson va escriure: >> As you're all probably aware I've been working on a new login manager >> for KDE [1]. Currently known as LightDM-KDE, named as it is based on >> the display manager backend LightDM [2]. > > How's the upstream of ligthdm? Have you worked with them? Do you feel it's an > upstream open to our needs? Lightdm is NOT a Canonical project, it is developed by Robert Ancell and as far as I know there's no CLA to sign. (I haven't contributed to the project yet) From the very few moments I spoke to Robert I'd say working with him is really nice and there won't be problems. Regarding the Canonical-CLA-issue: I also had my bad experiences with this, so please, please, never do anything like this in KDE (again)! But for LightDM I have no objections, +1 from me for this! (btw, I agree with Sune: One display manager is enough. But we could do a "transition phase" where both DMs are present. I'd also like to hear what KDM developers think about this.) Cheers, Matthias
Re: Plasma Workspaces 4.11: the last feature release in the 4.xseries for kde-workspace
@Kevin: I am only remotely following this issue, but as PackageKit developer, I would of course like to see our project in Plasma Workspaces as soon as possible. But I don't know the exact issues here. Also, having KSecrets merged would be a nice goal too. (The SecretService API is very stable, and has the potential to become a new de-facto XDG standard soon) So, why not work on merging all this stuff into Workspaces 5 as early as possible, so it is present there? (With having WS 4.11 frozen, it IMHO does not make any sense at all to develop new features for it, unless the new feature works on both Workspaces versions with less modifications) Cheers, Matthias
