Fwd: [ANNOUNCE] xdg-app - desktop app sandboxing system
-- Forwarded message -- Subject: [ANNOUNCE] xdg-app - desktop app sandboxing system Date: Mittwoch, 2015-06-24, 10:15:11 From: Alexander Larsson al...@redhat.com An: gnome-announce-l...@gnome.org, gnome-os-l...@gnome.org, contain...@lists.linux-foundation.org, xdg x...@lists.freedesktop.org xdg-app is a desktop and distribution-independent application bundling and system for Linux. It uses user namespaces and the kernel container technologies to run applications in a sandboxed environment without any kind of root privileges or setuid required[1]. It also features a user -space dbus filter with policies that are compatible with kdbus. xdg-app is still somewhat early in development, but it is now in a state where it is stable enough to get a wider audience. More details on how xdg-app works can be found here: https://wiki.gnome.org/Projects/SandboxedApps xdg-app recently moved to a new hosting service at freedesktop.org, so these are the current resources for xdg-app: Mailing list: http://lists.freedesktop.org/mailman/listinfo/xdg-app IRC: #xdg-app on freenode Git: git://anongit.freedesktop.org/xdg-app/xdg-app Releases: http://www.freedesktop.org/software/xdg-app/releases/ Bugzilla: https://bugs.freedesktop.org/ (product xdg-app) To actually test xdg-app I have created upstream gnome and freedesktop runtimes with some test apps, as well as an example repository with runtime and apps based on fedora rawhide packages. See these blog posts for details: https://blogs.gnome.org/alexl/2015/03/31/official-gnome-sdk-runtime-builds-are-out/ https://blogs.gnome.org/alexl/2015/06/17/testing-rawhide-apps-using-xdg-app/ [1] Needs user namespaces in the kernel, if not available it can be built to use setuid or setcaps instead. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an impetuous playboy rock star with a robot buddy named Sparky. She's a disco-crazy impetuous schoolgirl with her own daytime radio talk show. They fight crime! ___ xdg mailing list x...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg - -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Oxygen Icon usage terms
Hi all, I've just seen a question on using Oxygen icons on a forum and the poster was wondering about the status of http://www.oxygen-icons.org/ The terms in the wiki https://techbase.kde.org/Projects/Oxygen/Licensing say that one should link to the above site, but there is no content there. Anyone any idea what we can do about that? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Using Gerrit for code review in KDE
On Saturday, 2014-09-13, 17:49:31, Martin Gräßlin wrote: On Saturday 13 September 2014 16:51:15 Albert Astals Cid wrote: El Divendres, 12 de setembre de 2014, a les 22:52:40, Marco Martin va escriure: On Tuesday, September 9, 2014, Jan Kundrát j...@flaska.net wrote: If you would like all plasma to go, just give me a list of repos and I can make it happen. No, definitely not yet In my opinion, the purpose of this test is not to verify that Gerrit works or that the ACLs are set up properly -- both were done already. As part of the experiment i would also like to try to have stricter acls for +2 and submit, like starting from mantainers then slowly adding people (that's also how i understood it would have worked during the bof) I'd read that as being against the KDE Manifesto. my understanding was that it's still possible to bypass the code review, so I cannot see that it's against the KDE Manifesto as it's only a kind of social contract. Or am I missing something. That would be my interpretation as well. Also, I think our current albeit unwritten social rules or hacker ethics kind of do something similar already. I.e. if something gets committed that a maintainer does not approve of and reverts, then it stays reverted. The choice to make the maintainer's role more explicit throught the tooling is just making the decision more active than reactive. As for submit, that IMHO should at least also be available to the review request owner. Does anyone see advantages of having submit restricted at all once the necessary approval has been achieved? Cheers, Kevn -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Using Gerrit for code review in KDE
On Saturday, 2014-09-13, 20:38:21, Eike Hein wrote: These things reinforce each other in multiple ways. If main- tainers are not entrenched positions, they're easy to replace when they move on (whether they can accept this themselves or not). Once you codify them in ACLs (and yes, we do this in some places already, and I think this was a mistake as well) you add inertia because those ACLs need to be updated, and someone needs to work up the gumption to ask for that update. (Case study of what can happen when we lose track of this: We lost KDM. There are many more positive case studies where contributors kept projects alive once maintainers disappeared just by slowly ramping up their involvement, without needing hand over the keys flag days.) Hmm these are good points. I guess most people commenting so far have done so from a mostly KDE frameworks point of view, where maintainers want to be actively involved instead of having to reactively revert changes that don't fit or need more discussion. So your suggestion would be to not have +2 but a policy of some sort that only the +1 of the maintainer, if there is an active one, is considered as go ahead? If maintainers aren't entrenched, you also can't rely on them picking up the slack; hence encouraging stepping up. How do you become a maintainer? By actively doing review, for one. I.e. it's up to *maintainers* to stay active and involve themselves in the process, and provide guidance so that good code goes in and bad code stays out. The safety net we have for review working is our brains when making or picking through arguments. That sounds similar to Qt's approvers. The argument but you can still bypass Gerrit and push directly, this is just social etiquette doesn't matter because the whole thing is about social etiquette. The ACLs we already have reflect our social etiquette, and that means we need to be careful and think smart about evolving it. Personally I think social etiquette encouraging the use of review tools is fine. Social etiquette that entrenches some developers as special on those review tools is not. If I brainstorm about alternatives I find: * let maintainers have -2 as pro-active variation of reverting * build social ettiquette to always wait for the maintainer's +1 but at most for a certain grace period, e.g. one week * have everyone get +2 and use etiquette to do that only if there is already strong agreement or the grace period has passed Other? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Gerrit available for trial
Hi all, service annoucement for the people who were not so lucky as to being able to participant at this year's Akademy: Jan Kundrát, of Trojita fame, has set up a Gerrit instance [1] connected to the KDE git repository, i.e. it is now possible for KDE projects to opt in to a test of Gerrit for their review/submission workflow. It is currently used for Trojita itself and at the Frameworks BoF at Akademy we decided to also test drive this with two of our actively developed frameworks. Jan said in his Akademy talk [2] that other projects are welcome to participate in the trial so that developers can see if they like the tool and the workflows it encourages and also provide some testing for the setup as well. Participating will not make Gerrit the exclusive path for patches, it is still possible to push to KDE's git directly and/or use a reviewboard based workflow. Cheers, Kevin [1] https://gerrit.vesnicky.cesnet.cz/ [2] https://conf.kde.org/en/Akademy2014/public/events/140 -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Using Gerrit for code review in KDE
On Wednesday, 2014-09-10, 06:54:50, Ben Cooksley wrote: In regards to why we are permitting Gerrit to be evaluated - it is primarily to allow for the community to come to a decision. The complexity of the user interface among other issues are still problems which sysadmin believes could block it's overall adoption. I had hoped that independent projects, rather than Frameworks or anything along those lines would be the test subjects in this case though. Jan's invitation for testing has been brought to a wider audience during his talk at Akademy, so any of our projects is welcome to request being added to the test. The reason we selected two frameworks during the frameworks BoF is that we already have the requirement for reviews there and Gerrit provides a much nicer workflow that we really want to have at our disposal. Basically we try to achieve two goals here: - make developers working on frameworks aware of the advantages of the workflow Gerrit enables - provide active and multi-contributor projects as test cases for the setup Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Scripting/Extensions BoF at Akademy?
On Saturday, 2014-08-09, 17:34:04, Kevin Krammer wrote: Greetings all, I'd like to ask if there is any interest of having a BoF around the topic of script language based extensions for KDE applications. I've added the BoF to the timetable for Monday, but we can still easily change that if anyone can't make it then. https://community.kde.org/Akademy/2014/Monday#Room_1_-_8_September We should probably also start a wiki page for the agenda and link it from there. I can probably do that tomorrow if nobody beats me to it :) Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Scripting/Extensions BoF at Akademy?
On Saturday, 2014-08-09, 23:54:42, Christoph Cullmann wrote: On Saturday, 2014-08-09, 18:04:18, Christoph Cullmann wrote: Interesting would be, what we should use for scripting actually. KatePart still uses QtScript which is in maintainance mode, I tried to port to the the Qml/JSEngine stuff, but that was to buggy in 5.2, perhaps in 5.3 and later it is usable. I was primarly thinking about QtScript. My understanding is that despite its label it is still the primary scripting module due to QJSEngine not having all the API yet and all work regarding it being concentrated on the QML use case. But, indeed, this is a good topic as well. Actually, the Qt documentation states in the module list explicitly that QtScript shall not be used for new stuff ;=) Sure, but they might have added that prematurely. Anyway, a good thing to share experiences of. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Scripting/Extensions BoF at Akademy?
Greetings all, I'd like to ask if there is any interest of having a BoF around the topic of script language based extensions for KDE applications. Some applications already offer that, e.g. Kate, and Plasma is even designed around that idea. But currently there seems to be quite some infrastructure implemented multiple times, e.g. a require or include mechanism for QtScript. My goal for the BoF would be to see which functional blocks we have spread across KDE software, if we could identify bits that can be upstreamed and bits that would be nice in a KScriptAddon framework. One thing for the latter could be support for packages, probably based on Plasma packages, as a nice and common way of making application extensions distributable including assets and translations. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Scripting/Extensions BoF at Akademy?
On Saturday, 2014-08-09, 18:04:18, Christoph Cullmann wrote: Greetings all, I'd like to ask if there is any interest of having a BoF around the topic of script language based extensions for KDE applications. Some applications already offer that, e.g. Kate, and Plasma is even designed around that idea. But currently there seems to be quite some infrastructure implemented multiple times, e.g. a require or include mechanism for QtScript. My goal for the BoF would be to see which functional blocks we have spread across KDE software, if we could identify bits that can be upstreamed and bits that would be nice in a KScriptAddon framework. One thing for the latter could be support for packages, probably based on Plasma packages, as a nice and common way of making application extensions distributable including assets and translations. Hi, for the JS scripting in KatePart I would be interested in a BoF, for the Python stuff I have actually no clue how it works :P Neither do I but we can certainly discuss multi language support, etc as well if there is an interest by some participants. Some things like packaging is probably applicable in a very similar way. Interesting would be, what we should use for scripting actually. KatePart still uses QtScript which is in maintainance mode, I tried to port to the the Qml/JSEngine stuff, but that was to buggy in 5.2, perhaps in 5.3 and later it is usable. I was primarly thinking about QtScript. My understanding is that despite its label it is still the primary scripting module due to QJSEngine not having all the API yet and all work regarding it being concentrated on the QML use case. But, indeed, this is a good topic as well. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: [kde-community] Closing the kde-core-devel mailing list
On Tuesday, 2014-08-05, 20:29:05, Albert Astals Cid wrote: 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. I agree with Albert. k-c-d is the list to for things that happen in development, like kde-review requests, inter-module coordination, etc. It is more like a kde-community-technical list. kde-devel is more a list for question regarding developing with the KDE platform. If there is really a need to fold one list with kde-frameworks its this one. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Compatibility problems with latest GTK+ applications
On Friday, 2014-05-09, 12:44:18, John Layt wrote: On 9 May 2014 10:07, Boudewijn Rempt b...@valdyas.org wrote: And in the meantime, the GTK developers themselves have made pretty clear that GTK is for Gnome applets, not big cross-platform desktop applications: https://lwn.net/Articles/562856/. GTK+ is primarily intended to be used on the GNOME desktop, using X11 as the backend. GTK+ must focus on being the toolkit of the GNOME platform first, and tackle integration second. Thanks for that link, it explains things very nicely. Between their lack of resources and the GnomeOS philosophy it will be interesting to see how they respond to our approaches: in the article they clearly state only a mass rebellion from Gtk's users would prompt them to focus on cross-desktop/platform improvements. I can't help but wonder if the implement it without a fallback approach was partly intended to force other WMs into supporting CSD their way? Gnome is looking more and more like a walled garden these days, I really don't understand how they think that's the best way to win new users, but then I'm a pragmatist at heart. It is probably a matter of conserving resources. From their perspective the available options could be * fantastic experience on one primary platform vs * usual/acceptable experience everywhere Given a greater number of developers they might not have to chosse at all, but that's currently not the case. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Review Request 116951: Fix KDBusServiceStarter::findServiceFor() not returning error string
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116951/#review55680 --- kio/kio/kdbusservicestarter.cpp https://git.reviewboard.kde.org/r/116951/#comment38764 indentation looks wrong but maybe that's the diff interface kio/kio/kdbusservicestarter.cpp https://git.reviewboard.kde.org/r/116951/#comment38765 same here - Kevin Krammer On April 13, 2014, 10:41 p.m., David Jarvie wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116951/ --- (Updated April 13, 2014, 10:41 p.m.) Review request for kdelibs. Repository: kdelibs Description --- When KDBusServiceStarter::findServiceFor() fails to start the requested service after it is found to not be running, it does not return the error string. This patch fixes that and makes it behave as in the apidox. Diffs - kio/kio/kdbusservicestarter.cpp 90624fb Diff: https://git.reviewboard.kde.org/r/116951/diff/ Testing --- Tested this scenario, and it now returns the error string. Thanks, David Jarvie
Re: Review Request 116951: Fix KDBusServiceStarter::findServiceFor() not returning error string
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116951/#review55705 --- Looks good to me, but maybe let dfaure have a second look - Kevin Krammer On April 14, 2014, 11:48 a.m., David Jarvie wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116951/ --- (Updated April 14, 2014, 11:48 a.m.) Review request for kdelibs. Repository: kdelibs Description --- When KDBusServiceStarter::findServiceFor() fails to start the requested service after it is found to not be running, it does not return the error string. This patch fixes that and makes it behave as in the apidox. Diffs - kio/kio/kdbusservicestarter.cpp 90624fb Diff: https://git.reviewboard.kde.org/r/116951/diff/ Testing --- Tested this scenario, and it now returns the error string. Thanks, David Jarvie
Re: Configuration files transfer
On Saturday, 2014-04-12, 18:33:02, David Faure wrote:
On Saturday 12 April 2014 12:08:12 Kevin Krammer wrote:
On Saturday, 2014-04-12, 06:57:41, Ivan Čukić wrote:
+for (const auto testSubdir: { .kde, .kde5 }) {
Shouldn't that be .kde4?
Yes, already fixed in the next commit. :)
That block of code ($KDEHOME, otherwise ~/.kde, otherwise ~/.kde4)
sounds
like code that could be shared. Should we have a kde4ConfigHome() and
kde4DataHome() in, hmm, kcoreaddons?
That is why I asked the question in the first place. I'd say it would be
better to have this in a common place instead of every application
implementing it for itself.
Don't we have KStandardDirs in some porting framework?
Yes, but
1) it's in kdelibs4support, deprecated, i.e. apps are supposed to port AWAY
from it.
2) its logic has been ported away from KDEHOME and to
XDG_DATA_HOME/XDG_CONFIG_HOME etc. instead. So that a KF5-based app still
using KStandardDirs, would at least write into the right place.
So this isn't useful for migrating the KDE4 data.
I see.
Was just concered that we add KDE specific things to an otherwise independent
framework.
But I guess a single class can't be considered overhead :)
Plus it's kind of overkill since it handles many levels for many resources
while all we need is the local config and data dirs.
Right, hadn't though about that.
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
Re: Configuration files transfer
On Saturday, 2014-04-12, 06:57:41, Ivan Čukić wrote:
+for (const auto testSubdir: { .kde, .kde5 }) {
Shouldn't that be .kde4?
Yes, already fixed in the next commit. :)
That block of code ($KDEHOME, otherwise ~/.kde, otherwise ~/.kde4) sounds
like code that could be shared. Should we have a kde4ConfigHome() and
kde4DataHome() in, hmm, kcoreaddons?
That is why I asked the question in the first place. I'd say it would be
better to have this in a common place instead of every application
implementing it for itself.
Don't we have KStandardDirs in some porting framework?
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
Re: Configuration files transfer
On Friday, 2014-04-04, 18:21:31, David Faure wrote: On Friday 04 April 2014 09:42:34 Ivan Čukić wrote: Hi all, Since we have changed the location of our config files not to use .kde anymore, we will need some way of moving the old configuration files to their new locations. Should we use kconf_update for this, or is something else in the works? Kevin Krammer had thoughts on the topic - iirc along the lines of every application should take care of migrating the relevant data ? (cc'ed) I documented my look into this here (though more generalized, not just config): http://community.kde.org/Frameworks/Epics/StandardPathsMigration Application specific configs could be copied with an automated mechanism that has access to the porting aids framework and thus access to KStandardDirs. Shared configs are obivously tricky, might need some symlink approach. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Review Request 116951: Fix KDBusServiceStarter::findServiceFor() not returning error string
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116951/#review53689 --- kio/kio/kdbusservicestarter.cpp https://git.reviewboard.kde.org/r/116951/#comment37656 there is a check for error not being a null pointer in line 74, so it could pontentially be 0 here as well - Kevin Krammer On March 21, 2014, 2:39 p.m., David Jarvie wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116951/ --- (Updated March 21, 2014, 2:39 p.m.) Review request for kdelibs. Repository: kdelibs Description --- When KDBusServiceStarter::findServiceFor() fails to start the requested service after it is found to not be running, it does not return the error string. This patch fixes that and makes it behave as in the apidox. Diffs - kio/kio/kdbusservicestarter.cpp 90624fb Diff: https://git.reviewboard.kde.org/r/116951/diff/ Testing --- Tested this scenario, and it now returns the error string. Thanks, David Jarvie
Re: Review Request 116951: Fix KDBusServiceStarter::findServiceFor() not returning error string
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116951/#review53690 --- Looks good to me but maybe someone closer to KIO can confirm that - Kevin Krammer On March 21, 2014, 3:10 p.m., David Jarvie wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116951/ --- (Updated March 21, 2014, 3:10 p.m.) Review request for kdelibs. Repository: kdelibs Description --- When KDBusServiceStarter::findServiceFor() fails to start the requested service after it is found to not be running, it does not return the error string. This patch fixes that and makes it behave as in the apidox. Diffs - kio/kio/kdbusservicestarter.cpp 90624fb Diff: https://git.reviewboard.kde.org/r/116951/diff/ Testing --- Tested this scenario, and it now returns the error string. Thanks, David Jarvie
Re: Lokalization for KDE AppStream AppData files
On Wednesday, 2014-02-26, 18:54:43, Matthias Klumpp wrote: 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)? My guess (don't take my word on it, wait for Albert's reply) is that something similar to the handling of .desktop files would be preferable. The data at hand is very similar in nature and content. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Lokalization for KDE AppStream AppData files
On Tuesday, 2014-02-25, 18:45:52, Matthias Klumpp wrote: 2014-02-25 16:15 GMT+01:00 Thomas Lübking thomas.luebk...@gmail.com: 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 p lang=x (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? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Lokalization for KDE AppStream AppData files
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. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Lokalization for KDE AppStream AppData files
On Tuesday, 2014-02-25, 21:15:36, Matthias Klumpp wrote: 2014-02-25 20:38 GMT+01:00 Kevin Krammer kram...@kde.org: 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? 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. 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. Anyway, prepending a comment could even be done by script that runs the tool I guess. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Lokalization for KDE AppStream AppData files
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 kram...@kde.org: 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. 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. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Lokalization for KDE AppStream AppData files
On Tuesday, 2014-02-25, 23:20:18, Matthias Klumpp wrote: 2014-02-25 22:57 GMT+01:00 Thomas Lübking thomas.luebk...@gmail.com: Recap: the desired action is to have file.xml - p lang=xfoo bar/p and turn that into file.xml - p lang=xfoo bar/p p lang=enfoo bar/p p lang=deföö bär/p p lang=frle fó et la bàr/p p lang=esel fobarro/p No, it takes pfoo bar/p and turns that into pfoo bar/p p lang=enfoo bar/p p lang=deföö bär/p p lang=frle fó et la bàr/p p lang=esel fobarro/p 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. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Lokalization for KDE AppStream AppData files
On Sunday, 2014-02-23, 17:04:22, Matthias Klumpp wrote: 2014-02-23 16:37 GMT+01:00 Kevin Krammer kram...@kde.org: On Sunday, 2014-02-23, 16:31:37, Matthias Klumpp wrote: 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. /_p 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 p 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. Ah, I see. So that is actually not a requirement from anything in the processing chain after the files are shipped. In which case it might not be relevant for the discussion here since the tool used for extraction and merging might be able to understand the format well enought to not require such hacks. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Moving Baloo forward
On Wednesday, 2014-01-29, 00:06:11, Ingo Klöcker wrote: I don't think it makes sense to work around a social problem (uneducated users) by using an inferior and much more complex technical solution (some database instead of xattrs). IMHO the advantages of using xattrs (e.g. we get easy synchronization and backup of metadata for free) outweigh the possibility that some people might inadvertently publish private metadata. People need to be educated that they have to use their brains when they share stuff. And we need to make sharing stuff (with built-in privacy protection) as easy as possible. As you pointed out below, most sharing technologies automatically discard xattrs anyway. The only sharing option that would not that I can come up with is having a shared directory on a filesystem with xattrs support. The question for that is whether it is not the administrator responsibility to set it up without xattrs support if privacy between sharing parties is a concern. Moreover, the risk for privacy is significantly lower than with metadata that is stored in the file itself (as in your MS Word document example). In contrast to metadata stored in MS Word documents, metadata stored in xattrs will not be leaked if you share the file via mail or by uploading it to Facebook or by copying it on a (FAT32-formatted) USB-stick. Apparently, Dropbox supports xattrs, but IMHO it's Dropbox's responsibility to provide a setting to disable synchronization of file metadata. My guess would be that DropBox or any other synchronisation service only does that for sync clients, not when enabling outside access to the same data. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: kqmlgraphplugin -- a QML plugin to render beautiful and interactive graphs
On Tuesday, 2014-01-28, 11:51:06, Sebastian Gottfried wrote: Hi David, I don't want to start a naming bikeshed so if it is already too late to consider renaming, just dismiss these comments: No, that's still okay. Nothing is set in stone yet. The first thing I thought of when I read the name of the plugin is that it did graph rendering, like OGDF QML[0], and I was in desperate need for such a library a couple of months ago. I think graph is confusing for a couple of reasons: * There is already a concept of graphs associated to QML, as in QML Graph Scene (which is apparently the most common result I get from searching QML Graph) Never thought about that. * In KDE, Rocs deals with Graphs and KmPlot deals with these kinds of graphs. * There is a Qt Charts[1] thing that does something similar. So I would consider renaming this to something with plot/chart. I like charts better and would consider renaming it to kqmlchartsplugin. The QML import would be 'org.kde.charts' then. Are there any more opinions on the naming issue? If this uses QtQuick I would suggest that it be part of the name. QML is a more generic term, used for thing that can be used by a QML engine. Usually components without UI, like data sources, sensors, models, timers etc. Things that can be used outside a UI context or with any UI component set (QtQuick, Cascasdes, Widgets and so on). Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Qt 5.3 to log all debug/warning/error messages to journald on systemd systems
On Friday, 2014-01-24, 10:07:34, David Faure wrote: Kevin Krammer: kDebug uses qDebug. Yes, my mistake. I was thinking in Qt4/KDE4 term where we have runtime configurable output behavior through kdebugdialog (IIRC). Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Moving Baloo forward
On Friday, 2014-01-17, 01:47:17, Albert Astals Cid wrote: If we move now, in one year we will have had 1 year of real usage uncovering bugs and 1 year of bugfixes. If we move in one year, we will have lost that 1 year of real usage (since few people will be using it) and so in one year we will be in the same situation as we are now. Isn't there also the option to switch selected applications to Baloo now and others later, e.g. on their respective maintainers schedule? For example move KDE PIM to Baloo, which I think we have agreement on internally, and migrating our data in the process. That should not create any issues since it is unlikely that anyone was accessing our data directly through Nepomuk instead of using our APIs. That should give Baloo and its APIs a lot of testing, almost certainly improve the situtation for us (KDE PIM), but neither touch anyone else's semantic data nor interrrupt their technology stack (as a bonus move load away from their stack). There might be other examples of apps that can safely move without affecting any other current user of Nepomuk. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Coding style: block braces in switch cases
Hi all,
at KDE PIM we are cleaning up our code base from over a decade of different
coding styles. Well, we means Guy Maurel, he does all the actual work :)
We follow the kdelibs rules which in turn are close to what Qt uses IIRC.
Now we've hit a snag. There is no common rule regarding block braces in cases
of switch statements.
All example of switch statements show that the switch block braces start at
the line of the switch condition, just like with if conditions or loops.
They also show that case is aligned with switch, i.e. no intentation.
However, there seems to be no rule how to place block braces for case
statements.
I've looked around and found quite a variation:
e.g. qdatetime.cpp:
switch (...) {
case Foo: {
}
}
e.g. qrasterizer.cpp:
switch (...) {
case Foo:
{
}
}
e.g. qcommandlineparser.cpp:
switch (...) {
case Foo:
{
}
}
e.g. qlocale.cpp:
switch (...) {
case Foo: {
}
}
Any thoughts anyone?
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
Re: KClasses vs. Qt5Classes
On Tuesday, 2013-12-31, 12:42:22, Martin Graesslin wrote: On Tuesday 31 December 2013 12:15:09 David Faure wrote: QSystemTrayIcon = KNotificationItem No clue. I can't even find KNotificationItem in KF5 anywhere !?!? In fact it doesn't exist in kdelibs4 either. I think it got replaced with KStatusNotifierItem since 4.4 ? That one is still valid in KF5 (framework knotifications). I have no idea if/why it means QSystemTrayIcon is bad though. QSystemTrayIcon uses XEmbed which is bad by definition ;-) We have discussed this in the plasma team and think that the best solution would be to extend QSystemTrayIcon to use the status notifier API if available. Might need some hooks into the QPA as we probably cannot depend on D-Bus on that level. But as that doesn't exist yet, at the moment the proper suggestion should be to use KStatusNotifierItem. I faintly remember a discussion where it was deemed acceptable for QtWidgets to depend on QtDBus on Linux. But it makes more sense to do it in the QPA in any case, because this is where lots of the other plaform UI integration bits already went (native dialogs, menus, etc). Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: KMountPoint::probablySlow and cifs mount points
On Monday, 2013-11-25, 00:01:41, Mark Gaiser wrote: On Sun, Nov 24, 2013 at 10:09 PM, Albert Astals Cid aa...@kde.org wrote: Why? If you open a huge file by smb:// it'll copy it to the local file anyway, so why should not we copy it? Right. True but should it be like that? Lets take playing a movie from smb as an example. If you do that now in for example mplayer then kde will simply copy the movie to your local drive and start playing it. But should that be the case? I consider it a massive usability bug. One that isn't easy to fix. If you would mount the same share as cifs then the system thinks it's local and just plays the movie without copying. This is more likely a problem with mplayer's .desktop file. KIO usually hands over the URL when starting the program, unless the information it has about the program suggests that the program is not capable of handling the URL itself. To still be able to call the program KIO then first downloads the file and then calls the program using the temporary file as the program's argument. That is how it should be. Copying to your local system is a nasty workaround which should imho be prevented. I think it is also a difference how this is handled. I.e. if the file is downloaded first and then read locally, then there will be a significant delay between starting the open operation and content becoming available to the user. However, it might also be possible to consume received data right away and, additonally, save it to a local cache file in case the program needs to go back. Depending on cache policy that would even allow use cases like quickly opening a file again if the viewer had been closed accidentally. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: QDialog on stack+exec and dbus quit crash is no more
On Monday, 2013-11-11, 19:17:22, Albert Astals Cid wrote: El Diumenge, 10 de novembre de 2013, a les 15:45:42, Jan Kundrát va I've wasted my fair share of time on this in Trojita where we disconnect from the IMAP server upon seeing a network error. This, naturally, leads to freeing memory of some auxiliary objects, and that was a problem when these objects were stuck in e.g. a GUI prompt for password. The QPointerQDialog indeed looks like a kludge. The right way (tm) is, AFAIK, to use asynchronous state everywhere, i.e. have dialogs connected to slots of the object which triggered them. That's also the only way to do these prompts in QML, by the way. Yup, it's more code, but it's needed, IMHO. Not sure you're understanding what i say, we have an explicit check about QDialog on stack+exec that says it will crash if you dbus quit. I was under the impression that D-Bus triggered quit or D-Bus interaction in general is just one possible cause of something else triggers the parent deletion. What I'm saying is that this doesn't happen anymore and we should remove that check. You're saying that nested event loops are bad, and that's totally right, but can't see how it's related to what i said. So we have multiple checks that recommend non-stack modal dialogs and you want to get rid of one of them or all duplicates of the most generic one? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Adopting AppData in KDE?
On Wednesday, 2013-11-06, 08:40:56, Richard Hughes wrote: On 6 November 2013 03:49, T.C. Hollingsworth tchollingswo...@gmail.com wrote: If we have to do it by paragraph, having scripty merge the translations back into the original XML is going to be ugly... The reasons I chose to do it this way were mainly because most translators hate translating XML tags. And if one translator does something slightly wrong, the whole document becomes invalid. For instance, asking the translators to translate this source string: pThis is the list of features:/pulliMassive color database/li/ul If they translate this as: pThis is the list of features:/pulliMassive colour database/li/ul This fails hard when the document is installed (as in, fails to parse, and so doesn't get used). Most translators won't validate the resulting XML document before translating. In GNOME we'd ask them to translate This is the list of features: and Massive color database which is much more sane and basically impossible to get wrong. This sounds more like a problem in translator tooling, commit hooks and CI integration. Anyway, couldn't you still generate the XML with language selectors on the main elements themselves? Since you already put markup-less strings into the file, why not just add the language attribute to, e.g. desscription, and then fill the tags with content? Do you expect to support partial translations? I.e. one paragraph translated, followed by an untranslated one? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Adopting AppData in KDE?
On Wednesday, 2013-11-06, 12:55:40, Richard Hughes wrote: On 6 November 2013 08:55, Kevin Krammer kram...@kde.org wrote: Do you expect to support partial translations? I.e. one paragraph translated, followed by an untranslated one? Sure, we support that. Imagine the following paragraphs in locale C: pThis is what the color management program does:/p ulliIt's awesome/li/ul And translating that to en_GB, I only need to translate the first paragraph (color - colour). The same thing happens all the time with the other languages based on other languages, e.g. pt_BR and that kind of thing. Hmm, well the GB tranlator could just copy the string. It just looked a lot like HTML and certain things don't make the same sense in all languages, e.g. b does not necessarily apply to east asian glyphs and translators would need to be able to change that to something else. But I guess you don't have any actual markup in there, so no need to allow translators to change it. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Review Request 112880: Added KColorSchemeToken class.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112880/#review40494 --- kdeui/colors/kcolorschemetoken.h http://git.reviewboard.kde.org/r/112880/#comment29808 trailing whitespace kdeui/colors/kcolorschemetoken.h http://git.reviewboard.kde.org/r/112880/#comment29809 needs an @since version line kdeui/colors/kcolorschemetoken.h http://git.reviewboard.kde.org/r/112880/#comment29810 while not wrong, I would put it below the main description. kdeui/colors/kcolorschemetoken.cpp http://git.reviewboard.kde.org/r/112880/#comment29811 opening block brace for function body on separate line kdeui/colors/kcolorschemetoken.cpp http://git.reviewboard.kde.org/r/112880/#comment29812 I think we prefer C++ style casts over C style casts - Kevin Krammer On Sept. 22, 2013, 4:09 p.m., Denis Kuplyakov wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112880/ --- (Updated Sept. 22, 2013, 4:09 p.m.) Review request for kdelibs. Description --- It is wrapper to access KColorScheme's methods from QML code. Also added Q_GADGET to KColorScheme to enable Q_ENUMS using, to make them accessible from QML code. As it will be accepted, QML-clone of KgPopupItem will be posted for review to libkdegames, as it uses it to access KDE's color theme. More info: * search for KDE theme colors API for QML thread at kdelibs and kdegames mailinglists * NEED TO FIX: I can't include it like #include KColorSchemeToken at KReversi's code, only kcolorschemetoken.h. Maybe I've missed something? Diffs - kdeui/colors/kcolorschemetoken.cpp PRE-CREATION kdeui/colors/kcolorschemetoken.h PRE-CREATION kdeui/colors/kcolorscheme.cpp a6650ac kdeui/colors/kcolorscheme.h 17570fd kdeui/CMakeLists.txt b439e04 Diff: http://git.reviewboard.kde.org/r/112880/diff/ Testing --- I've tested it with KReversi's deniskup/gsoc2013/newdesign branch. Thanks, Denis Kuplyakov
Re: Review Request 112880: Added KColorSchemeToken class.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112880/#review40547 --- Are you sure you've uploaded a new diff? Reviewboard shows no changes between r2 and r3. As for the Camel Case include, you have to add a forwarding header in kdelibs/include - Kevin Krammer On Sept. 23, 2013, 11:55 a.m., Denis Kuplyakov wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112880/ --- (Updated Sept. 23, 2013, 11:55 a.m.) Review request for kdelibs. Description --- It is wrapper to access KColorScheme's methods from QML code. Also added Q_GADGET to KColorScheme to enable Q_ENUMS using, to make them accessible from QML code. As it will be accepted, QML-clone of KgPopupItem will be posted for review to libkdegames, as it uses it to access KDE's color theme. More info: * search for KDE theme colors API for QML thread at kdelibs and kdegames mailinglists * NEED TO FIX: I can't include it like #include KColorSchemeToken at KReversi's code, only kcolorschemetoken.h. Maybe I've missed something? Diffs - kdeui/CMakeLists.txt b439e04 kdeui/colors/kcolorscheme.h 17570fd kdeui/colors/kcolorscheme.cpp a6650ac kdeui/colors/kcolorschemetoken.h PRE-CREATION kdeui/colors/kcolorschemetoken.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112880/diff/ Testing --- I've tested it with KReversi's deniskup/gsoc2013/newdesign branch. Thanks, Denis Kuplyakov
Re: Review Request 112880: Added KColorSchemeToken class.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112880/#review40565 --- kdeui/colors/kcolorschemetoken.h http://git.reviewboard.kde.org/r/112880/#comment29882 just QObject, see below kdeui/colors/kcolorschemetoken.h http://git.reviewboard.kde.org/r/112880/#comment29881 This isn't a visible item, so you can just derive from QObject kdeui/colors/kcolorschemetoken.h http://git.reviewboard.kde.org/r/112880/#comment29883 just QObject *parent = 0 - Kevin Krammer On Sept. 23, 2013, 1:04 p.m., Denis Kuplyakov wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112880/ --- (Updated Sept. 23, 2013, 1:04 p.m.) Review request for kdelibs. Description --- It is wrapper to access KColorScheme's methods from QML code. Also added Q_GADGET to KColorScheme to enable Q_ENUMS using, to make them accessible from QML code. As it will be accepted, QML-clone of KgPopupItem will be posted for review to libkdegames, as it uses it to access KDE's color theme. More info: * search for KDE theme colors API for QML thread at kdelibs and kdegames mailinglists * NEED TO FIX: I can't include it like #include KColorSchemeToken at KReversi's code, only kcolorschemetoken.h. Maybe I've missed something? Diffs - includes/CMakeLists.txt cdf0143 includes/KColorSchemeToken PRE-CREATION kdeui/CMakeLists.txt b439e04 kdeui/colors/kcolorscheme.h 17570fd kdeui/colors/kcolorscheme.cpp a6650ac kdeui/colors/kcolorschemetoken.h PRE-CREATION kdeui/colors/kcolorschemetoken.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112880/diff/ Testing --- I've tested it with KReversi's deniskup/gsoc2013/newdesign branch. Thanks, Denis Kuplyakov
Re: Review Request 112880: Added KColorSchemeToken class.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112880/#review40571 --- looks ok to me know. Better add the frameworks review group as well - Kevin Krammer On Sept. 23, 2013, 1:51 p.m., Denis Kuplyakov wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112880/ --- (Updated Sept. 23, 2013, 1:51 p.m.) Review request for kdelibs. Description --- It is wrapper to access KColorScheme's methods from QML code. Also added Q_GADGET to KColorScheme to enable Q_ENUMS using, to make them accessible from QML code. As it will be accepted, QML-clone of KgPopupItem will be posted for review to libkdegames, as it uses it to access KDE's color theme. More info: * search for KDE theme colors API for QML thread at kdelibs and kdegames mailinglists * NEED TO FIX: I can't include it like #include KColorSchemeToken at KReversi's code, only kcolorschemetoken.h. Maybe I've missed something? Diffs - includes/CMakeLists.txt cdf0143 includes/KColorSchemeToken PRE-CREATION kdeui/CMakeLists.txt b439e04 kdeui/colors/kcolorscheme.h 17570fd kdeui/colors/kcolorscheme.cpp a6650ac kdeui/colors/kcolorschemetoken.h PRE-CREATION kdeui/colors/kcolorschemetoken.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112880/diff/ Testing --- I've tested it with KReversi's deniskup/gsoc2013/newdesign branch. Thanks, Denis Kuplyakov
Re: Review Request 112880: Added KColorSchemeToken class.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112880/#review40458 --- kdeui/colors/kcolorschemetoken.h http://git.reviewboard.kde.org/r/112880/#comment29799 a property with a setter but no NOTIFYlooks wrong to me for a QML wrapper kdeui/colors/kcolorschemetoken.h http://git.reviewboard.kde.org/r/112880/#comment29800 not get for property getters in Qt or KDE, just the propert name. see e.g. QLabel's text property kdeui/colors/kcolorschemetoken.h http://git.reviewboard.kde.org/r/112880/#comment29802 very uncommmon signal name for a QML wrapper. the resulting QML signal handler would be onOnBackgroundChange. Change signals are usually the property name followed by Changed kdeui/colors/kcolorschemetoken.h http://git.reviewboard.kde.org/r/112880/#comment29803 Public class without d-pointer? kdeui/colors/kcolorschemetoken.cpp http://git.reviewboard.kde.org/r/112880/#comment29804 is it guaranteed that the background changes when a color set is set? Couldn't the argument be the same as the current value or couldn't the background brush be the same? - Kevin Krammer On Sept. 22, 2013, 10:17 a.m., Denis Kuplyakov wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112880/ --- (Updated Sept. 22, 2013, 10:17 a.m.) Review request for kdelibs. Description --- It is wrapper to access KColorScheme's methods from QML code. Also added Q_GADGET to KColorScheme to enable Q_ENUMS using, to make them accessible from QML code. As it will be accepted, QML-clone of KgPopupItem will be posted for review to libkdegames, as it uses it to access KDE's color theme. More info: * search for KDE theme colors API for QML thread at kdelibs and kdegames mailinglists * NEED TO FIX: I can't include it like #include KColorSchemeToken at KReversi's code, only kcolorschemetoken.h. Maybe I've missed something? Diffs - kdeui/CMakeLists.txt b439e04 kdeui/colors/kcolorscheme.h 17570fd kdeui/colors/kcolorscheme.cpp a6650ac kdeui/colors/kcolorschemetoken.h PRE-CREATION kdeui/colors/kcolorschemetoken.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112880/diff/ Testing --- I've tested it with KReversi's deniskup/gsoc2013/newdesign branch. Thanks, Denis Kuplyakov
Re: KF5 kwallet, kwalletd and wallet manager questions
On Sunday, 2013-08-25, Valentin Rusu wrote: On 08/24/2013 02:32 PM, Kevin Krammer wrote: On Saturday, 2013-08-24, Albert Astals Cid wrote: El Dissabte, 24 d'agost de 2013, a les 12:31:20, Valentin Rusu va escriure: * AFAIK, frameworks should be independent and self-contained. kwallet depends on kde-runtime/kwalletd. This component should be detached from kde-runtime sources and attached inside kwallet/src/kwalletd, preserving history if possible. I can handle this task if that's OK for you (Aron, David, Kevin?) This makes sense and AFAIK is what is intended with frameworks, i.e. if a lib needs a binary, that binary and the lib should be shipped together One thing that could be put into consideration is whether the library/API would work with any SecretService implementation or require kwalletd specifically. The kwallet API is only implemented by kwalletd AFAIK. So for this API's cas, we should provide kwalletd along with it. The new secret service API, on the other hand, is likely to have several implementation. In that cas, the daemon should not be systematically tied-in. Ah, I see. I thought that the KDE client API for secret service would currently be part of that framework, but of course if it is separate than that is even better. The LXDE folks are looking into secure storage and currently seem to consider gnome-keyring as the daemon, so having a ready Qt API without runtime dependencies would certainly be of interest to them. I think that future versions of the kwallet framework will have configure options, to let packagers/users choose what to install. Right, makes sense. I was mostly concerned about the Secret Service part which I mistakingly thought was part of the kwallet framework dicussed here. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: KF5 kwallet, kwalletd and wallet manager questions
On Saturday, 2013-08-24, Albert Astals Cid wrote: El Dissabte, 24 d'agost de 2013, a les 12:31:20, Valentin Rusu va escriure: Hello, Now that frameworks splitting is almost done ;-) with some people even running KF5-based sessions on their systems, I'd like to plan kwallet porting and integration. BTW, I'd like also to announce that I agreed with Michael Leupold to take over the maintainership of KWallet and I'm now committed to do that. I also plan to add new features to kwallet, as some of you may remember from our Randa discussions. But I'll make another announcement(s) regarding these new features and ksecretsservice. Here are my questions about kwallet in KF5: * what tier will kwallet end-in? Note that kwallet.h is included only by khtml, whose tier is not yet defined * AFAIK, frameworks should be independent and self-contained. kwallet depends on kde-runtime/kwalletd. This component should be detached from kde-runtime sources and attached inside kwallet/src/kwalletd, preserving history if possible. I can handle this task if that's OK for you (Aron, David, Kevin?) This makes sense and AFAIK is what is intended with frameworks, i.e. if a lib needs a binary, that binary and the lib should be shipped together One thing that could be put into consideration is whether the library/API would work with any SecretService implementation or require kwalletd specifically. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Old compatibility feature in KTabBar causing problems.
On Tuesday, 2013-07-30, Hyperz wrote: The issue is that if the mouse moves even 1 pixel while the middle mouse button is being pressed/clicked to close a tab KTabBar doesn't emit mouseMiddleClick() and the tab doesn't get closed. Hmm, shouldn't there be something like a minimum drag distance, i.e. a threshold in pixel movement below which it is not yet considered a drag start? Do we still need such an old compatibility feature? Especially since virtually everything lets you move tabs with the left mouse button these days and middle-mouse-to-close is becoming the default. My guess would be that it is up to the application. If the applications does not want MMB drag, e.g. because it wants to use MMB for something else, then it should be able to deactivate that. Applications that do not use MMB for anything could keep it available in case their users do use it. Like having or not having pre-tab close buttons. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Review Request 110083: Make kdepim libs optional dependency for libkfbapi
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110083/#review32310 --- Ship it! Ship It! - Kevin Krammer On May 10, 2013, 10:32 a.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110083/ --- (Updated May 10, 2013, 10:32 a.m.) Review request for kdelibs and KDEPIM-Libraries. Description --- kdepim-libs are needed in the facebook library only to return user info as KABC::Addressee and note as KMime::Message, plus events use KCalCore classes. This patch makes dependency on kdepim-libs optional and disables building the event classes completely in case kdepim-libs was not found. Diffs - CMakeLists.txt 5aefdcf LibKFbAPI-KDEPIM.pc.in PRE-CREATION LibKFbAPI-KDEPIMConfig.cmake.in PRE-CREATION LibKFbAPI.pc.in af537d1 libkfbapi/CMakeLists.txt dac62bc libkfbapi/commentinfo.h e5578c7 libkfbapi/kdepim-utils.h PRE-CREATION libkfbapi/kdepim-utils.cpp PRE-CREATION libkfbapi/likeinfo.h e06052e libkfbapi/noteinfo.h 2492db1 libkfbapi/noteinfo.cpp 154593d libkfbapi/notificationinfo.h a882694 libkfbapi/userinfo.h ac22a7e libkfbapi/userinfo.cpp 26c64da libkfbapi/userinfoparser_p.h 0189a17 Diff: http://git.reviewboard.kde.org/r/110083/diff/ Testing --- Builds correctly here in both cases Thanks, Martin Klapetek
Re: Review Request 110083: Make kdepim libs optional dependency for libkfbapi
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110083/#review32015 --- libkfbapi/userinfo.h http://git.reviewboard.kde.org/r/110083/#comment23854 No, this would be global symbol. I meant as a constant of UserInfo, i.e. UserInfo::InvalidTimeZone. It is a special value returned by UserInfo::timezone(), right? - Kevin Krammer On May 4, 2013, 9:34 a.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110083/ --- (Updated May 4, 2013, 9:34 a.m.) Review request for kdelibs and KDEPIM-Libraries. Description --- kdepim-libs are needed in the facebook library only to return user info as KABC::Addressee and note as KMime::Message, plus events use KCalCore classes. This patch makes dependency on kdepim-libs optional and disables building the event classes completely in case kdepim-libs was not found. Diffs - LibKFbAPI-KDEPIMConfig.cmake.in PRE-CREATION CMakeLists.txt 5aefdcf LibKFbAPI-KDEPIM.pc.in PRE-CREATION LibKFbAPI.pc.in af537d1 libkfbapi/CMakeLists.txt dac62bc libkfbapi/commentinfo.h e5578c7 libkfbapi/kdepim-utils.h PRE-CREATION libkfbapi/kdepim-utils.cpp PRE-CREATION libkfbapi/likeinfo.h e06052e libkfbapi/noteinfo.h 2492db1 libkfbapi/noteinfo.cpp 154593d libkfbapi/notificationinfo.h a882694 libkfbapi/userinfo.h ac22a7e libkfbapi/userinfo.cpp 26c64da libkfbapi/userinfoparser_p.h 0189a17 Diff: http://git.reviewboard.kde.org/r/110083/diff/ Testing --- Builds correctly here in both cases Thanks, Martin Klapetek
Re: Review Request 110083: Make kdepim libs optional dependency for libkfbapi
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110083/#review31926 --- CMakeLists.txt http://git.reviewboard.kde.org/r/110083/#comment23805 I would change that to WITH_KDEPIMLIBS, i.e. without underscore between KDEPIM and LIBS. For me KDEPIM_LIBS suggests libraries from module kdepim, while this is about libraries from kdepimlibs libkfbapi/kdepim-utils.h http://git.reviewboard.kde.org/r/110083/#comment23806 I think you could forward declare Addressee here libkfbapi/kdepim-utils.h http://git.reviewboard.kde.org/r/110083/#comment23807 those two most likely as well libkfbapi/kdepim-utils.cpp http://git.reviewboard.kde.org/r/110083/#comment23808 how do you arrive at this value? is this documented somewhere? - Kevin Krammer On April 29, 2013, 11:18 a.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110083/ --- (Updated April 29, 2013, 11:18 a.m.) Review request for kdelibs and KDEPIM-Libraries. Description --- kdepim-libs are needed in the facebook library only to return user info as KABC::Addressee and note as KMime::Message, plus events use KCalCore classes. This patch makes dependency on kdepim-libs optional and disables building the event classes completely in case kdepim-libs was not found. Diffs - CMakeLists.txt 5aefdcf LibKFbAPI-KDEPIM.pc.in PRE-CREATION LibKFbAPI-KDEPIMConfig.cmake.in PRE-CREATION LibKFbAPI.pc.in af537d1 libkfbapi/CMakeLists.txt dac62bc libkfbapi/commentinfo.h e5578c7 libkfbapi/kdepim-utils.h PRE-CREATION libkfbapi/kdepim-utils.cpp PRE-CREATION libkfbapi/likeinfo.h e06052e libkfbapi/noteinfo.h 2492db1 libkfbapi/noteinfo.cpp 154593d libkfbapi/notificationinfo.h a882694 libkfbapi/userinfo.h ac22a7e libkfbapi/userinfo.cpp 26c64da libkfbapi/userinfoparser_p.h 0189a17 Diff: http://git.reviewboard.kde.org/r/110083/diff/ Testing --- Builds correctly here in both cases Thanks, Martin Klapetek
Re: Review Request 110083: Make kdepim libs optional dependency for libkfbapi
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110083/#review31934 --- libkfbapi/kdepim-utils.cpp http://git.reviewboard.kde.org/r/110083/#comment23813 Hmm. I see the same value being defined in userinfo.cpp so maybe it should be a public const int or enum value there and reused here? Also: what about using a negative value? - Kevin Krammer On May 3, 2013, 9:41 a.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110083/ --- (Updated May 3, 2013, 9:41 a.m.) Review request for kdelibs and KDEPIM-Libraries. Description --- kdepim-libs are needed in the facebook library only to return user info as KABC::Addressee and note as KMime::Message, plus events use KCalCore classes. This patch makes dependency on kdepim-libs optional and disables building the event classes completely in case kdepim-libs was not found. Diffs - CMakeLists.txt 5aefdcf LibKFbAPI-KDEPIM.pc.in PRE-CREATION LibKFbAPI-KDEPIMConfig.cmake.in PRE-CREATION LibKFbAPI.pc.in af537d1 libkfbapi/CMakeLists.txt dac62bc libkfbapi/commentinfo.h e5578c7 libkfbapi/kdepim-utils.h PRE-CREATION libkfbapi/kdepim-utils.cpp PRE-CREATION libkfbapi/likeinfo.h e06052e libkfbapi/noteinfo.h 2492db1 libkfbapi/noteinfo.cpp 154593d libkfbapi/notificationinfo.h a882694 libkfbapi/userinfo.h ac22a7e libkfbapi/userinfo.cpp 26c64da libkfbapi/userinfoparser_p.h 0189a17 Diff: http://git.reviewboard.kde.org/r/110083/diff/ Testing --- Builds correctly here in both cases Thanks, Martin Klapetek
Re: Review Request 110083: Make kdepim libs optional dependency for libkfbapi
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110083/#review31608 --- I am wondering if it wouldnt't make more sense to have the PIM integration as a separate lib, so that libkfbapi has a stable API and ABI at all times. - Kevin Krammer On April 26, 2013, 7:37 a.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110083/ --- (Updated April 26, 2013, 7:37 a.m.) Review request for kdelibs and KDEPIM-Libraries. Description --- kdepim-libs are needed in the facebook library only to return user info as KABC::Addressee and note as KMime::Message, plus events use KCalCore classes. This patch makes dependency on kdepim-libs optional and disables building the event classes completely in case kdepim-libs was not found. Diffs - CMakeLists.txt 5aefdcf libkfbapi/CMakeLists.txt dac62bc libkfbapi/commentinfo.h e5578c7 libkfbapi/config.h.cmake PRE-CREATION libkfbapi/likeinfo.h e06052e libkfbapi/noteinfo.h 2492db1 libkfbapi/noteinfo.cpp 154593d libkfbapi/notificationinfo.h a882694 libkfbapi/userinfo.h ac22a7e libkfbapi/userinfo.cpp 26c64da libkfbapi/userinfoparser_p.h 0189a17 Diff: http://git.reviewboard.kde.org/r/110083/diff/ Testing --- Builds correctly here in both cases Thanks, Martin Klapetek
Re: Results of the freedesktop summit
On Tuesday, 2013-04-16, David Faure wrote: 4) Defined standard for .desktop file cache This is something that I've been wanting for quite some time already: replacing the ksycoca cache with something that is updated when .desktop files are installed, without the need for directory watching or slow kbuildsycoca on login. Much like update-mime-database works. The existing tool update-desktop- database will be updated to also create this binary on-disk cache, and should be run by package post-installs (but we'll also detect the case where the cache wasn't updated, by looking at directories mtime, and we'll update it on- demand; so, unlike update-mime-database, this won't be strictly required, just a performance improvement). We designed the format of the binary cache so that it's easy to use without memory allocations (just mmap), exactly like the shared-mime-info cache. Status: Ryan is working on adding the cache generation to update-desktop- database, and on an implementation of the use of the cache. I'll look into either using the latter (he's using BSD license to make that impossible), or implementing that with Qt classes myself (as I did for the mime spec). Did you mean using a BSD license to make that possible or is there a new requirement that BSD licensed code is a no-go? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Parsing a user-entered localized datetime
Hi Denis, On Wednesday, 2013-04-10, Denis Steckelmacher wrote: to other calendar systems. Does KDE store its locale-specific settings in files that can be easily edited by translators ? Can't help you with the rest, but one example of locale specific settings are (street-)address formatting rules. You can find those files in kde-runtime/l10n, lool for config key AddressFormat in the entry.desktop files for various locales. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Accessing: www-Authenticate via kio?
On Wednesday, 2013-04-03, Àlex Fiestas wrote: Is there anyway of getting the authentication realm using kio_http ? I tried with (http/webdav and adding an user as well) KIO::get(KUrl(webdav://owncloudserver/remote.php/webdav/)); job-setUiDelegate(0); job-exec(); qDebug() job-metaData(); metada contains: charset, utf-8 content-type, application/xml referrer, request-id, responsecode, 401 ssl_in_use, FALSE Is there anyway of getting this info with kio? I'm doing this in a kded module so I really want to make it async. this info as in the metaData() result? Isn't that always there independent of whether you run exec() or retrieve it in a result slot? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: KDEReview: Nepomuk-Controller QML
On Wednesday, 2013-03-27, Jörg Ehrichs wrote: Assuming this setting is stored in some KConfig based file, wouldn't it be possible to migrate it using kconf_update? Good question. The config is saved in plasma-desktop-appletsrc and I need to add: [Containments][3][Applets][25][Configuration][Applets][36] geometry=0,0,24,24 immutability=1 plugin=nepomukcontroller-qml zvalue=0 it seems the old nepomuk controller did not save to this file instead if this program will be removed from the system it won't start. Have to explicitly start it via $ nepomukcontroller to start it here I guess which icons are shown in the system tray is a setting of the system tray applet, no? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Ot help
On Saturday, 2013-03-23, 陈翔宇 wrote: How to cancel mail list? You can unsubscribe through the list's web interface: https://mail.kde.org/mailman/listinfo/kde-core-devel Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Login for bug reporting
On Wednesday, 2013-02-06, Anders Lund wrote: Onsdag den 6. februar 2013 21:52:53 skrev Alex Fiestas: On Wednesday 06 February 2013 20:36:33 Christoph Cullmann wrote: Hi, actually, if he has taken the obstacles of installing tens of megabytes of stuff, what was the problem with creating an account? Haven't it ever happened to you that you are buying something on the interwebs or checking some stuff and when you are asked to login/register you stop? It has happened to me hundreds of times, maybe because I'm lazy. I sympathize with this user. So do I. Wouldn't it be possible to send a confirmation link for a bug reported by someone not logged in? It was definitely the process of creating an account, the developer was explicitly stating that providing an email address isn't the problem. Does the crash report dialog offer the option of creating an account? Does it store the password so that it can be automatically retrieved for further reports or when interacting with the web interface in a browser? My understanding of how bugzilla works is that it sends emails to people registered for a certain bug, so an email address would be sufficient, no? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Login for bug reporting
On Wednesday, 2013-02-06, Frank Reininghaus wrote: considering that we get lots of duplicates for any reproducible bug, my impression is actually not that there are to many obstacles in the bug reporting process. Providing any kind of contact me via email/Facebook channel will only make it worse. This wouldn't be another channel of communication, just a different way to provide the bug tracker with the usual contact information. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Login for bug reporting
On Wednesday, 2013-02-06, Myriam Schweingruber wrote: Hi all, On Wed, Feb 6, 2013 at 10:20 PM, Frank Reininghaus frank7...@googlemail.com wrote: considering that we get lots of duplicates for any reproducible bug, my impression is actually not that there are to many obstacles in the bug reporting process. Providing any kind of contact me via email/Facebook channel will only make it worse. I'm already spending a lot of time marking reports as duplicate/invalid or telling people that reporting bugs for KDE 4.8 or earlier is not quite as useful as they think. Please do not make it worse by lowering the bug reporting barriers. I fully agree with Frank here, we already get way enough useless reports, please don't lower the barrier even more. IMHO it is already very easy to report a bug in BKO, much easier actually than in other bug trackers out there, and, unless you find a miracle solution to increase the number of triagers at least 10x the current number, lowering the barrier would also mean more bogus and spam. Please don't make our work harder than it already is. This isn't a way of lowering the barrier of reporting, it is about allowing different means of providing the necessary personal information of the bug reporter. In any case, the main issue of the person was to encounter the account requirment after having gone through the process of making the crash report useful. If we don't want any further bug reports from non-account holders, we can alternatively change the order of things, e.g. check for account credentials before checking for debug symbols. I do wonder though why our wikis allow different ways of login if we seem think that only input from people with accounts on KDE infrastructure provide valueable content. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Login for bug reporting
On Thursday, 2013-02-07, Teemu Rytilahti wrote: I'm not (yet) sure how the process works for Mozilla folks, but all the crashes are reported to a centralized place and aggregated afaik, all done without logging. The bug entries in their Bugzilla are then linked (and vice-versa?) to the crash reports, see https://crash- stats.mozilla.com/products/Firefox . I met a guy from Mozilla on my flight back home from FOSDEM and his job is doing statistic analysis on their crash reports to find those that happen most often and then enter those as issues for the developers to look at. So they definitely don't add all crash reports to their bug tracker. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Login for bug reporting
On Thursday, 2013-02-07, Martin Sandsmark wrote: On Thu, Feb 07, 2013 at 11:10:35AM +0100, Kevin Krammer wrote: I met a guy from Mozilla on my flight back home from FOSDEM and his job is doing statistic analysis on their crash reports to find those that happen most often and then enter those as issues for the developers to look at. So they definitely don't add all crash reports to their bug tracker. But do they accept crashes which are not from their own builds? No idea, I was more interested in having him talk about FirefoxOS :) The only thing I remember from the initial introduction was that they get so many crash reports that they can't look at them individually but need to perform statistical analysis first. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Login for bug reporting
Hi folks, at FOSDEM I was approached by a person who asked me to relay his dissatisfaction with the requirement of having a KDE Bugzilla account to report crashes via the KDE crash handler dialog. The issue in his case was kind of made worse by having this obstacle appear too late, i.e. after he had followed the instructions to create a useful backtrace and had downloaded several tens of megabytes of debug symbols. Being a FOSS developer himself he said that he understands the need for having a communication channel with the reported, but just having an email address for that would be sufficient (e.g. Debian's bug tracker works that way). So the question is whether alternative login options [1] are something we could do or whether this is impossible in our setup or just something we don't want to do because of certain drawbacks. Cheers, Kevin [1] assuming that a KDE bugzilla login is nowadays a KDE Identity login, could we have something like on the Wikis, e.g. OpenID, or something comment sections of websites used, e.g. login via Facebook? -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Finalized proposal for changes to i18n in KF5
On Friday, 2013-01-04, Oswald Buddenhagen wrote: random ramblings: i don't like the recommendation for extracted vs. disambiguating comments (and closed-source authors will typically do the exact opposite anyway). The opposite thing as in only having comments and not caring at all about ambiguity and that it makes the translations of their software suck? If so, why should we care? We offer the options of doing it better and have recommendations based on more than a decade of large scale i18n. Is there any reason at all other than lazy programmers to even have i18n functions that are not i18nc variants (i.e. require a comment)? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Review Request: port Sonnet to QSettings
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107791/#review24025 --- I am a bit puzzled by the usage of QSettings for file I/O. My, rather limited, understanding of QSettings in Qt5 context is that is mostly the same as in Qt4 and Qt4's version is AFAIK neither capable of doing hierachical files nor immutable settings nor environment/tool-output dependent values. All of which KConfig can do and which could have been deployed (especially hierachy and immutability). Or maybe I am misunderstanding the purpose of this endeavour, i.e. is this just exploring options and not idended to be ever merged into KF5? kdeui/sonnet/configdialog.h http://git.reviewboard.kde.org/r/107791/#comment18309 explicit kdeui/sonnet/configdialog.h http://git.reviewboard.kde.org/r/107791/#comment18310 Is this method necessary anymore? There is only one constructor, right? kdeui/sonnet/configwidget.h http://git.reviewboard.kde.org/r/107791/#comment18311 explicit kdeui/sonnet/configwidget.cpp http://git.reviewboard.kde.org/r/107791/#comment18313 Probably also move into constructor? kdeui/widgets/ktextedit.cpp http://git.reviewboard.kde.org/r/107791/#comment18314 Especially since it seems to hardcode QSettings usage without any option for a KDE application to read from KConfig instead - Kevin Krammer On Dec. 27, 2012, 12:52 a.m., Martin Tobias Holmedahl Sandsmark wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107791/ --- (Updated Dec. 27, 2012, 12:52 a.m.) Review request for KDE Frameworks, kdelibs and David Faure. Description --- Ported everything away from KConfig to QSettings. I couldn't really find any users of the ::save function, so I think the source incompatible change would be worth it. Alternatively we could add a deprecated dummy function that takes in a KConfig object and just ignores it, and uses QSettings. Diffs - kdeui/sonnet/configdialog.h 7c4993b kdeui/sonnet/configdialog.cpp 625441b kdeui/sonnet/configwidget.h 023b659 kdeui/sonnet/configwidget.cpp 549d5af kdeui/sonnet/highlighter.cpp 6cbb14c kdeui/sonnet/tests/test_configdialog.cpp 4c4fd21 kdeui/widgets/ktextedit.h d0c1c4d kdeui/widgets/ktextedit.cpp 71d2a9f staging/sonnet/src/core/backgroundchecker.h f0da3a3 staging/sonnet/src/core/backgroundchecker.cpp dc05b94 staging/sonnet/src/core/globals.cpp bf4f504 staging/sonnet/src/core/loader.cpp 887aee5 staging/sonnet/src/core/settings.cpp 59cb593 staging/sonnet/src/core/settings_p.h e14bad7 staging/sonnet/src/core/speller.h 37dd82f staging/sonnet/src/core/speller.cpp f831f55 Diff: http://git.reviewboard.kde.org/r/107791/diff/ Testing --- it builds. Thanks, Martin Tobias Holmedahl Sandsmark
Re: Review Request: port Sonnet to QSettings
On Dec. 27, 2012, 10:33 a.m., Kevin Krammer wrote: I am a bit puzzled by the usage of QSettings for file I/O. My, rather limited, understanding of QSettings in Qt5 context is that is mostly the same as in Qt4 and Qt4's version is AFAIK neither capable of doing hierachical files nor immutable settings nor environment/tool-output dependent values. All of which KConfig can do and which could have been deployed (especially hierachy and immutability). Or maybe I am misunderstanding the purpose of this endeavour, i.e. is this just exploring options and not idended to be ever merged into KF5? David Faure wrote: Right, QSettings doesn't do these things (well, it does hierarchical, but only two levels -- this is the most common use case, though). But this is about simple spell-checking... why would an administrator need immutable settings, or environment variables / tool output in config keys? This is typically user preferences. Any Qt-only library would do exactly this (use QSettings internally, waiting for a better solution in Qt). Yes, someone should really work on getting a better configuration framework into Qt (e.g. splitting out windows registry stuff out of QSettings, to make QSettings INI-only, add a KConfigGroup equivalent to QSettings, and make it support multiple levels of hierarchy via QStandardPaths). Two levels are most likley the most common case because most systems do not have any system administrator. Once you have admin customization you have at least three (package, admin, user). I don't have any evidence for nor against usage of Kiosk features in regard to spell checking, I am just pointing out that the solution proposed here does have none of those. I also don't think it matters that a Qt-only library would do exactly this, a Qt-only library would not have been part of a solution that offered those option in the first place. The reuse of the filename sonnetrc suggest to me that the intention is to use the same file. A KConfig based application and a QSettings based application will behave inconsitently if using the same file. Or is this a per-application stored file? Do we assume that KDE application developers who's programs are being used in an Enterprise setup will fork the library and reimplement the config with KConfig or do we want them to use the KF5 version? The later will either require that the library does not handle config itself or at least allows applications to intercept config access or provide config that takes precendence over stored config. IMHO the most sensible case is to let the application handle config I/O, allowing it to store the config in a way that is most approriate for its usage. If that is a KConfig INI file, a simple QSetting INI file or a JSON file shouldn't really matter to an engine which only is interested in the values. - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107791/#review24025 --- On Dec. 27, 2012, 12:52 a.m., Martin Tobias Holmedahl Sandsmark wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107791/ --- (Updated Dec. 27, 2012, 12:52 a.m.) Review request for KDE Frameworks, kdelibs and David Faure. Description --- Ported everything away from KConfig to QSettings. I couldn't really find any users of the ::save function, so I think the source incompatible change would be worth it. Alternatively we could add a deprecated dummy function that takes in a KConfig object and just ignores it, and uses QSettings. Diffs - kdeui/sonnet/configdialog.h 7c4993b kdeui/sonnet/configdialog.cpp 625441b kdeui/sonnet/configwidget.h 023b659 kdeui/sonnet/configwidget.cpp 549d5af kdeui/sonnet/highlighter.cpp 6cbb14c kdeui/sonnet/tests/test_configdialog.cpp 4c4fd21 kdeui/widgets/ktextedit.h d0c1c4d kdeui/widgets/ktextedit.cpp 71d2a9f staging/sonnet/src/core/backgroundchecker.h f0da3a3 staging/sonnet/src/core/backgroundchecker.cpp dc05b94 staging/sonnet/src/core/globals.cpp bf4f504 staging/sonnet/src/core/loader.cpp 887aee5 staging/sonnet/src/core/settings.cpp 59cb593 staging/sonnet/src/core/settings_p.h e14bad7 staging/sonnet/src/core/speller.h 37dd82f staging/sonnet/src/core/speller.cpp f831f55 Diff: http://git.reviewboard.kde.org/r/107791/diff/ Testing --- it builds. Thanks, Martin Tobias Holmedahl Sandsmark
Re: Review Request: port Sonnet to QSettings
On Dec. 17, 2012, 10:38 p.m., Kevin Krammer wrote: IMHO this is wrong. Not code wise but conceptual. As far as I understand QSettings is basically deprecated, it is just not official marked as such because there is no replacement. This would be porting away from a fully functional, way more advanced and maintained settings. If the sole goal of this endavor is to remove the KConfig dependency than this ought to be done by either having an interface that can be implemented through KConfig or by passing values as QVariant maps or hashes. Oswald Buddenhagen wrote: and where exactly do you see that kconfig maintainer? ;) it's unfortunate that the chosen config class is part of the API. judging by uses, would it be reasonable to just disable that part of the API indefinitely? less drastically, would it be acceptable to pass a file name instead of a config object? that would of course incur some overhead (assuming we are passing the application's main config file). it's unfortunate that the chosen config class is part of the API. Indeed. Most likely out of convenience. Hence the idea to just replace it with a generic key/value object that doesn't do any specific form of I/O and can allowing the using application to decide on persistant storage. But if I understand you correctly you would rather go for the full solution and make those properties directly read-/writable, right? - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107791/#review23643 --- On Dec. 17, 2012, 9:15 p.m., Martin Tobias Holmedahl Sandsmark wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107791/ --- (Updated Dec. 17, 2012, 9:15 p.m.) Review request for KDE Frameworks, kdelibs and David Faure. Description --- Ported everything away from KConfig to QSettings. I couldn't really find any users of the ::save function, so I think the source incompatible change would be worth it. Alternatively we could add a deprecated dummy function that takes in a KConfig object and just ignores it, and uses QSettings. Diffs - kdeui/sonnet/configdialog.h 7c4993b kdeui/sonnet/configdialog.cpp 625441b kdeui/sonnet/configwidget.h 023b659 kdeui/sonnet/configwidget.cpp 549d5af kdeui/sonnet/highlighter.cpp 6cbb14c kdeui/widgets/ktextedit.cpp 71d2a9f staging/sonnet/src/core/backgroundchecker.h f0da3a3 staging/sonnet/src/core/backgroundchecker.cpp dc05b94 staging/sonnet/src/core/globals.cpp bf4f504 staging/sonnet/src/core/loader.cpp 887aee5 staging/sonnet/src/core/settings.cpp 59cb593 staging/sonnet/src/core/settings_p.h e14bad7 staging/sonnet/src/core/speller.h 37dd82f staging/sonnet/src/core/speller.cpp f831f55 Diff: http://git.reviewboard.kde.org/r/107791/diff/ Testing --- it builds. Thanks, Martin Tobias Holmedahl Sandsmark
Re: Review Request: port Sonnet to QSettings
On Dec. 17, 2012, 10:38 p.m., Kevin Krammer wrote: IMHO this is wrong. Not code wise but conceptual. As far as I understand QSettings is basically deprecated, it is just not official marked as such because there is no replacement. This would be porting away from a fully functional, way more advanced and maintained settings. If the sole goal of this endavor is to remove the KConfig dependency than this ought to be done by either having an interface that can be implemented through KConfig or by passing values as QVariant maps or hashes. Oswald Buddenhagen wrote: and where exactly do you see that kconfig maintainer? ;) it's unfortunate that the chosen config class is part of the API. judging by uses, would it be reasonable to just disable that part of the API indefinitely? less drastically, would it be acceptable to pass a file name instead of a config object? that would of course incur some overhead (assuming we are passing the application's main config file). Kevin Krammer wrote: it's unfortunate that the chosen config class is part of the API. Indeed. Most likely out of convenience. Hence the idea to just replace it with a generic key/value object that doesn't do any specific form of I/O and can allowing the using application to decide on persistant storage. But if I understand you correctly you would rather go for the full solution and make those properties directly read-/writable, right? Oswald Buddenhagen wrote: the idea with the file name has the advantage that it is most natural, but sort of slow, and it may actually not work - if the app uses kconfig, but sonnet uses qsettings on the same file, you may actually get garbage out of it. i'd strongly recommend not using a variant map, etc., as using it would require lots of boilerplate code. if you make it so that instantiating is nothing else than new Sonnet::ConfigDialog(new KConfigWrapper(new KConfigGroup(KGlobal::config(), Spellchecking))); it may be ok. still a bit ... weird. you could make kconfiggroup directly implement the interface, but then you'd get an asymmetry with qsettings. also, where would KMapInterface be defined? where would the qsettings wrapper live? or maybe upstream QMapInterface and make QSettings implement it, too? would it even fit the API? Martin Tobias Holmedahl Sandsmark wrote: What about not exposing any of the config storage details at all? We have the application name, that should be enough to store application specific settings. I agree with Ossi that filename would not work as you would need the same config handling facility on both sides of the API anyway. I am not sure though that he means with boilerplate code being needed. The access of the settings object right now seems to be pretty much just value lookups, potentially with default value. Something QHash::value() supports as far as I can see. Anyway, that was just an idea on how to keep the load/save behavior, I agree with Martin that Sonnet should not be exposed to storage at all, it should just work with the values it was configured with by the code using it. - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107791/#review23643 --- On Dec. 17, 2012, 9:15 p.m., Martin Tobias Holmedahl Sandsmark wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107791/ --- (Updated Dec. 17, 2012, 9:15 p.m.) Review request for KDE Frameworks, kdelibs and David Faure. Description --- Ported everything away from KConfig to QSettings. I couldn't really find any users of the ::save function, so I think the source incompatible change would be worth it. Alternatively we could add a deprecated dummy function that takes in a KConfig object and just ignores it, and uses QSettings. Diffs - kdeui/sonnet/configdialog.h 7c4993b kdeui/sonnet/configdialog.cpp 625441b kdeui/sonnet/configwidget.h 023b659 kdeui/sonnet/configwidget.cpp 549d5af kdeui/sonnet/highlighter.cpp 6cbb14c kdeui/widgets/ktextedit.cpp 71d2a9f staging/sonnet/src/core/backgroundchecker.h f0da3a3 staging/sonnet/src/core/backgroundchecker.cpp dc05b94 staging/sonnet/src/core/globals.cpp bf4f504 staging/sonnet/src/core/loader.cpp 887aee5 staging/sonnet/src/core/settings.cpp 59cb593 staging/sonnet/src/core/settings_p.h e14bad7 staging/sonnet/src/core/speller.h 37dd82f staging/sonnet/src/core/speller.cpp f831f55 Diff: http://git.reviewboard.kde.org/r/107791/diff/ Testing --- it builds. Thanks
Re: Review Request: port Sonnet to QSettings
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107791/#review23643 --- IMHO this is wrong. Not code wise but conceptual. As far as I understand QSettings is basically deprecated, it is just not official marked as such because there is no replacement. This would be porting away from a fully functional, way more advanced and maintained settings. If the sole goal of this endavor is to remove the KConfig dependency than this ought to be done by either having an interface that can be implemented through KConfig or by passing values as QVariant maps or hashes. - Kevin Krammer On Dec. 17, 2012, 9:15 p.m., Martin Tobias Holmedahl Sandsmark wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107791/ --- (Updated Dec. 17, 2012, 9:15 p.m.) Review request for KDE Frameworks, kdelibs and David Faure. Description --- Ported everything away from KConfig to QSettings. I couldn't really find any users of the ::save function, so I think the source incompatible change would be worth it. Alternatively we could add a deprecated dummy function that takes in a KConfig object and just ignores it, and uses QSettings. Diffs - kdeui/sonnet/configdialog.h 7c4993b kdeui/sonnet/configdialog.cpp 625441b kdeui/sonnet/configwidget.h 023b659 kdeui/sonnet/configwidget.cpp 549d5af kdeui/sonnet/highlighter.cpp 6cbb14c kdeui/widgets/ktextedit.cpp 71d2a9f staging/sonnet/src/core/backgroundchecker.h f0da3a3 staging/sonnet/src/core/backgroundchecker.cpp dc05b94 staging/sonnet/src/core/globals.cpp bf4f504 staging/sonnet/src/core/loader.cpp 887aee5 staging/sonnet/src/core/settings.cpp 59cb593 staging/sonnet/src/core/settings_p.h e14bad7 staging/sonnet/src/core/speller.h 37dd82f staging/sonnet/src/core/speller.cpp f831f55 Diff: http://git.reviewboard.kde.org/r/107791/diff/ Testing --- it builds. Thanks, Martin Tobias Holmedahl Sandsmark
Re: FOSDEM
On Wednesday, 2012-12-12, Pau Garcia i Quiles wrote: Guys, No frameworks talk at FOSDEM CrossDesktop DevRoom? Really? I submitted one last week. https://lists.fosdem.org/pipermail/crossdesktop-devroom/2012- December/33.html if you need more talks I have an idea for another one, just let me know. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: FOSDEM
On Wednesday, 2012-12-12, Pau Garcia i Quiles wrote: On Wed, Dec 12, 2012 at 2:28 PM, Kevin Krammer kram...@kde.org wrote: On Wednesday, 2012-12-12, Pau Garcia i Quiles wrote: Guys, No frameworks talk at FOSDEM CrossDesktop DevRoom? Really? I submitted one last week. https://lists.fosdem.org/pipermail/crossdesktop-devroom/2012- December/33.html My bad, I forgot about that. if you need more talks I have an idea for another one, just let me know. Please. The more talks, the better. There is no written rule saying one person cannot get two talks :-) Sent. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Prepping KDirModel and KFileItem for QML
Hi Mark, On Saturday, 2012-11-17, Mark wrote: So i was thinking: Why don't we just make KFileItem available in QML. It doesn't have to be a QML component, but if KFileItem where to have Q_PROPERTY lines then most of the data would already be possible to make available. I did this in my code and it works rather nice though i inherited KFileItem as FileItem. It's a header only class [3]. It might not be necessary to subclass KFileItem (unless you need access to protected API), a QObject class holding a KFileItem might do as well. The latter obviously having the advantage that the contained KFI instance's setters are not exposed, thus guaranteeing that all changes must go through the QML adaptor's setters, thus making sure proper change notification signals being emitted. What i want to do is discuss these changes that Marco and I have made and merge them back in kdelibs 4.10 branch in KDirModel and KFileItem. I believe that the 4.10 branch of all modules is frozen at this point. Then KDirModel (not KFileItem) still has to be made available in QML. I want to do that in either org.kde.plasma.core or introduce a new import for kdelibs components and name that: org.kde.libs or something along those lines. The latter one has my preference since it really doesn't belong in plasma. I agree. I think we need to come up with a scheme and policy on how to handle QML bindings across our modules in a consistent way. should be a settable property. Perhaps with a default value. Last thing is what about the properties of KFileItem that are not directly exposable to QML. Non exposable functions: - ACL() (due to KACL not being available in QML) - assign(KFileItem) (possible, but would we want that?) - cmp(KFileItem) (possible, but would we want that?) - determineMimeType() (due to return type not being available in QML) - entry() (due to return type not being available in QML) - extraData() (ehh..?) - ... and a bunch of others. Some of those, e.g. extraData(), are marked as deprecated, so it wouldn't make any sense anyway to expose them in new binding API. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Prepping KDirModel and KFileItem for QML
On Saturday, 2012-11-17, Mark wrote: On Sat, Nov 17, 2012 at 4:40 PM, Kevin Krammer kram...@kde.org wrote: Hi Mark, On Saturday, 2012-11-17, Mark wrote: So i was thinking: Why don't we just make KFileItem available in QML. It doesn't have to be a QML component, but if KFileItem where to have Q_PROPERTY lines then most of the data would already be possible to make available. I did this in my code and it works rather nice though i inherited KFileItem as FileItem. It's a header only class [3]. It might not be necessary to subclass KFileItem (unless you need access to protected API), a QObject class holding a KFileItem might do as well. Well, i made a subclass because there are not much other ways to do the same outside of kdelibs. The intention is obviously to merge my changes back in KFileItem and not subclass it there. Merging the changes as in adding Q_PROPERTY to KFileItem is not possible due to KFileItem not being a QObject and Q_PROPERTY requiring a QObject subclass. The latter obviously having the advantage that the contained KFI instance's setters are not exposed, thus guaranteeing that all changes must go through the QML adaptor's setters, thus making sure proper change notification signals being emitted. What i want to do is discuss these changes that Marco and I have made and merge them back in kdelibs 4.10 branch in KDirModel and KFileItem. I believe that the 4.10 branch of all modules is frozen at this point. That's oke. I don't expect this to be done today or this week. Just sometime when 4.10 is open would be fine imho. You probably meant 4.11 Then KDirModel (not KFileItem) still has to be made available in QML. I want to do that in either org.kde.plasma.core or introduce a new import for kdelibs components and name that: org.kde.libs or something along those lines. The latter one has my preference since it really doesn't belong in plasma. I agree. I think we need to come up with a scheme and policy on how to handle QML bindings across our modules in a consistent way. org.kde.libs sounds very sensible to me :) At least for kdelibs functionality that is exposed to QML. Actually I would go for a more fine grained namespacing, after all we are trying to move aware from libs as a single entity with the KDE Frameworks 5 effort. Since both classes discussed here are in kdelibs/kio, maybe something more along the lines of org.kde.kio Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: KIO::ListJob::entries emits twice for folders with 100+ entries. Why?
On Thursday, 2012-11-15, Mark wrote: Also, funny that you mention dolphin. Since dolphin can't possibly make use of this. Dolphin is sorting the entries thus needs all of them to be in before it can even sort. And even if dolphin receives two entries signals (which is the itemsAdded signal from KDirModel) then it certainly won't speed things up, but rather slow things down because it would have to do sorting twice. Once on a small set of data (relatively fast) and once on the full set of data (dog slow). A bit off topic but: It doesn't need the full set for sorting the first patch and it doesn't have to sort the full set when the new entries come in. It could either insert the new items into the sorted first patch or sort the second patch and then perform the merge step of a merge sort algorithm. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: KDEREVIEW: share like connect and plasmate
On Saturday, 2012-11-03, Pino Toscano wrote: - RemoteInstaller uses /var/tmp/plasmaremoteinstaller/ as destination directory, which is a bit too generic (at least appending the user name and chmod'ing it 600 would help); also there is a race between the KIO exists and the mkdir calls I guess KStandardDirs could handle that, using resource type tmp Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: what I am missing for kdeclative
Hi Guy, On Friday, 2012-11-02, guy-kde wrote: Hello again! Using https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/ entry/experimental/libkdeclarative/kdeclarative.h I think kdelibs/master is currently unused (not updated). Try branch KDE/4.10 Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: what I am missing for kdeclative
On Friday, 2012-11-02, guy-kde wrote: Hi Kevin! On Fri, 2 Nov 2012 19:07:08 +0100, Kevin Krammer kram...@kde.org wrote: Hi Guy, On Friday, 2012-11-02, guy-kde wrote: Hello again! Using https://projects.kde.org/projects/kde/kdelibs/repository/revisions/maste r/ entry/experimental/libkdeclarative/kdeclarative.h I think kdelibs/master is currently unused (not updated). Try branch KDE/4.10 I am not fit with git options! Can you give me the whole command? Or how to tell it to kdesrc-build. Thanks You basically just switch to a branch like this (after clone) git checkout KDE/4.10 For kdesrc-build look into .kdesrc-buildrc find module kdelibs and change its branch line to branch KDE/4.10 Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Moving libkfacebook to extragear
On Monday, 2012-10-29, Martin Klapetek wrote: On Sun, Oct 28, 2012 at 8:03 PM, Kevin Krammer kram...@kde.org wrote: This is for the parsing purposes - the library uses QJson parser/mapper, which automagically maps the received json data to qobjects, otherwise there would have to be manual parsing everywhere (and the facebook jsons are huge), which means more code, more error possibilities, more maintaining requirement and worse readability (compared to two lines QJson mapper). So I'd like to leave this one as is. I haven't had a look at the QJson library internals (yet), but from its usage it looks like that it is only using instances of those QObject classes to provide a convenient mapper of map keys to conversion functions (the property setters). This would make them an internal implementation detail, something more convenient than manually writing a mapping of string to function pointer but also just private. As I said I'll have a look into QJson, but unless I am gravely mistaken it only needs such QObjects as a generic accessor API, not as the actual data object. Thanks. I fixed all the issues you pointed out except this one. I think you can remove m_accessToken, m_path and m_queryItems from FacebookJob. Access token and path are already set on m_url and addQueryItem can be implemented to just call m_url.addQueryItem(). Also, virtual void start() = 0 is already part of KJob's API, so not needed again. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Moving libkfacebook to extragear
On Monday, 2012-10-29, Martin Klapetek wrote: On Mon, Oct 29, 2012 at 8:28 AM, Kevin Krammer kram...@kde.org wrote: I think you can remove m_accessToken, m_path and m_queryItems from FacebookJob. Access token and path are already set on m_url and addQueryItem can be implemented to just call m_url.addQueryItem(). Also, virtual void start() = 0 is already part of KJob's API, so not needed again. Good points, all fixed. Almost :) FacebookJob::m_queryItems is still there. can probably also remove the typedef for QueryItem. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Moving libkfacebook to extragear
On Sunday, 2012-10-28, Kevin Krammer wrote:
On Sunday, 2012-10-28, Martin Klapetek wrote:
On Sat, Oct 27, 2012 at 6:05 PM, Kevin Krammer kram...@kde.org wrote:
- the *Info classes seem to be normal data classes, IMHO they don't
need to be
QObjects but rather value types
This is for the parsing purposes - the library uses QJson parser/mapper,
which automagically maps the received json data to qobjects, otherwise
there would have to be manual parsing everywhere (and the facebook jsons
are huge), which means more code, more error possibilities, more
maintaining requirement and worse readability (compared to two lines
QJson mapper). So I'd like to leave this one as is.
I haven't had a look at the QJson library internals (yet), but from its
usage it looks like that it is only using instances of those QObject
classes to provide a convenient mapper of map keys to conversion functions
(the property setters).
I've checked QJson and its QObjectHelper indeed only uses the passed object as
a setter/getter interface.
Those info classes can therefore easily be made non-public/non-exported and
a single instance of each class to operate on respective instance of a proper
value-type data class.
E.g.
// appinfo.h
class LIBKFACEBOOK_EXPORT AppInfo
{
public:
// if applications do not need to set this, AppInfoParser could also be
// a friend, etc
void setId( const QString id );
QString id() const;
// ...
private:
class Private;
QSharedDataPointerPrivate d;
};
// appinfoparser_p.h
class AppInfoParser : public QObject
{
Q_OBJECT
Q_PROPERTY( QString, id READ id WRITE setId )
public:
void setData( const AppInfo appInfo ) { m_appInfo = appInfo; }
AppInfo data() const { return m_appInfo; }
void setId( const QString id ) { m_appInfo.setId( id ); }
QString id() const { return m_appInfo.id() }
private:
AppInfo m_appInfo;
};
Usage e.g. in PostInfo::setApplication(
void PostInfo::setApplication( const QVariantMap application )
{
AppInfoParser parser; // could be also be a member, etc
QJSon::QObjectHelper::qvariant2qobject( application, parser );
m_application = parser.data();
}
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
Re: Moving libkfacebook to extragear
On Sunday, 2012-10-28, Martin Klapetek wrote: On Sat, Oct 27, 2012 at 6:05 PM, Kevin Krammer kram...@kde.org wrote: - FacebookJob(QString, QString) calls setCapabilities, FacebookJob(QString) does not - Is the FacebookJob(QString) constructor really needed. It seems all jobs need a path This is used (only) from FacebookGetJob, assumingly for querying multiple items, where just the ids are specified and no path is needed. I'll see what can be done about this. Even FacebookGetJob and its subclasses set a path. FacebookGetIdJob for multiple IDs sets the query as query item instead of encoding it in the path itself, but it nevertheless needs / as path. So path is always needed, the base class can always require it. - the *Info classes seem to be normal data classes, IMHO they don't need to be QObjects but rather value types This is for the parsing purposes - the library uses QJson parser/mapper, which automagically maps the received json data to qobjects, otherwise there would have to be manual parsing everywhere (and the facebook jsons are huge), which means more code, more error possibilities, more maintaining requirement and worse readability (compared to two lines QJson mapper). So I'd like to leave this one as is. I haven't had a look at the QJson library internals (yet), but from its usage it looks like that it is only using instances of those QObject classes to provide a convenient mapper of map keys to conversion functions (the property setters). This would make them an internal implementation detail, something more convenient than manually writing a mapping of string to function pointer but also just private. As I said I'll have a look into QJson, but unless I am gravely mistaken it only needs such QObjects as a generic accessor API, not as the actual data object. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Moving libkfacebook to extragear
Hi, On Saturday, 2012-10-27, Martin Klapetek wrote: Hi, I'd like to move libkfacebook, the foundation for akonadi-facebook resource, into extragear. It's been in use for a while, lots of distro ship it bundled with akonadi-facebook resource, which is now becaming part of kdepim-runtime for 4.10 with libkfacebook as optional compile-time dependency. I'd like to ask for a review of this library, currently in kdereview - https://projects.kde.org/projects/kdereview/libkfacebook I had a cursory look and found a couple of things. CCing the original authors so they can provide input. - The job classes should have a QObject *parent = 0 argument and pass parent on to KJob's constructor. - Some of the constructors that can be called with only one argument are missing the explicit keyword. - FacebookJob(QString, QString) calls setCapabilities, FacebookJob(QString) does not - Is the FacebookJob(QString) constructor really needed. It seems all jobs need a path - All jobs to the same URL base setup (protocol, host, token). I am wondering if the base class could just have a KUrl member and initialize all the common stuff and derived classes just add to that. - the *Info classes seem to be normal data classes, IMHO they don't need to be QObjects but rather value types - The typdefs in eventinfo.h create global types with very generic names, e.g. Event Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Use of bin versus libexec
On Thursday, 2012-09-20, Jonathan Marten wrote: Kevin Krammer kram...@kde.org writes: Agreed. It is important, however, to remember that some of those (e.g. akonadiserver, akonadi_control) are not KDE programs and can therefore not be in a KDE specific libexec location but have to go into a standard (FHS or freedesktop.org) location for that purpose. Thanks for the clarification Kevin. Perhaps a better place for those Akonadi executables would then be $KDEDIR/libexec - this location isn't in the LSB/FHS but many packages which still use GNU Autoconf use it. IIRC KDE3 had the same. Do you mean $PREFIX/libexec, where $PREFIX will often be /usr (for distribution packages)? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: How Can I change wallpaper from CLI?
On Wednesday, 2012-09-05, Aaron J. Seigo wrote: what that would do in this case is instead of implementing (non-standard) means to set desktop wallpapers in N applications, N applications simply start advertising what content the user is focused on so that other parts of the system can react. that way instead of dozens of different plugins for dozens of applications to do something as inane and rarely used as set this random image i'm viewing to be my wallpaper using a menu item (it's already possible with drag and drop), Share Like Connect could simply offer an item when a image with a supported mimetype is selected / viewed. then nobody needs to worry about plasma shell internals (which can even differ between shells, btw, and has changed over time in some shells making maintaining such publicly used dbus APIs a PITA) and nobody needs to keep writing new plugins for this stuff. The problem with that (as far as I can tell) is that this would not be available to non-KDE apps, which (again as far as I understand) is the case of the thread starter. D-Bus interfaces have the advantage of being accessible from almost any program technology stack, most times even from shell scripts. and how hard is it? using namespace KActivities; m_resource = new ResourceInstance(window-wId(), this); ... some time later ... m_resource-setUri(m_currentImage); m_resource-setTitle(m_imageTitle); m_resource-setMimetype(m_imageMimetype); voila. show me a dbus api for wallpaper setting that can do that. :) Just curious: what kind of non-D-Bus communication mechanism is used by that? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: How Can I change wallpaper from CLI?
On Thursday, 2012-09-06, Aaron J. Seigo wrote: On Thursday, September 6, 2012 12:47:16 Kevin Krammer wrote: The problem with that (as far as I can tell) is that this would not be available to non-KDE apps, which (again as far as I understand) is the case of the thread starter. if the issue was non-KDE apps, this would be an interesting starting point for discussion. Well, the issue is non-KDE apps or at least one of them (the one of the developer asking on how to do change the wallpaper). but the discussion moved to the example of a KIPI plugin for digikam. I considered this an additonal data point, i.e. another interested party in changing wallpapers. However, if we consider this a new subtopic, then somebody should probably advise the thread starter on the more generic problem. that is a KDE application. True. once we get our own house in order, then i'd love to discuss about how we interface with the rest of the world. Sure. Meaning that someone has to reply to the original query and write that Plasma workspaces currently do not support programmatic changes of wallpaper but is something considered for the future. D-Bus interfaces have the advantage of being accessible from almost any program technology stack, most times even from shell scripts. qdbus org.kde.ActivityManager /ActivityManager | grep Resource we're smart enough to implement things in ways that aren't completely stupid. ;) and really this is a design question (is associating URIs and metadata with windows a good / better solution? if so, how?), not an implementation problem (what is used for remote procedure calls?). I didn't say that D-Bus interfaces were the best or even a good solution just that one of their properties is being usable from a lot of program environments. show me a dbus api for wallpaper setting that can do that. :) Just curious: what kind of non-D-Bus communication mechanism is used by that? it uses DBus. the differentiation is that it isn't focused on making something to set a wallpaper but focused on allowing content to be introspected so that things can be done for/with that content. making an API for setting wallpaper is not only fragile (see the differences in KDesktop 1, 2, 3 and Plasma; see the differences for windows, mac, xfce, gnome, etc) it is also very limited in scope and needs to be upkept in every single application. Without checking the implementation details I would have guessed that allowing content to be introspected needs support for that introspection in every single application and that support would need to be updated when the introspector changes the way it introspects. Basically moving the maintenance of API from the target to the source of the data. However, the thread starter might be willing to provide such introspection capability if somebody points them to respective interface descriptions. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: new WebP image plugin (kimgio) and cmake question
On Thursday, 2012-09-06, David Faure wrote: On Saturday 01 September 2012 13:20:08 Kevin Krammer wrote: - how can I add a new MIME Type for image/x-webp ? Can't help you with the other things, but for that see kdelibs/mimetypes/kde.xml That's only the short-term hack solution. Follow the instructions at http://www.freedesktop.org/wiki/Specifications/AddingMIMETutor in order to submit the mimetype definition for inclusion into shared-mime-info itself [which I can do, then]. Good point! I didn't consider the fact that this was a non-application-specific MIME type. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: How Can I change wallpaper from CLI?
On Thursday, 2012-09-06, Aaron J. Seigo wrote: in the same way that every application that opens files stored on disk needs to support file open/read/write. in reality, very few of our applications make direct libc calls to achieve this and instead rely on (much) higher level libraries to keep such details at arms length. Sure, same as applications dealing with images using the Kipi plugins for sharing implementations of common tasks. the introspection mechanism is completely encapsulated in libkactivities and no application need (or should) care now or in the future about the implementation details. in frameworks 5 libkactivities will end up being a Qt- only library. the dbus API is also available in a well-formed dbus xml service definition so it can be readily reused by other applications which don't use Qt. Excellent, so can any of the developers involved with this effort compile a list of D-Bus introspection files (probably as links into the repository) for the thread starter so he can implement the necessary adaptors/interfaces in whatever technology stack he is using? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: [PATCH] KSecretsService Collection and Item property names
Hi Jakub, thank you caring about our client implementation. The macro usage looks a bit weird to me, but it is Valentin's call :) Cheers, Kevin On Sunday, 2012-08-05, Jakub Filak wrote: The current implementation of KSecretsService accepts property names of Collection and Item without interface name. The Secret Service API standard says Specify the property names in full interface.Property form [1] The form required by the standard: org.freedesktop.Secret.Item.Label The accepted form in KSecretsService: Label (gnome-keyring accepts the properties only in full interface form) The patch changes the accepted name form from single name form to full interface name form. The patch simply adds an interface prefix to each occurrence of a property name. (I used a helper macros because of DRY.) The patch applies to the files: ksecretsserviced/frontend/secret/collection.cpp ksecretsserviced/frontend/secret/service.cpp ksecretsserviced/frontend/tests/servicetest.cpp Regards, Jakub [1] : http://standards.freedesktop.org/secret-service/re02.html -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: RFC: Moving KWallet Password dialog into Plasma
On Saturday, 2012-07-21, David Faure wrote: On Friday 20 July 2012 20:35:24 David Edmundson wrote: With Akonadi - there's always a window, and they have a solution. I don't think that's true. On KDE startup, the mail dispatcher might want to send pending email, or the calendar applet starts akonadi and then the imap resources start the regular sync from servers. In these cases, there isn't a window associated with the password request. Indeed, most likely a misunderstanding of what I wrote. The base API for Akonadi services has a method for retrieving a suitable window Id for the dialog parent role, however it has to be provided by something that has a window. Its current implementation is rather limited, i.e. it does it D-Bus call to the Akonadi Systemtray application. Being a D-Bus call this could be implemented by a more appropriate workspace component. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+
On Saturday, 2012-06-09, Aaron J. Seigo wrote: On Saturday, June 9, 2012 17:23:44 Andrey Ponomarenko wrote: I've run the compatibility test against the 4.8.3 and 4.8.4 versions of KDE-libs using the ABI Compliance Checker tool and got the following report: this is remarkably useful. thanks! are we running this on every release? if not, could we? a report like this across our public libraries made at beta1 would be so fantastic ... Or even as part of the CI system. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: kio and frameworks 5
On Sunday, 2012-05-13, David Faure wrote: On Friday 11 May 2012 21:33:35 Casper Clemence wrote: Libferris is an awesome piece of technology. It provides not just the traditional features of a VFS but a uniform method of access for applications and users to a large and expanding range of things What does it do exactly, and how? There have been a couple of blog postings on planetkde showing what it can do [1], but I have no idea how it works. Cheers, Kevin [1] http://monkeyiq.blogspot.com/search/label/libferris -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: The Nepomuk Situation
On Monday, 2012-05-07, Vishesh Handa wrote: On Mon, May 7, 2012 at 9:53 PM, Albert Astals Cid aa...@kde.org wrote: So you mean yes, they can, they do now and can still do it, even if using the old APIs are suboptimal. Right? I'm sorry. What? I think what Albert is asking is whether applications using the old APIs can continue to do so even if other applications are using the new APIs. Or whether the old APIs become unavailable of dysfunctional when the new ones are introduced. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Extra KDE Telepathy modules moving to Extragear
On Sunday, 2012-04-29, Martin Klapetek wrote: On Sat, Apr 28, 2012 at 22:44, Kevin Krammer kram...@kde.org wrote: On Saturday, 2012-04-28, George Kiagiadakis wrote: No, the classes that wrap GObjects do not need a d-pointer. All the calls are forwarded to the underlying GObject and if for any reason we ever need to save extra data on the wrapper class (which is highly unlikely), we should use the GObject qdata for that. Wrapper classes may be destroyed and re-allocated by QtGLib and therefore they shouldn't hold any data. So the GObject has a d-pointer? Any specific reason there is a GObject at all? My very basic understanding of Telepathy was that it is D-Bus based services. Telepathy is based on D-Bus services, however this is about Telepathy logger [1], which is a GObject-based implementation of a central logging Telepathy component, which does not use D-Bus for sending the logs as it is quite heavy data and D-Bus for this purpose is rather slow, so it provides a direct access API. The documentation you linked to seems to be quite of of date (most of the links in it don't work), so I would still need some clarifications. The document claims that the logger is an independent service, i.e. it says: Telepathy Logger is a session daemon. I quite don''t understand the term direct access API in the context of a daemon. Usually daemon refers to a separate process. Communicating with a process is to my best understanding never done by linking the daemon code into the client applications. My best guess so far is that there is some library that provides read-only access to files the independent logger writes onto disk. Our telepathy-logger-qt, which we want to move to Extragear, basically just wraps the original logger into Qt-like API, so that it can be used with Qt/KDE apps easily. Based on my guess I would strongly recommend to put the wrapped GObject into the wrapper's d-pointer. Otherwise your only way of ever implementing that natively is to name a struct GObject and use that as the native implementation's d-pointer, making it very hard for any using application to link with any library exposing GObject symbols. Cheers, Kevin [1] - http://telepathy.freedesktop.org/wiki/Logger -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Extra KDE Telepathy modules moving to Extragear
On Saturday, 2012-04-28, George Kiagiadakis wrote: No, the classes that wrap GObjects do not need a d-pointer. All the calls are forwarded to the underlying GObject and if for any reason we ever need to save extra data on the wrapper class (which is highly unlikely), we should use the GObject qdata for that. Wrapper classes may be destroyed and re-allocated by QtGLib and therefore they shouldn't hold any data. So the GObject has a d-pointer? Any specific reason there is a GObject at all? My very basic understanding of Telepathy was that it is D-Bus based services. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Question about unittesting
On Sunday, 2012-04-08, Kevin Krammer wrote: At KDE we usually use the QTest framework [1] for unittesting and we have cmake macros that make it easy to add them to a project's CMakeLists.txt (e.f. see [2]) and some C/C++ helper macros that make writing them easier [3]. Cheers, Kevin [1] http://qt-project.org/doc/qt-4.8/qtest.html Sorry, that is not a very good link, this one is better http://qt-project.org/doc/qt-4.8/qtestlib-manual.html [2] http://ktutorial.wordpress.com/2009/03/18/unit-testing-a-kde-4-library/ [3] http://lxr.kde.org/ident?i=QTEST_KDEMAIN Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Review Request: include KolorManager in kdegraphics
On Wednesday, 2012-03-14, Matthias Klumpp wrote: 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. Being a freedesktop.org project in the sense of being hosted at freedesktop.org does not add any value to this discussion. It is only hosted there because it is lead by GNOME developers with enought connections to fdo admins got a repository approved. A project originating at KDE would not have been able to do that no matter how independently developed it would have been. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: bugzilla situation
and have apply filtering and highlighting such that what one sees depends on what one needs to see. E.g. say second level is able to attach scoring information to information inside the first level context and, when the involvement of third level becomes necessary, just flag the context for needs third level review. At this point third level can already use the second level score to only look at a reduced problem, but is potentially available to expand. If we assume a separate score for third level, developers of the same team could even reduce the required reading even further, even if the respective individual will not be the one working on a solution. Basically just a more advanced implementation of what usenet clients already provided [1] almost two decades ago. Cheers, Kevin [1] I know a couple of developers who read their project's user mailinglist through a newgroup interface and have local scoring rules that keep all postings hidden unless 100 points are reached. This can be achieved by any combination of things happending, e.g. the person themselves posting (gets 100 points instantanioulsy), two postings from another developer (50 points for posting by any other developer), etc. They can temporarily or permanently upscore certain other posters, explicitly hide or unhide threads, etc. -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On Monday, 2011-11-14, Kevin Ottens wrote: Right. Although I don't expect a kdeui to still exist in the end. The relevant KWallet code might end up in a kde4support I think. For that to happen we'd need a similar convenience API in libksecretservice itself if deemed appropriate (the whole KWallet API being synchronous it makes me feel a bit uneasy about it, could block on the other process, I'd rather keep that explicit on the API consumer with exec'ed jobs). Definitely. But not because it could block but because it must block. And the only safe way to do that is to run the asynchronous call in a separate thread, blocking the calling thread with a semaphore or waitcondition. Loads of extra work for the maintainer of the synchronous wrapper for little extra convenience of the API using developer. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: FW: Kleopatra Locking Clipboard
Hi Andrew, there haven't been any responses since your first email. Since you wrote Kleopatra.exe I would suggest you send to the kde-windows list instead. Cheers, Kevin On Wednesday, 2011-11-02, Andrew Birch wrote: Hi guys, I posted the below to kde-de...@kde.orgmailto:kde-de...@kde.org before I was a member of the list so I'm not sure whether it got through or not. Hence, I thought I re-post now I am a member - I would appreciate any advice. Thanks very much in anticipation, Andy Andrew Birch Junior Developer ___ [cid:imagebc90e7.png@6a6f7a50.ae0c4f22] Main: +44 20 7634 8500 Direct: +44 20 7634 8538 Email: andrew.bi...@tradar.com Web:www.tradar.comhttp://www.tradar.com/ This email is subject to the following disclaimer: Tradar disclaimerhttp://www.tradar.com/company/emaildisclaimer.htm. London Office - Old Change House. 128 Queen Victoria Street, London. EC4V 4BJ Tradar Limited is a limited company registered in England and Wales. Registered number: 3431380. Registered office: 20-21 Jockey's Fields, London. WC1R 4BW From: Andrew Birch Sent: 27 October 2011 12:06 To: 'kde-de...@kde.org' Cc: Mark Hazeldine Subject: Kleopatra Locking Clipboard Hi there, Application: Kleopatra (Certificate Manager and Unified Crypto GUI) Version: 2.1.0 KDE Version: 4.1.4 I am a developer who is working on a piece of software that accesses the Clipboard. I am experiencing a problem whereby when trying to access the Clipboard an ExternalException is thrown with the following error message: 'The requested clipboard operation did not succeed'. As a result, I did some diagnostic work to try to work out which application was locking the Clipboard. There seem to be a number of different applications that sometimes lock it (presumably whilst they have access to it). However, the worst offender seems to be Kleopatra.exe. By 'worst' I mean it seems to persistently lock the Clipboard and thus blocks our application from accessing it. We are not actively using Kleopatra when this problem occurs; it is just running in the background. Also, interestingly this problem does not always seem to happen; sometimes Kleopatra doesn't seem to access/lock the Clipboard. I was wondering if you might know why this is and if there is anything we can do to prevent Kleopatra.exe from persistently accessing the Clipboard? Thanks, Andy -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: The future of Power Management - together with Activities
On Sunday, 2011-10-02, Andreas Pakulat wrote: Hmm, that means I have to learn about activities if I ever want to watch a movie while I'm without ac... Shouldn't the movie player inhibit display replated saving functions in this case? (Assuming you meant playing a movie in full screen). Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Extending KZip class
On Sunday, 2011-10-02, Θεόφιλος Ιντζόγλου wrote: I'm trying to improve the karchive plugin of ark to have better support for zip files but unfortunately there are some things missing from the KZip class like support for encrypted archives and file deletion. Should I create patches for the KZip/KArchive classes or just subclass KZip class and do all the necessary changes locally? I think ideallly this would be done in the existing classes. However, there is currently a kind of freeze for features in kdelibs so you might have to work on that in a subclass of your own for the time being. But hopefully in a way that results in this extended functionality being part of the respective classes in KDE frameworks 5. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: The case for a kdelibs 4.8
On Thursday, 2011-09-29, Rolf Eike Beer wrote: The reason to stop master was (as far as I understand) to make the frameworks branch easily to maintain. If someone is working on 4.8 (bugfixing, features) all this has to be ported to frameworks, too. So you develop a moving target on a moving target. What about a more stricter than usual policy for additions to 4.8? Like every new feature wanted in 4.8 has to go through reviewboard for 4.8 and frameworks 5. That way the developer doing the feature work for 4.8 will also take care of the forward porting task. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Review Request: Start D-Bus after setting KDE_FULL_SESSION
On Aug. 3, 2011, 6:19 p.m., Oswald Buddenhagen wrote: this sounds wrong. what if dbus is started earlier, e.g. by a PAM module? this can easily happen once we use the new SecretService. there should be some interface to push environment variables into the bus after it is running. maybe it would be ok to read a file with VAR=value assignments (one per line, no quoting whatsoever - printenv output) from a defined per-session location before activating services. I guess a D-Bus enabled app could actually check the workspace it is running on instead of falling back to the detect by environment variable hack. E.g. by checking if Plasma Desktop's name is registered or ksmserver is the session server, etc. - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102194/#review5362 --- On Aug. 3, 2011, 12:15 p.m., Christoph Feck wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102194/ --- (Updated Aug. 3, 2011, 12:15 p.m.) Review request for kdelibs, Kevin Kofler, George Kiagiadakis, and David Faure. Summary --- As described in bug 267770. Luckily, there is no KDE-specific initialization between D-Bus launch and setting KDE_FULL_SESSION, so interchanging them should not affect KDE itself. This addresses bug 267770. http://bugs.kde.org/show_bug.cgi?id=267770 Diffs - startkde.cmake 92c8753 Diff: http://git.reviewboard.kde.org/r/102194/diff Testing --- I don't know D-Bus activated apps, I assume I don't have any, so I did not see any difference in startup. Thanks, Christoph
