Re: The situation of KWallet, and what to do about it?
On Wednesday, 2016-07-13, 11:41:14, Thomas Pfeiffer wrote: > On 11.07.2016 22:29, Mark Gaiser wrote: > > As far as i can tell, QtKeyChain isn't a keychain at all, it's a wrapper > > around platform specific keychains that provides a unified interface for > > keychain functionality. It itself doesn't implement a keychain (or it does > > on windows?). > > Yes, QtKeychain wraps available keychains from the platform it runs on. > However: "Since Windows does not provide a service for secure storage > QtKeychain uses the Windows API function CryptProtectData to encrypt the > password with the user’s logon credentials. The encrypted data is then > persisted via QSettings." > > On Linux we could use GNOME Keyring, but if we don't want that, we'd of > course still have to implement our own backend. The advantage would be that > it would be much easier to replace that at any point without having to > adapt applications. If QtKeychain, or any other multiplatform API, can use the SecretService API on Linux, then we could just require such an implementation to be available and let the distributors decide whether they want to fulfill that with gnome- keyring (assuming it is-a SecretService daemon). 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: I developed a workaround for Qt5.4 DND bug that KDE apps might need
On Thursday, 2016-01-21, 12:28:02, PCMan wrote: > On Thu, Jan 21, 2016 at 6:16 AM, Frank Reininghaus <frank7...@googlemail.com > > wrote: > > You said that a patch is in the Qt bug tracker, but all I could find > > with a bit of searching is a link to this Chromium report, which has a > > patch: > > > > https://code.google.com/p/chromium/issues/detail?id=543940 > > > > Is that the patch you mean? Do you know if it has been submitted for > > review to Qt? If not, do you think that you could make that happen > > (since you seem to know quite a bit about drag) or help to make > > it happen? > > Yes, that's the patch I referred to. > It's not attached to the original bug report, but the patch is mentioned in > the comments. > FYI: https://bugreports.qt.io/browse/QTBUG-47981 The problem is that if there is no attempt to get the patch merged, it will likely not happen. Similar to KDE, a patch that cannot be properly reviewed is basically "not existant" unless the maintainer of the base code has enough time to deal with any necessary changes themselves. Part of dealing with code contributions is using the project's code contribution infrastructure for that. E.g. for a github hosted project that would be a pull request, for a KDE project a Phabricator request and for Qt that is a Gerrit request. Maybe whoever created the patch in question doesn't know that the way to get some fix into Qt is to upload it to Gerrit? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: I developed a workaround for Qt5.4 DND bug that KDE apps might need
Hi, On Saturday, 2016-01-16, 12:43:53, PCMan wrote: > Since DND is crucial for a modern desktop environment and it's an upstream > bug, I believe that KDE is also affected. > Luckily I found some quick workarounds, so I'm gonna share it with you. > > https://github.com/lxde/pcmanfm-qt/pull/295/files > > I made it an independent C++ class which is licensed under LGPL, so it can > easily be reused by other Qt projects. > Just add two lines in your main() and it will work automagically. > > The bug still exists in Qt 5.5 and it's not yet fixed in Qt upstream. Sorry, this may be a stupid question: is this a proper fix or more like a hack? If the former, has it been submitted upstream? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: I developed a workaround for Qt5.4 DND bug that KDE apps might need
On Saturday, 2016-01-16, 21:35:03, PCMan wrote: > On Sat, Jan 16, 2016 at 6:20 PM, Kevin Krammer <kram...@kde.org> wrote: > > Sorry, this may be a stupid question: is this a proper fix or more like a > > hack? > > It's a quick hack rather than a proper fix. > The pusepose of this hack is simple. > Make it work for the window period before the users get the latest Qt which > contain a proper fix. Ok, thanks. > > If the former, has it been submitted upstream? > > There's a patch in the Qt bug tracker, but nobody tests it. > The bug is left there for quite some time. Patch in the Qt bug tracker meaning as an attachment or a proper Gerrit change request? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Volunteer developer without much experience
Hi Oleg, On Sunday, 2015-09-20, 14:23:07, Oleg Kitain wrote: > Hello KDE people. > I'm a developer at ELVEES-NeoTek who, so far, has mostly worked with > drivers and Python applications. > I don't currently have Qt experience, but I am fairly competent in C and > pretty okay with C++. > > I want to help KDE5 achieve feature parity with KDE4. How can I start? Any particular product of KDE you want to work on? The shell/desktop, or one of the applications? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Review Request 124328: Man pages for kapidox
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124328/#review82397 --- I thought our man pages are written in docbook and then translated by the usual docbook workflow? - Kevin Krammer On Juli 12, 2015, 4 nachm., Scott Kitterman wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124328/ --- (Updated Juli 12, 2015, 4 nachm.) Review request for KDE Frameworks, Alex Merry, Aurélien Gâteau, and Kevin Krammer. Repository: kapidox Description --- Add man pages for kapidox scripts Diffs - docs/depdiagram-generate-all.1 PRE-CREATION docs/depdiagram-generate.1 PRE-CREATION docs/depdiagram-prepare.1 PRE-CREATION docs/kgenapidox.1 PRE-CREATION docs/kgenframeworksapidox.1 PRE-CREATION setup.py 083543f Diff: https://git.reviewboard.kde.org/r/124328/diff/ Testing --- Built and installed updated version and verified man pages were correctly installed and readable in the KDE man page viewer. Thanks, Scott Kitterman ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
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: Gerrit available for trial
On Saturday, 2014-10-11, 11:31:54, David Faure wrote: On Saturday 11 October 2014 00:00:53 Jan Kundrát wrote: On Friday, 10 October 2014 23:38:37 CEST, David Faure wrote: Another issue: could all incoming review requests for kio (and all other frameworks in the future, except plasma-framework which has a dedicated list) be sent to kde-frameworks-devel? I don't see a mail with my request there. Sure, that can be done, too. How noisy would you like Gerrit to be? Just new changes? New revisions, too? What about comments/reviews? See [1] for possible options. I'll also have to chat with Ben to make sure that the e-mails do not end up in the moderation queue. I would say all, just like we have with reviewboard and Qt gerrit. I am not opposed but I think just the new ones would be sufficient. If one is interested in the proceedings of a specific request it is easy enough to add oneselves as a reviewer. It also makes the new notification stand out since it is the one being delivered to the list while the following ones are delivered to each reviewer directly. I think it is also important to consider that Gerrit allows each user to setup their own notifications in a quite flexible way. I.e. a framework maintainer could always get all noitifications for their framework. The notifications sent to the list would primarly serve as a provider of activitiy overview and new frameworks becoming available. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
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.
Re: Maintaining KAppTemplate
Hi Simon, On Saturday, 2014-09-13, 21:06:31, Simon Waechter wrote: Hi there I am sure Anne-Marie doesn't mind that an active new contributor is taking care of KAppTemplate. I remember her writing to kde-edu about having fewer time for KDE in the forseeable future and handing over other responsibilities to capable people there as well. Ok, thanks for that information Kevin. If this is enough +1, is it possible to replace the current maintainer ( https://projects.kde.org/projects/kde/kdesdk/kapptemplate ) ? That would be great :) I'd say create a sysadmin ticket [1] and ask for you being added to the project's maintainers. Use the link to this thread in the list archives as a reference. By the way, KAppTemplate has now an experimental frameworks branch with a working(=usable) application, but there is still much work left. Awesome :) Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: There's no proper replacement for KIcon
On Thursday, 2014-09-11, 17:56:38, Eike Hein wrote: On 11.09.2014 17:22, Kevin Krammer wrote: Hicolor is there for cases where the setup fails to provide any workspace or distribution specific theme. Yes. So I'm thinking ahead and telling you how that setup looks like for a workspace: - Write a Qt platform plugin. Needs coding chops. We have them. What about workspaces which don't? What about all the other toolkits be- sides Qt? - Swap out icons in hicolor. Which do you think happens? Depends on the wanted results. A platform plugin provide platform integration which icons are only a small part of. If the platform vendor wants Qt application to properly integrate with their choice of workspace, they will have a platform integration plugins. If they just want to have icons, they are very well able to ship their own version of hicolor fallback icons. This does not conflict with having a non-broken hicolor theme package to start with. But why not just have your theme as an explicit theme like everyone else and only get your theme in case the fallback path is triggered? Because making Qt aware of an explicit theme involves writing a Qt platform plugin. It means if you're a sys admin / distro you can no longer solve your problem on the spec level (unless you swap out icons in hicolor), you need to be aware Qt exists. Seems like a layering violation to me. As I said above, it depends on the level of integration you'd like to achieve. There are lots of integration points provided by said plugin. Sharing a setting that indicates a default theme name is of course a good goal, doesn't however fix the problem of the fallback being incomplete. No, but it makes it a lot easier for distros to provide a complete fallback (- installing Oxygen or something else, setting it as preferred fallback). It's less work than maintaining a complete hi- color no one can agree on. I don't see why it would be difficult to agree on having a non-broken fallback. Or do you mean install the custom theme twice, once as itself and once as hicolor? Wait - I think I now understand why we're having trouble communicating about this. You think a distro has the option to install Oxygen *as* hicolor, right, making my preferred fallback thing seem redundant? That's not so - because numerous apps install app icons *into* the hicolor folder structure, including KDE apps, and those can conflict with the icons in a theme. For distro packagers that means they'd have to fix numerous package installs to eliminate those conflicts. No, I mean providing their own hicolor theme if they want to (ab)use the fallback as their integration point. I really have to read the spec soon, but I have my doubt that it lists any app specific icons. Thus installing such into its paths should not conflict with anything already there. So using any given theme *as* hicolor doesn't fly without manual merging/maintenance work for packagers, which is what I suggest to avoid with a 'preferred system fallback' config knob. Assuming that a vendor wants to override the default hicolor package, then yes that will obviously require maintenance. This is no different with any other deviation from upstream. Again, having a shared setting, exposed via whatever mechanism (env variable, X11 property, file, ) is orthogonal to having a working fallback. The fallback is hit when no other means of lookup, whether configurable or hardcoded, resulted in a matching icon. So it *must* at least contain all icons that are specified in the spec, it is an icon loader's last resort. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
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. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
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: Maintaining KAppTemplate
Hi Simon, On Thursday, 2014-09-11, 17:21:11, Simon Waechter wrote: Hey there At the moment I am porting the KAppTemplate application to KF5 and I wanted to ask, if it is possible to take over maintainership from Anne-Marie Mahfouf, which is more or less inactive as far as I know. I am sure Anne-Marie doesn't mind that an active new contributor is taking care of KAppTemplate. I remember her writing to kde-edu about having fewer time for KDE in the forseeable future and handing over other responsibilities to capable people there as well. Beside porting to KF5 (Experimental patch: https://git.reviewboard.kde.org/r/120135/ ) I also plan to update and introduce new templates, fix several problems memory leaks. Another idea is to move the core functionality inside a shared library so KDevelop/KDevplatform can use that library and avoid a code duplication of the whole template code, which is quite annoying at the moment. There might also be the possibility to add a file generator and a VCS option. Sounds like a good plan :) Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: There's no proper replacement for KIcon
On Wednesday, 2014-09-10, 23:43:15, Albert Astals Cid wrote: El Dimarts, 9 de setembre de 2014, a les 16:25:26, Kevin Krammer va escriure: On Sunday, 2014-09-07, 10:27:06, Albert Astals Cid wrote: So as I see it, there's three options: * Do nothing, and expect that people have to set one of XDG_CURRENT_DESKTOP, KDE_FULL_SESSION, GNOME_DESKTOP_SESSION_ID or DESKTOP_SESSION environment variables to get icons * Do the change/hack to QGenericUnixTheme::themeHint return any of the themes in xdgIconThemePaths that is not hicolor * Talk to the xdg-people to include a way to get the current icon theme and use that in QGenericUnixTheme::themeHint Wouldn't a fourth option be to make sure that hicolor is actually a proper fallback as specified? Applications already are more or less required to install their fallbacks in hicolor, so the shared icons should be there as well, no? I don't think it makes sense, i mean who would install stuff to hicolor/actions/document-open.png ? oxygen? breeze? tango? someothericonset? For applications it makes sense tha application to install to hicolor since the application owns the name for that icon, but noone actually owns the document-open.png action so that's why i think it makes no sense for it to be there. The rule to always also install an application icon into Hicolor was meant as an example of a general intent that Hicolor be fully usable. I don't know the details of the icon spec but my understanding was that document-open was a specified standard name. Assuming that is the case it would have implied for me that an icon of this name is always present. If not in the current theme then at least in the fallback Hicolor theme. Again based on these prior assumptions on the spec, not having that icon in Hicolor would constitute a bug in the Hicolor theme and should be fixed by adding the icon there,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. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On Thursday, 2014-09-11, 09:33:23, Albert Astals Cid wrote: El Dijous, 11 de setembre de 2014, a les 08:46:11, Kevin Krammer va escriure: The rule to always also install an application icon into Hicolor was meant as an example of a general intent that Hicolor be fully usable. I don't know the details of the icon spec but my understanding was that document-open was a specified standard name. Correct. Assuming that is the case it would have implied for me that an icon of this name is always present. Should be always present in valid themes, yes. If not in the current theme then at least in the fallback Hicolor theme. Again based on these prior assumptions on the spec, not having that icon in Hicolor would constitute a bug in the Hicolor theme and should be fixed by adding the icon there,no? There's no hicolor theme per se. Only a bunch of empty folders http://www.freedesktop.org/software/icon-theme/releases/hicolor-icon-theme-0 .5.tar.gz Is there a maintainer for this package? IMHO the only sensible solution is to make sure that it actually contains the icons specified. Without it is rather useless as a specification base line. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On Thursday, 2014-09-11, 02:06:02, Albert Astals Cid wrote: El Dijous, 11 de setembre de 2014, a les 10:57:17, Kevin Krammer va escriure: On Thursday, 2014-09-11, 09:33:23, Albert Astals Cid wrote: El Dijous, 11 de setembre de 2014, a les 08:46:11, Kevin Krammer va escriure: The rule to always also install an application icon into Hicolor was meant as an example of a general intent that Hicolor be fully usable. I don't know the details of the icon spec but my understanding was that document-open was a specified standard name. Correct. Assuming that is the case it would have implied for me that an icon of this name is always present. Should be always present in valid themes, yes. If not in the current theme then at least in the fallback Hicolor theme. Again based on these prior assumptions on the spec, not having that icon in Hicolor would constitute a bug in the Hicolor theme and should be fixed by adding the icon there,no? There's no hicolor theme per se. Only a bunch of empty folders http://www.freedesktop.org/software/icon-theme/releases/hicolor-icon-the me -0 .5.tar.gz Is there a maintainer for this package? I have no idea IMHO the only sensible solution is to make sure that it actually contains the icons specified. Without it is rather useless as a specification base line. By reading http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html i think they disagree with you as they mention hicolor for icon apps and not for general icons. Ok, I'll try to read the spec and ask for clarification on the XDG list. From my point of view there is little use case of having a fallback if it does not allow one to fall back 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. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On Thursday, 2014-09-11, 15:29:13, Eike Hein wrote: On 11.09.2014 11:11, Kevin Krammer wrote: From my point of view there is little use case of having a fallback if it does not allow one to fall back to it. Check out the chat log for the idea of enhancing the spec to add some sort of system-level configuration scheme to set a fallback one level higher than hicolor (to avoid a namespace fight over hicolor). I imagine that will come up in the xdg thread. Sounds interesting, but checkout where? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On Thursday, 2014-09-11, 15:40:14, Eike Hein wrote: On 11.09.2014 15:33, Kevin Krammer wrote: Sounds interesting, but checkout where? In this thread, where I've posted it and encouraged reading it a few times :). Ah :) I thought you were referring to some XDG discussion. Having a configurable fallback before the final fallback can't hurt, but that doesn't solve the actual problem of hicolor being incomplete. It is just a work around. Might be the only way if the other participants in the icon spec standard want the fallback to be broken. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On Thursday, 2014-09-11, 15:53:57, Eike Hein wrote: On 11.09.2014 15:43, Kevin Krammer wrote: Having a configurable fallback before the final fallback can't hurt, but that doesn't solve the actual problem of hicolor being incomplete. It is just a work around. Sort of, except I think the outcome is more or less the same - either a distro/ISV decides on a particular set of icons to roll into hicolor to make things look good (which means work) or they get an explicit config knob to do that merging. Why would hicolor be distro/ISV specific? I don't think you really get out of distributed work in either scenario - in the fix hicolor scenario you have many distros replicating the work (because no, deciding on a single hicolor isn't going to happen, if only because theming is one of the things distros do to differentiate themselves), I am afraid I can't follow. No distro would be involved in that, I am talking about a hicolor package that is provided alongside the spec. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On Thursday, 2014-09-11, 17:05:43, Eike Hein wrote: On 11.09.2014 16:09, Kevin Krammer wrote: Why would hicolor be distro/ISV specific? Because a hicolor theme everyone likes visually isn't going to happen. People will want to modify what's in that fall- back for theming reasons, and distros theme to differentiate themselves. Why would anyone want to change the fallback? The fallback is something you never ever want to see, it is a worst case scenario puffer. Like the safety net in a circus arena. I think what you mean is a default, like us using Oxygen/whatever, GNOME using Tango/whatever, etc. Hicolor is there for cases where the setup fails to provide any workspace or distribution specific theme. Its purpose (I have still not read the spec but that is the only thing that makes sense to me) is to make sure there is an icon if anything else has failed. A shared resource to avoid every application having to ship fallbacks for each used icon. In the hicolor as fallback scheme, there are two ways to affect what icons actually show in KF5 apps outside Plasma: - Make sure this environment outside Plasma, whatever it is, has a Qt platform plugin available that reads some setting somewhere that overrides hicolor by specifying a theme. Right, this is what a distributor or other workspace would do if they care about theming as a means of differentiation. (This is how Plasma itself solves this.) Exactly. - Manipulate what icons are actually in hicolor. Sure, if somebody wants to install their icon theme instead of hicolor, why not. But why not just have your theme as an explicit theme like everyone else and only get your theme in case the fallback path is triggered? Or do you mean install the custom theme twice, once as itself and once as hicolor? If we introduce a preferred system fallback theme config option in the spec that overrides hicolor, and make Qt aware of it, that avoids either work, which is more extensible to new environments. Sharing a setting that indicates a default theme name is of course a good goal, doesn't however fix the problem of the fallback being incomplete. I read that non Qt based systems use XSettings to exchange that information (on X11 only of course) so maybe we can have that in Qt as well? And come up with a way to do something equivalent on Wayland? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
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: There's no proper replacement for KIcon
On Sunday, 2014-09-07, 10:27:06, Albert Astals Cid wrote: So as I see it, there's three options: * Do nothing, and expect that people have to set one of XDG_CURRENT_DESKTOP, KDE_FULL_SESSION, GNOME_DESKTOP_SESSION_ID or DESKTOP_SESSION environment variables to get icons * Do the change/hack to QGenericUnixTheme::themeHint return any of the themes in xdgIconThemePaths that is not hicolor * Talk to the xdg-people to include a way to get the current icon theme and use that in QGenericUnixTheme::themeHint Wouldn't a fourth option be to make sure that hicolor is actually a proper fallback as specified? Applications already are more or less required to install their fallbacks in hicolor, so the shared icons should be there as well, 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. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [Kde-pim] split kdepimlibs
On Tuesday, 2014-08-26, 18:30:54, Daniel Vratil wrote: I think all the type-specific libraries (-abc, -calendar, ...) would all depend on the Widgets library anyway and the amount of non-gui stuff is rather limited * I think it is a worthy goal to make a widget split there as well. Some of the widgets are things like type data editors, which could be separated such that all editing logic and data handling can be used in a C++ or QML context. If the QML driven technology is not QtWidgets, then forcing a dependency might not be appreciated. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: split kdepimlibs
On Wednesday, 2014-08-27, 19:59:24, John Layt wrote: My general 2c: I'm with Kevin that we should do functional and api reviews, move code around, and generally refactor stuff *before* we split anything. It's just plain easier that way. I don't think we're anywhere near close to knowing what to do with everything to be splitting things yet. Will we also end up with deprecated code in a kdepimlibs4-support, for example? We started a page at https://community.kde.org/Frameworks/Epics/kdepimlibs to document this sort of stuff, it would be good to bring it up-to-date and work through it progressively. We also have Akademy and the sprint scheduled for November (?) at which we could sit down and methodically work through the list of everything and figure out what to do. I agree, it makes little sense to rush this before Akademy. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119895: New class for 5.2 to help user to migrate config files and ui file to new standardpath
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119895/#review65352 --- Ship it! Ship It! - Kevin Krammer On Aug. 22, 2014, 10:55 vorm., Laurent Montel wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119895/ --- (Updated Aug. 22, 2014, 10:55 vorm.) Review request for KDE Frameworks, David Faure and Kevin Krammer. Repository: kcoreaddons Description --- Class helps user to migrate config file and ui file to new location Diffs - autotests/CMakeLists.txt 75d1293 autotests/data/appui1rc PRE-CREATION autotests/data/appuirc PRE-CREATION autotests/data/foo1rc PRE-CREATION autotests/data/foorc PRE-CREATION autotests/kdelibs4configmigratortest.cpp PRE-CREATION src/lib/CMakeLists.txt 26eb5a1 src/lib/util/kdelibs4configmigrator.h PRE-CREATION src/lib/util/kdelibs4configmigrator.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119895/diff/ Testing --- Thanks, Laurent Montel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: split kdepimlibs
Looks like you forgot to add the KDE PIM list :-) On Tuesday, 2014-08-26, 11:20:25, laurent Montel wrote: Hi, I will split kdepimlibs as it akonadi (need to find another name because it's still used) akonadi-abc Is that akonadi/kabc? akonadi-calendar akonadi-contact akonadi-mime akonadi-notes akonadi-socialutils gpgme++ kabc kalarmcal kblog kcalcore kcalutils kholidays kimap kioslave kldap kmbox kmime kontactinterface kpimidentities kpimtextedit kpimutils ktnef kxmlrpcclient mailtransport microblog qgpgme syndication Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: split kdepimlibs
On Tuesday, 2014-08-26, 12:32:48, laurent Montel wrote: Le mardi 26 août 2014 11:50:50 Kevin Ottens a écrit : On Tuesday 26 August 2014 11:20:25 laurent Montel wrote: Hi, I will split kdepimlibs as it akonadi (need to find another name because it's still used) akonadi-abc akonadi-calendar akonadi-contact akonadi-mime akonadi-notes akonadi-socialutils To me it sounds like some of those things could be regrouped now. What about also bringing the akonadi server on board? Having a bigger akonadi framework containing server (right now in kdesupport), some access libs and a few default plugins would make sense (it looks like a KIO like framework). Regroup as a framework as : akonadi-framework (better name) - src - akonadi-abc - akonadi-calendar - akonadi-contact - akonadi-mime - akonadi-notes - akonadi-socialutils - server (Dan must speak about it if he wants to move here) - plugins serializer (moved from kdepim-runtime) We have to assume that frameworks will end up in single package dependencies, so it would be nice to have Akonadi server separate so it remains installable on its own. One thing that should probably be considered is that the current libs mix non- UI and UI stuff, so some separation in between these lines might still be something to strive for. gpgme++ kabc kalarmcal kblog kcalcore kcalutils This one looks like a dumping ground of random things. Maybe some of it should move in other frameworks? Sergio can speak about it kholidays kimap kioslave Definitely not a framework. Are all the ioslaves in there still used? I think at least some of them can be let go. The others could go in kio-extras I guess. kioslave indeed not a framework. I think that just pop3 is used by kdepim yes others can move to kio-extra Is the Akonadi IO slave in there 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. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119895: New class for 5.2 to help user to migrate config files and ui file to new standardpath
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119895/#review65016 --- src/lib/util/kdelibs4configmigrator.h https://git.reviewboard.kde.org/r/119895/#comment45446 explicit Just a general question: do we really want a porting class in core addons? - Kevin Krammer On Aug. 22, 2014, 9:05 vorm., Laurent Montel wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119895/ --- (Updated Aug. 22, 2014, 9:05 vorm.) Review request for KDE Frameworks, David Faure and Kevin Krammer. Repository: kcoreaddons Description --- Class helps user to migrate config file and ui file to new location Diffs - src/lib/util/kdelibs4configmigrator.cpp PRE-CREATION autotests/CMakeLists.txt 75d1293 autotests/data/appui1rc PRE-CREATION autotests/data/appuirc PRE-CREATION autotests/data/foo1rc PRE-CREATION autotests/data/foorc PRE-CREATION autotests/kdelibs4configmigratortest.cpp PRE-CREATION src/lib/CMakeLists.txt 26eb5a1 src/lib/util/kdelibs4configmigrator.h PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119895/diff/ Testing --- Thanks, Laurent Montel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119895: New class for 5.2 to help user to migrate config files and ui file to new standardpath
On Aug. 22, 2014, 9:39 vorm., Laurent Montel wrote: Just a general question: do we really want a porting class in core addons? Laurent Montel wrote: Kdelibs4Migration is already in this addons. Where do you want to put it ? In which module ? I just found it strange. To me it is like having Qt3Support in QtCore. But I don't know what the goal of KDE core addons is, so providing compatibility stuff might very well be part of its scope. - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119895/#review65016 --- On Aug. 22, 2014, 9:05 vorm., Laurent Montel wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119895/ --- (Updated Aug. 22, 2014, 9:05 vorm.) Review request for KDE Frameworks, David Faure and Kevin Krammer. Repository: kcoreaddons Description --- Class helps user to migrate config file and ui file to new location Diffs - src/lib/util/kdelibs4configmigrator.cpp PRE-CREATION autotests/CMakeLists.txt 75d1293 autotests/data/appui1rc PRE-CREATION autotests/data/appuirc PRE-CREATION autotests/data/foo1rc PRE-CREATION autotests/data/foorc PRE-CREATION autotests/kdelibs4configmigratortest.cpp PRE-CREATION src/lib/CMakeLists.txt 26eb5a1 src/lib/util/kdelibs4configmigrator.h PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119895/diff/ Testing --- Thanks, Laurent Montel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119895: New class for 5.2 to help user to migrate config files and ui file to new standardpath
On Aug. 22, 2014, 9:39 vorm., Laurent Montel wrote: Just a general question: do we really want a porting class in core addons? Laurent Montel wrote: Kdelibs4Migration is already in this addons. Where do you want to put it ? In which module ? Kevin Krammer wrote: I just found it strange. To me it is like having Qt3Support in QtCore. But I don't know what the goal of KDE core addons is, so providing compatibility stuff might very well be part of its scope. David Faure wrote: Well, it's not the same. You want to be able to port away from Qt3support / kdelibs4support at some point, to stop linking to it. On the other hand, you need to keep calling kdelibs4migrator for the entire 5.x lifetime, since you can't know at which point the last users will switch. So you don't want such code in a compatibility library that you're trying to stop linking to. Well, that is only the case for applications which used to use kdelibs in their Qt4 version. It is just a single class for now, but if we also want to support data migration at some point this is going to need asynchronous copying, etc. adding to the complexity of a library targetted at more than just ported KDE applications, no? - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119895/#review65016 --- On Aug. 22, 2014, 10:55 vorm., Laurent Montel wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119895/ --- (Updated Aug. 22, 2014, 10:55 vorm.) Review request for KDE Frameworks, David Faure and Kevin Krammer. Repository: kcoreaddons Description --- Class helps user to migrate config file and ui file to new location Diffs - autotests/CMakeLists.txt 75d1293 autotests/data/appui1rc PRE-CREATION autotests/data/appuirc PRE-CREATION autotests/data/foo1rc PRE-CREATION autotests/data/foorc PRE-CREATION autotests/kdelibs4configmigratortest.cpp PRE-CREATION src/lib/CMakeLists.txt 26eb5a1 src/lib/util/kdelibs4configmigrator.h PRE-CREATION src/lib/util/kdelibs4configmigrator.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119895/diff/ Testing --- Thanks, Laurent Montel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119895: New class for 5.2 to help user to migrate config files and ui file to new standardpath
On Aug. 22, 2014, 9:39 vorm., Laurent Montel wrote: Just a general question: do we really want a porting class in core addons? Laurent Montel wrote: Kdelibs4Migration is already in this addons. Where do you want to put it ? In which module ? Kevin Krammer wrote: I just found it strange. To me it is like having Qt3Support in QtCore. But I don't know what the goal of KDE core addons is, so providing compatibility stuff might very well be part of its scope. David Faure wrote: Well, it's not the same. You want to be able to port away from Qt3support / kdelibs4support at some point, to stop linking to it. On the other hand, you need to keep calling kdelibs4migrator for the entire 5.x lifetime, since you can't know at which point the last users will switch. So you don't want such code in a compatibility library that you're trying to stop linking to. Kevin Krammer wrote: Well, that is only the case for applications which used to use kdelibs in their Qt4 version. It is just a single class for now, but if we also want to support data migration at some point this is going to need asynchronous copying, etc. adding to the complexity of a library targetted at more than just ported KDE applications, no? Laurent Montel wrote: For data, not all applications needs it. So I don't know if I will add in this class. But indeed if we need to put it in this class we need to make it async. But what is the problem with it ? As David wrote we need to have it in all kf5 life so we need to put it in a specific module and we can't put it in kdelibs4support module. I have to say I am not really sure what the goal here is. The base need is a way for applicaiton developers to find their old files, basically a KStandardDirs implementation. If we really want to provide tools on top of that, wouldn't a dedicated framework be a better choice? How likely does an application only have config and ui.rc and no data? - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119895/#review65016 --- On Aug. 22, 2014, 10:55 vorm., Laurent Montel wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119895/ --- (Updated Aug. 22, 2014, 10:55 vorm.) Review request for KDE Frameworks, David Faure and Kevin Krammer. Repository: kcoreaddons Description --- Class helps user to migrate config file and ui file to new location Diffs - autotests/CMakeLists.txt 75d1293 autotests/data/appui1rc PRE-CREATION autotests/data/appuirc PRE-CREATION autotests/data/foo1rc PRE-CREATION autotests/data/foorc PRE-CREATION autotests/kdelibs4configmigratortest.cpp PRE-CREATION src/lib/CMakeLists.txt 26eb5a1 src/lib/util/kdelibs4configmigrator.h PRE-CREATION src/lib/util/kdelibs4configmigrator.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119895/diff/ Testing --- Thanks, Laurent Montel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119895: New class for 5.2 to help user to migrate config files and ui file to new standardpath
On Aug. 22, 2014, 9:39 vorm., Laurent Montel wrote: Just a general question: do we really want a porting class in core addons? Laurent Montel wrote: Kdelibs4Migration is already in this addons. Where do you want to put it ? In which module ? Kevin Krammer wrote: I just found it strange. To me it is like having Qt3Support in QtCore. But I don't know what the goal of KDE core addons is, so providing compatibility stuff might very well be part of its scope. David Faure wrote: Well, it's not the same. You want to be able to port away from Qt3support / kdelibs4support at some point, to stop linking to it. On the other hand, you need to keep calling kdelibs4migrator for the entire 5.x lifetime, since you can't know at which point the last users will switch. So you don't want such code in a compatibility library that you're trying to stop linking to. Kevin Krammer wrote: Well, that is only the case for applications which used to use kdelibs in their Qt4 version. It is just a single class for now, but if we also want to support data migration at some point this is going to need asynchronous copying, etc. adding to the complexity of a library targetted at more than just ported KDE applications, no? Laurent Montel wrote: For data, not all applications needs it. So I don't know if I will add in this class. But indeed if we need to put it in this class we need to make it async. But what is the problem with it ? As David wrote we need to have it in all kf5 life so we need to put it in a specific module and we can't put it in kdelibs4support module. Kevin Krammer wrote: I have to say I am not really sure what the goal here is. The base need is a way for applicaiton developers to find their old files, basically a KStandardDirs implementation. If we really want to provide tools on top of that, wouldn't a dedicated framework be a better choice? How likely does an application only have config and ui.rc and no data? David Faure wrote: I think Laurent is thinking of kdepim, where the data (akonadi DB etc.) was already in XDG dirs anyway, so it doesn't need to be migrated. Many other apps don't have local data at all (okular, gwenview, kolourpaint, etc. etc.). At most a config file and ui.rc files, which is now covered. Apps with specific data would have to handle that specifically anyway. So we're left with two classes (one returning paths and one migrating the common case of foorc and fooui.rc), which pollute kcoreaddons to avoid creating a whole framework just for two classes. I can't exactly see how this would be a problem for other kcoreaddons users though. They're not using all of the QtCore classes either, for sure :-) As I said before, it just felt weird to me. As for data, I have more than 100 subdirs in .kde/share/apps, including okular and gwenview. could be empty, but apparently something created them - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119895/#review65016 --- On Aug. 22, 2014, 10:55 vorm., Laurent Montel wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119895/ --- (Updated Aug. 22, 2014, 10:55 vorm.) Review request for KDE Frameworks, David Faure and Kevin Krammer. Repository: kcoreaddons Description --- Class helps user to migrate config file and ui file to new location Diffs - autotests/CMakeLists.txt 75d1293 autotests/data/appui1rc PRE-CREATION autotests/data/appuirc PRE-CREATION autotests/data/foo1rc PRE-CREATION autotests/data/foorc PRE-CREATION autotests/kdelibs4configmigratortest.cpp PRE-CREATION src/lib/CMakeLists.txt 26eb5a1 src/lib/util/kdelibs4configmigrator.h PRE-CREATION src/lib/util/kdelibs4configmigrator.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119895/diff/ Testing --- Thanks, Laurent Montel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: How to promote less mature Frameworks?
On Wednesday, 2014-08-20, 12:14:31, Aleix Pol wrote: It would be very interesting to have somebody working on kdepimlibs around. I keep hearing that they will be available soon, but I still ignore whether the people doing the work want the kdepimlibs to become KDE Frameworks (they didn't want them to be part of kdelibs already, so there must be reasons). The libs were moved out of kdelibs at that time for different reasons, e.g. gettting them packages separately for better dependency control. Development follows the same policies as for kdelibs. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
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: Writing a unit test to test support for proxied connections in a computer that is not behind a proxy?
Hi, On Saturday, 2014-08-09, 17:14:26, Adrián Chaves Fernández wrote: Has anyone here ever written a unit test to test support for proxied connections in a computer that is not behind a proxy? Do you think that it is possible? Specifically testing that the software uses the (KDE) system-wide proxy settings?” What would you like to check for? I guess your test could create a QTcpServer instance and have it listen on an arbitrary port. It would then generate or alter the test environments proxy config to point to that ip/port and then check if your server gets the connection that your code under test opens. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
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: [Kde-hardware-devel] Question Akonadi Contact
Hi, cross-posting to the kde-pim list which is the appropriate one for questions regarding the PIM stack to which Akonadi belongs. On Saturday, 2014-07-19, 10:43:28, 桥 杨 wrote: Hello ! I would like to know how to get the default collection for adding a contact in Akonadi. I am not sure but I think we currently don't have any particular collection marked as the default addressbook. We do have a mechanism for something like that, calles SpecialCollections, but I think we currently use that for contacts. Or is there a simpler interface to add/modify/delete contacts? (Like calendar has had a simplified interface to do all these operations). Thanks! Hmm, I don't think so, but the kpeople library might have such interfaces. Any particular use case you are trying to solve? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
Re: [kde-promo] The name of Applications 4.14 + 1
On Thursday, 2014-07-17, 01:19:45, Albert Astals Cid wrote: Hi all, please let's keep future discussion in kde-promo since i think this is more a promo related thing than anything. A while ago we decided that 4.14 will be the last KDE 4 Applications release and that after that we would switch (at least for a while) to application releases where applications are either kdelibs4 based or KF5 based (on a tarball/repository level). Now we need a name for that thing. * We can't call it 4.15 since the 4.x in there for everybody means based in kdelibs4.x * We can't call it 5.x since the 5.x in there will make people think all apps are KF5.x based Are these really a concern? I would go for 5.x as a new epoch of releases. Each application has its own dependencies, whether these are KDE libraries or Qt or domain specific ones, each having their own versioning scheme and current numbers. Some applications even have their own version numbers, so this will only be the version for the bundle, 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. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Web Shortcuts KCM
On Wednesday, 2014-07-16, 10:33:43, David Faure wrote: On Tuesday 15 July 2014 15:16:20 Kevin Ottens wrote: (ie at most a widget would be enough for the app related settings, we should talk to the underlying platform for the other ones). I don't want users to have to configure their search engines in 10 KDE apps one after the other by hand. A centralized configuration is much more convenient. Hmm, what if KDE applications outside a KDE workspace are seen as separate entities by users of those other workspaces? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE + Firefox integration: restart?
First of all, thanks for stepping up and getting the discussion going again. One thing that strikes me as wrong though, considering the comments on the Firefox list, is that this is phrased as KDE Integration. Using the KDE file dialog would be KDE specific integration, using the user configured default application for a certain task is not. That would be Free Software Desktop integration, i.e. folling the mime-apps- spec: http://www.freedesktop.org/wiki/Specifications/mime-apps-spec/ Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: KDE + Firefox integration: restart?
On Tuesday, 2014-07-08, 08:49:24, grantksupp...@operamail.com wrote: Hi On Tue, Jul 8, 2014, at 08:43 AM, Kevin Krammer wrote: First of all, thanks for stepping up and getting the discussion going again. One thing that strikes me as wrong though, considering the comments on the Firefox list, is that this is phrased as KDE Integration. Using the KDE file dialog would be KDE specific integration, using the user configured default application for a certain task is not. That would be Free Software Desktop integration, i.e. folling the mime-apps- spec: http://www.freedesktop.org/wiki/Specifications/mime-apps-spec/ I don't know enough to know the correct semantics. I do know: (1) 'this' has been talked about for a very long time, admittedly in 'drips and drabs', as a KDE + Firefox issue. Specifically getting Firefox to use Dolphin. (2) The Opensuse 'patches' have been specifically for use in KDE, and have been called in packaging 'mozilla-kde4-integration' and 'kmozillahelper' Sure, but time has moved on and default application handling is now covered by a cross-desktop specification. This is no longer about having KDE Workspace specific code, framing it as such hides the actual scope. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: [opensuse-factory-mozilla] Re: KDE + Firefox integration: restart?
On Tuesday, 2014-07-08, 09:04:39, grantksupp...@operamail.com wrote: Hi, On Tue, Jul 8, 2014, at 08:59 AM, Kevin Krammer wrote: Sure, but time has moved on and default application handling is now covered by a cross-desktop specification. This is no longer about having KDE Workspace specific code, framing it as such hides the actual scope. Would that by chance be the 'xdg-tools file dialog' as used by Google Chrome already, Use KDE file dialogs https://sublimetext.userecho.com/topic/152179-use-kde-file-dialogs/ No, kdialog usage is indeed KDE tools specific. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: code convention
On Saturday, 2014-06-28, 08:52:53, Rodrigo Bonifacio wrote: Dear all, is there any code guideline that recommends developers to avoid the use of exception handling mechanisms in KDE applications? This is primarily a result of Qt only being partially exception safe: http://qt-project.org/doc/qt-5/exceptionsafety.html It is probably not documented separately again on KDE's side. You can always use exceptions if you make sure they never leave your code into Qt's code, e.g. catch them in slots so they don't get into the signal/slot code. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: UPnP library for Qt
On Sunday, 2014-06-29, 12:25:43, Shantanu Tushar Jha wrote: Hey folks, One of the things we wanted to implement in Plasma Media Center is DLNA/UPnP support. A quick search seems to suggest https://code.google.com/p/qupnp/ for Qt projects. Has anybody used it in their projects or have any other suggestions? Or, should we directly use GUPnP with a wrapper? I think I read somewhere that there is a UPnP KIO slave. So it might be worth looking for it and checking what it 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. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: KDE applications 4.14 LTS or 4.15?
On Wednesday, 2014-06-04, 09:52:59, Mario Fux wrote: Am Mittwoch, 04. Juni 2014, 00.53:36 schrieb Albert Astals Cid: Morning [snip] My conclusion of this is: - 4.14 is LTS with a relaxed string and feature freeze (though ask before you do) like KDE 3.5.10 (or what it was). - Towards the end of 2014 we can start to release KDE applications based on KDE Platform 4 and based on KF5 together and decide then next year how we do KF5based application releases in the future and which modules and Co. - Definitely end Qt4/Platform 4 based releases in August 2015 (when Plasma LTS ends) from the KDE side Please speak up if you don't like this/want this otherwise I'll write an email with these conclusions at the end of next week. I'm not sure i agree or maybe i don't understand what you mean :D Are you waying that we should - Do 4.14 LTS *and* - Release kdelibs4-based apps + KF5-based apps late in the year? I see this things as one or the other, don't see what the 4.14 LTS gives us if we are going to continue releasing kdelibs4-based apps and for those that are stable we have KF5-based. That means a lot of work for devels, since we need to again care about 3 branches: - 4.14 LTS - 2014.12 release - trunk I'm not sure what 4.14 LTS adds to the mix if we are just going to do mix releases of kdelibs4+kf5-based apps. Yes, you're right. Both (4.14 LTS and a bundle) wouldn't work. It's what you said: - Release KDE Applications 4.14 as we did for 4.13 - And then from December onwards release bundles of kdelibs4/qt4 and kf5 based application (for the kdelibs4/qt4 apps this would be like LTS: not really new feature, mostly bug fixes and gradually porting to KF5). Well, the latter depends on the application developers' road maps. Some might prefer continued feature development on Qt4 over porting. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
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: KDE applications 4.14 LTS or 4.15?
On Tuesday, 2014-04-29, 19:32:04, Albert Astals Cid wrote: El Dimarts, 29 d'abril de 2014, a les 18:13:20, Mario Fux va escriure: But this email is mostly about if we should stop KDE applications releases with 4.14 (stop feature development I mean) and make a LTS release out if it (likewise to the KDE Workspaces/Plasma did with 4.11.x till August 2015) or if we want more feature development in the KDE Applications with Qt4 and KDE Platform 4 and thus target a 4.15 release. I honestly don't think you can decouple the discussion of KF5 versions of apps and its release schedule from the question of what is going to happen with 4.x releases. If you tell me that the first KDE Applications based in KF5 is going to be in two years because people don't have time to port, i obviously want 4.15, 4.16 and more, if you tell me it's going to be in a year, i have different opinion. Anyway I still think we should mixmatch as I proposed in the other email. I agree. If the proposal is to discontinue traditional SC released (platform+workspaces+applications) in favor of a form of Applications SC (just applications, no platform or workspaces), then it really doesn't matter which external dependencies each application is targetting. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: KDE applications 4.14 LTS or 4.15?
On Friday, 2014-04-25, 21:09:34, Mario Fux wrote: Morning gals and guys First: there are several mailing lists in the TO: above but please just write to the kde-devel mailing list for this discussion. As the release schedule for our KDE applications in the version 4.14 [1] were finalized at the beginning of this week it's time to discuss if 4.14 should become a LTS release (e.g. until August 2015 like KDE Workspaces 4.11) or if we need (at least) another features release and thus 4.15? I am not sure I understood this correctly. The proposal is to end 4.x SC releases at 4.14 and either not do any SC until all applications have been ported or discontinue the SC releases alltogether? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Review Request 117511: Add class for finding the kde4 config and apps home dirs.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117511/#review56172 --- src/lib/util/kdelibs4migration.cpp https://git.reviewboard.kde.org/r/117511/#comment39207 would QStringLiteral work here? src/lib/util/kdelibs4migration.cpp https://git.reviewboard.kde.org/r/117511/#comment39204 Hmm. I think that looks weird. Can this be split in the type definition (struct something) and the constant defintion? src/lib/util/kdelibs4migration.cpp https://git.reviewboard.kde.org/r/117511/#comment39205 Also maybe just a personal taste, but I find it better to explicitly use parentheses when mixing boolean and arithmetic operators, i.e. make it explicit which operator has precendence. In this case putting parentheses around the size calculation. Or even calculating the size as a const int before the loop (can it be done as a const_expr outside the function?). src/lib/util/kdelibs4migration.cpp https://git.reviewboard.kde.org/r/117511/#comment39208 Do we have some logging categories for kdecoreaddons? - Kevin Krammer On April 22, 2014, 9:32 a.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117511/ --- (Updated April 22, 2014, 9:32 a.m.) Review request for KDE Frameworks, Ivan Čukić and Kevin Krammer. Repository: kcoreaddons Description --- Add class for finding the kde4 config and apps home dirs. To help applications migrating to the kf5/qt5 directories. Diffs - autotests/CMakeLists.txt 2f14b3a229b07071ed6e8b0772e03ee798db6c03 autotests/kdelibs4migrationtest.cpp PRE-CREATION src/lib/CMakeLists.txt 39ca3b8e9d5a4f8ffa06ca2ccf017b02ac245fd7 src/lib/util/kdelibs4migration.h PRE-CREATION src/lib/util/kdelibs4migration.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/117511/diff/ Testing --- Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117511: Add class for finding the kde4 config and apps home dirs.
On April 22, 2014, 9:50 a.m., Kevin Krammer wrote: src/lib/util/kdelibs4migration.cpp, line 97 https://git.reviewboard.kde.org/r/117511/diff/2/?file=267469#file267469line97 Also maybe just a personal taste, but I find it better to explicitly use parentheses when mixing boolean and arithmetic operators, i.e. make it explicit which operator has precendence. In this case putting parentheses around the size calculation. Or even calculating the size as a const int before the loop (can it be done as a const_expr outside the function?). Or as a std:find_if()? Sorry, have just watched a Going Native talk about no raw loops :) - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117511/#review56172 --- On April 22, 2014, 9:32 a.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117511/ --- (Updated April 22, 2014, 9:32 a.m.) Review request for KDE Frameworks, Ivan Čukić and Kevin Krammer. Repository: kcoreaddons Description --- Add class for finding the kde4 config and apps home dirs. To help applications migrating to the kf5/qt5 directories. Diffs - autotests/CMakeLists.txt 2f14b3a229b07071ed6e8b0772e03ee798db6c03 autotests/kdelibs4migrationtest.cpp PRE-CREATION src/lib/CMakeLists.txt 39ca3b8e9d5a4f8ffa06ca2ccf017b02ac245fd7 src/lib/util/kdelibs4migration.h PRE-CREATION src/lib/util/kdelibs4migration.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/117511/diff/ Testing --- Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Baloo Indexer and options
On Tuesday, 2014-04-22, 08:10:37, Lindsay Mathieson wrote: On Mon, 21 Apr 2014 05:57:51 PM Nathan Bradshaw wrote: They do. They can be turned off via the UI, Nope. ok, no longer worth having a discussion if you can't muster a better response than this I was referring to the UI as is. I'm glad that Vishesh is considering adding an option for disabling it, but not there yet. And there are no options for customising the default file type exclusions in the UI, that means they are not defaults, but effectively hard coded. Nor for setting up a white list - Vishesh has point blank ruled that out. Apparently users do not need that level of configuration. Hmm, what about an additional UI? As far as I know there is no enforces one-to-one mapping of KCM and service/config file, basically any KCM can change any config. If we had an alternative KCM that exposes more features of the underlying config then OSVs and/or sysadmins could decide which one (or both) would show up in systemsettings depending on their users' needs. It also makes it great for user support when one can have a kcmshell4 something command which will open advanced settings for people who need it without having to fall back to giving instructions how to manually edit a file. Eventually the simple KCM could even gain a button or similar to show the advanced UI on demand. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Baloo Indexer and options
On Monday, 2014-04-21, 16:53:16, Michael Jansen wrote: This has been discussed in detail at http://lists.kde.org/?l=kde-develm=139606131629659w=2 . tl;dr - There won't be an option to disable Baloo or an include list. Baloo might however show list of currently indexed dirs. I really hope they reconsider. I was always a fan of nepomuk. Used it all the time. Improved it with small patches and quite some patches for crashes. Worked with them on performance issues. This is the first time i consider disabling it completely myself. Because it seems its going in a direction that completely breaks my style of work. And puts me into potential legal troubles. I mount devices and network storage INTO my home directory. Sometimes by putting the mount point into my home directory, sometimes by symlinking it into my home directory. I create a LOT of directories directly in my home directory I DO NOT WANT TO BE INDEXED AT ALL. And don't insult me by telling me to blacklist each and every directory i create there manually or change my workflow. If i don't get a whitelist this stuff is useless for me. Why? My assumption would be that it behaves like rsync does, i.e. stays on the some file system. I have a similar setup, i.e. different volumes symlinked into subdirs of $HOME for access convenience, and rsync does not attempt to copy those when I use it for backup. Since Baloo or its KCM seems to already do mount point and device detection I would assume that it resolves mounts/symlinks before it checks its config. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Baloo Indexer and options
On Monday, 2014-04-21, 17:25:55, Nathan Bradshaw wrote: On Mon, Apr 21, 2014 at 5:02 PM, Lindsay Mathieson lindsay.mathie...@gmail.com wrote: On Mon, 21 Apr 2014 04:44:33 PM Nathan Bradshaw wrote: yes it can. remove $home and it is turned off. And for a number of people it doesn't. And yes this is a bug, which no doubt will be fixed. But this is also why you give people options and overrides - bugs happen and its arrogant to assume they won't. why do you think a checkbox linked to the deactivation functionality would be different to it being triggered by removing $home? It is probably a matter of user expectation regarding how certain interface elements affect functionality. A checkbox and similar elements are known for on/off things. An empty white list might come close. A blacklist with one item, on the other hand, requires to know that the blacklisted item is the default whitelisted item. I don't think the interface choice does necessarily imply a change in the config itself, i.e. a checkbox could still manipulate the blacklist/whitelist accordingly. Things like that are often used elsewhere, e.g. a toggle of some kind being in the user inetrface but the state being encoded as a special value for a field that is enabled/disabled by the toggle control. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Baloo Indexer and options
On Monday, 2014-04-21, 20:28:36, Vishesh Handa wrote: Hell, maybe all file indexing should just be disabled by default. I was thinking about that as well, in a larger context than just indexing. I.e. I was thinking if we could come up with a general UI concept of hinting that a feature is disabled but can be enabled. Currently we most often only show enabled/disabled via the respective widget property, but it would often be benefitial to indicate that this is not because of something impossible in the current context but as a result of a choice elsewhere. For example in the context of search a disabled indexer would lead to zero results, so a search UI would probably be shown as disabled. In a kind of tri-state fashion it could indicate not available on your own request. Ultimately this could even hint at something optional not having been installed yet. Anyway, until such a time, would it be possible to find interaction points which could detect the state and offer to turn things on? I vaguely remember that Explorer on Windows suggesting to me to enable indexing for a directory I triggered a search in. Basically whitelisting from within the search interface Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Review Request 117511: Add class for finding the kde4 config and apps home dirs.
On April 12, 2014, 11:12 a.m., Kevin Krammer wrote: I wonder if this really belongs in kdecoreaddons. I.e. it is only relevant for KDE applications porting, right? IMHO this would fit best in an explicit porting framework David Faure wrote: I don't want to put this in kdelibs4support because apps are supposed to port away from that and stop linking to it (thus avoiding I link to everything), while they are supposed to keep the migration code for quite some time (not everyone will upgrade to 5.0 right away). I don't think it makes sense to create yet another framework for one class. We are going crazy already with the number of frameworks and the small size of some of them. So this leaves kcoreaddons, unless you have a better suggestion. Kevin Ottens wrote: If that's really only about configuration, why not kconfig? That's where we have the config update tooling too. I'd find it less surprising there. If not strictly about configuration kcoreaddons seems the only sane option indeed. Kevin Krammer wrote: It is not just for config, there is already a function for returning KDE data home. However that brings up a new question from me: what about the other resource types? If I were to port away from KStandardDirs I would like to be able to find old locations of my files and my access right now might not be to just config and data. All my initial assumptions on porting were based on KStandardDirs still existing and finding the paths as usual. My understanding is taht this is no longer true, i.e. because KStandardDirs behaves differently in the porting framework version. So this legacy dir support class needs to be basically be KStandardDirs's user local implementation, e.g. allowing locate(), etc. David Faure wrote: Which other resource types would be useful, exactly? In my ~/.kde4/share, apart from config and apps, I can only see (after cleaning up some useless cruft like applnk and mimelnk) wallpapers and kde4/services (due to a locally-defined searchprovider). Most services would be kde4 plugins that wouldn't make sense in kf5 though. I can move my custom searchproviders definitions by hand ;) Anything else you guys have? locate() is not very useful in the context of migrations: it searches at all levels, while we only want to care for files in the user's home. This is why most of the KStandardDirs logic doesn't really apply anymore. locateLocal() is basically what we're doing with QFile::exists(configHome()+kfoorc). wallpapers is however a good example of a resource type that is missing. So maybe we can make this based on resource strings again like kstandarddirs used to be, to support the resources that make sense without adding too much api... ? Yes, locateLocal(), sorry. Didn't mean that resource lookup would need to search the hierarchy, just that it might be nice for migration code to be able to use the same resource identifiers. That is if your application is currently doing something like dirs.saveLocation(resourceType, fileName); the respective migration code could find the file using an as close as possible syntax, e.g. migration.saveLocation(resourceTpype, fileName) or locateLocal() I.e. right now application developers do not need to know how resource types are mapped onto subdirectories, so having the same kind of lookup helper would be nice. - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117511/#review55504 --- On April 12, 2014, 11:01 a.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117511/ --- (Updated April 12, 2014, 11:01 a.m.) Review request for KDE Frameworks, Ivan Čukić and Kevin Krammer. Repository: kcoreaddons Description --- Add class for finding the kde4 config and apps home dirs. To help applications migrating to the kf5/qt5 directories. Diffs - autotests/CMakeLists.txt 7ab7bc43be1434ae93f7c77af90e41bbde5168ac autotests/kdelibs4migrationtest.cpp PRE-CREATION src/lib/CMakeLists.txt 1d17874f0da428bd34ea85ee98683f6fef620c81 src/lib/util/kdelibs4migration.h PRE-CREATION src/lib/util/kdelibs4migration.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/117511/diff/ Testing --- Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117511: Add class for finding the kde4 config and apps home dirs.
On April 12, 2014, 11:12 a.m., Kevin Krammer wrote: I wonder if this really belongs in kdecoreaddons. I.e. it is only relevant for KDE applications porting, right? IMHO this would fit best in an explicit porting framework David Faure wrote: I don't want to put this in kdelibs4support because apps are supposed to port away from that and stop linking to it (thus avoiding I link to everything), while they are supposed to keep the migration code for quite some time (not everyone will upgrade to 5.0 right away). I don't think it makes sense to create yet another framework for one class. We are going crazy already with the number of frameworks and the small size of some of them. So this leaves kcoreaddons, unless you have a better suggestion. Kevin Ottens wrote: If that's really only about configuration, why not kconfig? That's where we have the config update tooling too. I'd find it less surprising there. If not strictly about configuration kcoreaddons seems the only sane option indeed. It is not just for config, there is already a function for returning KDE data home. However that brings up a new question from me: what about the other resource types? If I were to port away from KStandardDirs I would like to be able to find old locations of my files and my access right now might not be to just config and data. All my initial assumptions on porting were based on KStandardDirs still existing and finding the paths as usual. My understanding is taht this is no longer true, i.e. because KStandardDirs behaves differently in the porting framework version. So this legacy dir support class needs to be basically be KStandardDirs's user local implementation, e.g. allowing locate(), etc. - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117511/#review55504 --- On April 12, 2014, 11:01 a.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117511/ --- (Updated April 12, 2014, 11:01 a.m.) Review request for KDE Frameworks, Ivan Čukić and Kevin Krammer. Repository: kcoreaddons Description --- Add class for finding the kde4 config and apps home dirs. To help applications migrating to the kf5/qt5 directories. Diffs - autotests/CMakeLists.txt 7ab7bc43be1434ae93f7c77af90e41bbde5168ac autotests/kdelibs4migrationtest.cpp PRE-CREATION src/lib/CMakeLists.txt 1d17874f0da428bd34ea85ee98683f6fef620c81 src/lib/util/kdelibs4migration.h PRE-CREATION src/lib/util/kdelibs4migration.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/117511/diff/ Testing --- Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
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: Review Request 117511: Add class for finding the kde4 config and apps home dirs.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117511/#review55504 --- I wonder if this really belongs in kdecoreaddons. I.e. it is only relevant for KDE applications porting, right? IMHO this would fit best in an explicit porting framework src/lib/util/kdelibs4migration.cpp https://git.reviewboard.kde.org/r/117511/#comment38618 initialize d to nullptr? - Kevin Krammer On April 12, 2014, 11:01 a.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117511/ --- (Updated April 12, 2014, 11:01 a.m.) Review request for KDE Frameworks, Ivan Čukić and Kevin Krammer. Repository: kcoreaddons Description --- Add class for finding the kde4 config and apps home dirs. To help applications migrating to the kf5/qt5 directories. Diffs - autotests/CMakeLists.txt 7ab7bc43be1434ae93f7c77af90e41bbde5168ac autotests/kdelibs4migrationtest.cpp PRE-CREATION src/lib/CMakeLists.txt 1d17874f0da428bd34ea85ee98683f6fef620c81 src/lib/util/kdelibs4migration.h PRE-CREATION src/lib/util/kdelibs4migration.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/117511/diff/ Testing --- Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
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: Is Konqueror still a live project?
On Monday, 2014-03-31, 15:13:22, Josh Liberty wrote: I'm not trying to bash anyone, I'm just really wondering about that. Is rekonq good enough for most KDE users (I find that hard to believe)? Is everyone just using Firefox/Chrome? I am using Konqueror. Have been for many, many years :-) Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Is Konqueror still a live project?
On Tuesday, 2014-04-01, 06:54:36, Lindsay Mathieson wrote: No extensions/plugins - there's a number of extensions in firefox I just don't wwant to do without. However Aandrea is porting rekonq to K5 and there is a proposal for an extension api. For me extensions are close to being a must have feature for browsers. The abiulity to write them and a broad range of them. The question is how you define an extension. Konqueror had extensions/plugins for many years, the difference to those of other browsers is that they are written in C++ instead of JavaScript. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Move KDED out of frameworks?
On Saturday, 2014-03-29, 01:21:24, Aleix Pol wrote: On Fri, Mar 28, 2014 at 9:14 PM, Kevin Krammer kram...@kde.org wrote: I thought I was obvious that I was addressing the Aleix's concern about portability of frameworks requiring D-Bus, but I must have failed at that. I'll try to make it more clear: a framework that can be built on a platform, run on that platform and provide its functionality on that platform can be considered supported on that platform. And, additionally, the whole point of having different frameworks is the ability to choose which ones to use, which at least for me implied not having to use a framework that does not provide any features an application needs. Cheers, Kevin Well, I think that what Boudewijn means is that even though we can use DBus on Windows, we might not really want to. Not only for deployment constraints but also because then you need to take care of having it running and management. It can be more of a promo statement more than actual technical advice, but I prefer happy users of few frameworks than slightly frustrated users of many frameworks... I am not saying that we have to use D-Bus in frameworks that require out-of- process components, we can of course always use a hand crafted communication mechanism based on QLocalSocket/-Server, even on platforms that have D-Bus as part of the system installation. I am just saying that frameworks using D-Bus can be used on more platforms than just Linux. All frameworks with dynamic dependencies need to have deployment documentatation. Whether that is bundling a D-Bus installer or bundling plugins and setting custom search paths or bundling a plugin installer. And, most importantly, it is the application developer's choice which frameworks they need and which just optionally use on certain platforms. I just don't see a point in telling application developers that a certain framework is not available on certain platforms when in fact it is but some application developers might chose not to use it due to deployment requiremens. Qt doesn't restrict its supported platforms to Linux just because that is the platform where it comes pre-installed. If a platform without system Qt is widely used there can even be initiatives to remedy that somewhat, like Ministro does on Android. In other words, I don't think it's enough to be able to build and run. I think that it's fundamental also to be able to deploy it and provide an seamless and integrated experience to the user. Of course, I never stated anything to the contrary. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move KDED out of frameworks?
On Friday, 2014-03-28, 12:54:42, Aleix Pol wrote: On Fri, Mar 28, 2014 at 12:32 PM, Àlex Fiestas afies...@kde.org wrote: On Friday 28 March 2014 11:30:25 Alex Merry wrote: In principle, I agree. In practice, a lot of our frameworks have a runtime dependency of some sort on it.[0] Alex [0]: http://lxr.kde.org/search?v=kf5-qt5_filestring=_string=kded5 I can't talk for other frameworks but in the case of Solid it is a mistake since it makes code that is cross-platform not cross-platform anymore. During the next week I will either remove that or make it platform specific (kde integration). Well yes, actually we should (re-)consider whether frameworks that depend on QtDBus in general if they're cross-platform or not. [1] D-Bus does run on most platforms, at least on desktop. There was a thread on the Qt development list a short while ago which discussed enabling QtDBus by default in Windows and Mac builds. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move KDED out of frameworks?
On Friday, 2014-03-28, 20:26:59, Boudewijn Rempt wrote: On Fri, 28 Mar 2014, Kevin Krammer wrote: D-Bus does run on most platforms, at least on desktop. There was a thread on the Qt development list a short while ago which discussed enabling QtDBus by default in Windows and Mac builds. It might 'run' -- but I still wouldn't want to distribute any application that uses dbus on windows or osx. In fact, for krita on Windows, I've hacked kdelibs 4 to disable dbus completely, and I'd do the same for osx, if I had the time. Just answering the questions of the people who get worried by their firewalls or other security software reporting DANGER! because dbus tries to make a local network connection is already too much of a pain. I know, that is currently a problem of the Windows port, i.e. it using TCP instead of named pipes which are more an equivalent to Unix sockets. (as evident by QLocalSocket/-Server using that instead). The D-Bus session/user daemon is also something that needs to be treated in a platform specific way as a dependency. E.g. on Windows there could be a D-Bus installer that applications bundle and run if necessary, very much like Games bunlding an DirectX installer. Such a D-Bus installer would also register a startup hook that runs D-Bus on session start or user login, whatever makes sense for the platform. Frameworks that need D-Bus, e.g. KIO would then have the D-Bus installation as a deployment requirement. As with all frameworks it is up to the application developer which one they want to depend on and which one they treat as options. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move KDED out of frameworks?
On Friday, 2014-03-28, 20:55:02, Boudewijn Rempt wrote: On Fri, 28 Mar 2014, Kevin Krammer wrote: The D-Bus session/user daemon is also something that needs to be treated in a platform specific way as a dependency. E.g. on Windows there could be a D-Bus installer that applications bundle and run if necessary, very much like Games bunlding an DirectX installer. Oh no, I never would do that... It would still cost me many hours of my life dealing with it, and it would still give my users no advantage at all. There just isn't any reason an application like Krita would need an ipc solution -- and any library that insists on coming with one is just not going to make the cut. I thought I was obvious that I was addressing the Aleix's concern about portability of frameworks requiring D-Bus, but I must have failed at that. I'll try to make it more clear: a framework that can be built on a platform, run on that platform and provide its functionality on that platform can be considered supported on that platform. And, additionally, the whole point of having different frameworks is the ability to choose which ones to use, which at least for me implied not having to use a framework that does not provide any features an application needs. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
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: Query: Possible code contribution
Hi, On Wednesday, 2014-03-19, 23:36:27, Harsh Kumar wrote: On 3/16/14, Kevin Krammer kram...@kde.org wrote: One other thing that came to my mind is development of examples for Frameworks 5, see [1] and [2]. Only a couple of the frameworks seem to have an examples subdirectory. I think it would be both a valuable and self-contain contribution to make sure that as many frameworks as possible have good example programs. Maybe even having tutorials on techbase.kde.org explaining the steps that were necessary to create the examples. I can write some examples as I have some time want to contribute. However, I will need some guidance. I found a examples directory in karchive. Is that what is required? Yes, that is what I had in mind. Can someone please suggest a framework which is simple with which I can start creating examples? Good question. All the Tier 1 in this list [1] should be a good start since they do not depend on anything other than Qt itself. I am not sure how simple they are or if they have examples already. Maybe Sonnet or Solid would be interesting to work with? Cheers, Kevin [1] http://community.kde.org/Frameworks/List -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: video audio preview dolphin
Hi, On Saturday, 2014-03-15, 20:17:47, Nowardev-Team wrote: Hi i have modified a little dolphin like you can see here http://www.youtube.com/watch?v=-zHatr2_xHQ but the sick stuff it's the video that is not shown can someone help me ? Do you mean that the video is preview seems to just show one still image? i get this message here QLayout: Attempting to add QLayout to PhononWidget , which already has a layout Doesn't look like your fault, your change doesn't introduce a new layout. diff file http://wklej.org/id/1300553 this is the file phononwidget.cpp http://wklej.org/id/1300532 Does the video play without your modifications? CC'ing kfm-devel since we are talking about a Dolphin modification 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. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Query: Possible code contribution
On Sunday, 2014-03-16, 00:16:45, Lydia Pintscher wrote: On Fri, Mar 14, 2014 at 2:40 PM, Ganesh Kumar gp29111...@gmail.com wrote: Hi. This is Ganesh P Kumar, doing my B.Tech in Computer Science and Engineering in IIT Madras. As part of our curriculum we must contribute code to an open source project. There is a deadline of 40 days for the project submission. Given this small deadline, I would like to ask for suggestions from the KDE Developer group about what would be a viable project during this time. We are ok with working either with the KDE UI as such, or with any KDE subproject. Also, I would like to add that none of us have any dev experience in KDE before. Would a project to fix several small little issues be viable? Then you could maybe work with the designers/usability team and help them out a bit. 40 days is really not much. One other thing that came to my mind is development of examples for Frameworks 5, see [1] and [2]. Only a couple of the frameworks seem to have an examples subdirectory. I think it would be both a valuable and self-contain contribution to make sure that as many frameworks as possible have good example programs. Maybe even having tutorials on techbase.kde.org explaining the steps that were necessary to create the examples. CCing the frameworks development list. Cheers, Kevin [1] https://dot.kde.org/2014/03/04/kde-frameworks-5-alpha-two-out [2] http://community.kde.org/Frameworks -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Frameworks book
On Sunday, 2014-03-16, 11:50:26, David Faure wrote: On Saturday 15 March 2014 02:08:52 Valorie Zimmerman wrote: Hello frameworks developers, It has been discussed on the KDE-Community list that some of you would like a Frameworks book. I would strongly suggest that this is not ONLY a paper book but also an online book where updates get published, e.g. like the french Qt5 book works. Not sure this would work here but a couple of months back I bought a NodeJS book on LeanPub [1] and since then I get notification emails when a new version has been published and can be downloaded again. Cheers, Kevin [1] https://leanpub.com/ -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: What to test for 4.13?
Hi Marko, On Saturday, 2014-03-15, 16:04:24, mk-li...@email.de wrote: Hi Kevin, And I won’t consider MacPorts' installation from sources as a design flaw, it is partly just a development state on the way to become an open-source software distribution system (not only) for Apple’s MacOSX. If I am not mistaken you can run MacPorts also on Linux. :-) I didn't mean to imply or suggest that the design was flawed or anything like that. I was just wondering if the group was targetting a different audience. Ian wrote something about build dependencies and building which kind of didn't go well with my mental model of Mac users. I hardly know any Mac user who would build software so they would not be affected by build dependencies. Several postings later my understanding is that Macports do have binary packages as well, which would solve Ian's concerns and be more in line with what my Mac users would be looking for. Also one has to point out that MacPorts DELIBERATELY does not distribute port binaries which use code with a licence which isn’t allowing binary distribution. This is good and considerate design in my eyes. Right. Doesn't apply to KDE software but certainly the right thing to do in the wider scope. Maybe there are some non-KDE packages which require the libsdl library and they require the +x11 variant, so then everybody gets it. Just as KGoldrunner gets Nepomuk, et al. … ;-) That is a serious packaging problem then. Yes, it’s hugely difficult to get KDE applications to build without any X11 deps. Any idea why? Most applications should not have any X11 dependency, those available on Windows definitely don't. Or rather there seems to be a huge gap between the target audience of the mac packaing effort and the people wanting to use it. Has anyone pointed that out to them? Well, their philosophy is: OFFER EVERYTHING for the usual OSX user, as up-to-date as possible, so that no-one misses anything later. Back then - when there were no port binaries distributed - this would mean hours and hours and hours of building X11 and Qt and KDE… A pain to get started with any Qt[34] application, I tell you! usual OSX user and hours of building just don't match in my experience. hours of building and usual user doesn't match on any platform I know of. Hence my assumption that the target audience was not the audience that the packaging effort actually catered for. That assumption seemed to have been wrong with Macports actually having pre- built software and having building as a separate option. My updated understanding is now that it is very much like a Linux package repository, where users can just install and run the software without having to care about building and dependencies. Basically a FOSS app store. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Query: Possible code contribution
On Sunday, 2014-03-16, 00:16:45, Lydia Pintscher wrote: On Fri, Mar 14, 2014 at 2:40 PM, Ganesh Kumar gp29111...@gmail.com wrote: Hi. This is Ganesh P Kumar, doing my B.Tech in Computer Science and Engineering in IIT Madras. As part of our curriculum we must contribute code to an open source project. There is a deadline of 40 days for the project submission. Given this small deadline, I would like to ask for suggestions from the KDE Developer group about what would be a viable project during this time. We are ok with working either with the KDE UI as such, or with any KDE subproject. Also, I would like to add that none of us have any dev experience in KDE before. Would a project to fix several small little issues be viable? Then you could maybe work with the designers/usability team and help them out a bit. 40 days is really not much. One other thing that came to my mind is development of examples for Frameworks 5, see [1] and [2]. Only a couple of the frameworks seem to have an examples subdirectory. I think it would be both a valuable and self-contain contribution to make sure that as many frameworks as possible have good example programs. Maybe even having tutorials on techbase.kde.org explaining the steps that were necessary to create the examples. CCing the frameworks development list. Cheers, Kevin [1] https://dot.kde.org/2014/03/04/kde-frameworks-5-alpha-two-out [2] http://community.kde.org/Frameworks -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: What to test for 4.13?
Hi Marko, On Sunday, 2014-03-16, 13:23:35, mk-li...@email.de wrote: Hi Kevin, On 16 Mar 2014, at 11:07 , Kevin Krammer kram...@kde.org wrote: Also one has to point out that MacPorts DELIBERATELY does not distribute port binaries which use code with a licence which isn’t allowing binary distribution. This is good and considerate design in my eyes. Right. Doesn't apply to KDE software but certainly the right thing to do in the wider scope. Hmm, it does apply also to KDE software, since it may use a library which isn’t permitting binary-only distribution. I find this hard to believe. That would mean this is a KDE application that is not available on Linux distributions. Yes, it’s hugely difficult to get KDE applications to build without any X11 deps. Any idea why? Most applications should not have any X11 dependency, those available on Windows definitely don’t. Well, good question! Unfortunately I am not knowledgeable enough to answer this easily now. I have no clue about that either but my naive approach would have been to check the build input files for Windows branches and check if the deviation is something compiler specific (or similar like paths), or non-X11 platform stuff. Also the recent porting efforts to Wayland should help there as well since it is another non-X11 platform. Your system gets updated whenever a port maintainer decides to commit an updated portfile. So, one does not need to worry about how to deinstall old software versions from the depths of your iMac’s file system, but instead can sit back and rely on MacPorts’ logic to keep everything up-to-date, which generally works fine and with very little interactive user action. The plus is that you usually have stable and up-to-date software installed. For KMyMoney 4.6 - for instance - there are two ports kmymoney4 and kmymoney4-devel. The first is always the latest release version, whereas the devel port distributes a version which I try to keep as close as possible to its git's HEAD version, i.e. is always bleeding edge. The user decides what she/he wants. Nice! And thanks to the buildbots the MacPorts infrastructure can make sure that a a new version of any committed portfile will always be build immediately and thus explicitly verify for all four supported versions of MacOSX that the port binaries can be build just fine. THAT is very close to CI, isn’t it?! Are the build results published somewhere? A website or mailinglist one can subscribe to? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: What to test for 4.13?
On Sunday, 2014-03-16, 20:45:49, mk-li...@email.de wrote: On 16 Mar 2014, at 20:34 , Kevin Krammer kram...@kde.org wrote: A dependency in two versions of GTK? For a non-GUI program? I even had a case with a port (don’t remember which one though) where actually LaTeX was required just because there was some documentation stuff to be converted from tex to pdf… Imagine to have to build LaTeX just for generating a piece of documentation. LaTeX’s tools then also pull in X11 due to ImageMagick and poplar! (It never ends.) Yes, but those are build dependencies, right? The binary packages are not affected by this, are they? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: What to test for 4.13?
Hi Ian, On Friday, 2014-03-14, 12:15:39, Ian Wadham wrote: Hi Kevin, On 13/03/2014, at 12:19 AM, Kevin Krammer wrote: On Tuesday, 2014-03-11, 14:05:02, Ian Wadham wrote: I am chiefly concerned about *integration* issues between certain KDE apps and the KDE desktop --- which of course is not present when you are running Apple OS X. I believe that, once they are fixed, these issues will stay fixed until there is some major re-design of KDE or Apple OS X. I base that opinion on direct experience with UNIX, other O/S's and desktops, at the sysadmin and maintenance level, before I retired from the workforce. I am not sure how many KDE applications have any integration needs with the KDE desktop, but I would guess only very few. Most apps run fine in GNOME or other Linux desktops, quite a lot are also avaiable from the KDE Windows initiative. That is a useful piece of the puzzle. I was just wondering what the situation is on Gnome, which I presume does not run the startkde script … :-) Right, startkde is only run for launching a KDE workspace session. The applications don't need anything from there. I should have been more precise. For KDE desktop, please read KDE desktop infrastructure, by which I mean any settings or background processes or dependencies of those kinds (e.g. DBus) that are commonly used within the KDE desktop and can be used indirectly by applications via classes in KDE or Qt libraries. It might also include procedures that are hidden from the direct view of the KDE application writer, such as loaders and caches. Well, D-Bus is launched, on Linux, by the general session setup. Maybe OSX has something that allows to autostart services when a user logs in. All the other things relevant to an application are started by KDE library code, nothing the application developer needs to handle exlicitly. Hence KDE application working in other environments such as GNOME. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: What to test for 4.13?
On Friday, 2014-03-14, 11:23:30, Ian Wadham wrote: On 13/03/2014, at 12:46 AM, Kevin Krammer wrote: On Monday, 2014-03-10, 17:06:53, Ian Wadham wrote: P.S. I see from your signature you are a developer mentor, Kevin. Would you be able to mentor me while I try to get a handle on some of the problems with running KDE apps in an Apple environment? Like my first problem will be why plugins sometimes work and sometimes not, in KDE on Apple OS X. Not sure I can really help you since I have no clue but I can sure try. Well, thank you very much for that, Kevin. May I write to you privately to get started? Sure. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: What to test for 4.13?
On Friday, 2014-03-14, 13:52:28, Mario Fux KDE ML wrote: Am Freitag, 14. März 2014, 09.10:01 schrieb Kevin Krammer: Morning guys Would you be able to mentor me while I try to get a handle on some of the problems with running KDE apps in an Apple environment? Like my first problem will be why plugins sometimes work and sometimes not, in KDE on Apple OS X. Not sure I can really help you since I have no clue but I can sure try. Well, thank you very much for that, Kevin. May I write to you privately to get started? Sure. Please use the kde-mac list for information that's of interest for a broader audience. Avoid private mails if not absolutely necessary. I am not subscribed there, I am not using a Mac. And thanks a lot for efforts! Ah and Kevin, I already asked John, Marko and Ian and now you, would you want to come to Randa this summer to help make KDE apps and KF5 even better on other platforms? Depends on whether you consider Debian one of other platforms :) Anyway, haven't planned as far ahead yet. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: [GSoC 2014] Looking for a mentor
Hi Marcin, On Thursday, 2014-03-13, 17:53:31, Marcin Grzywaczewski wrote: But Recordmydesktop has some issues: 1. It's a console application - it's fine, great and UNIX-way, but I'm not sure it's a way to go for my target. 2. It's not integrated into KDE - I want to use good notifications and OSD. It's a minor from the developer's POV, but major for the user to get a good notifications. There was a KDE frontend for it once, called krecordmydesktop, there is one for GTK if my package repository search is still valid. Anyway, a different approach might yield better results, just wanted to be sure you've had a look at the available options. One other thing that came to my mind was whether that should not be part of the compositor somehow. It has the content for most (all?) windows already and knows where each window is, etc. I guess it is also the only process which can do that on Wayland. I found this on a quick googling: http://sathyasays.com/2009/03/06/using-kwin-as-a-desktop-video-recording-and-screencast-tool/ Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: [GSoC 2014] Looking for a mentor
On Thursday, 2014-03-13, 20:00:14, Marcin Grzywaczewski wrote: Fantastic idea! If there are even basic prerequisities to build it into KWin, I'd like to develop it with pleasure. My goal is to *fix* pain with screencasting on Linux - and means are not that urgent - it can be a plugin to KWin, another program, developing an existing app etc. Do you are interested in developing it inside KWin, really? I'd be happy to cooperate on such task! I have actually no clue :) I just remembered reading about that KWin plugin and remember thinking that it was pretty smart to get the screen image at the source so to speak. It might very well be an extremly stupid thing to do for what I know, lets CC the KWin developers ;-) @KWin people: we are discussing this [1] in that [2] context Thank you for interesting read, Kevin! You're welcome! Another thing I came across (again) is this blog entry: http://alicious.com/recap-kde4-video-screen-capture/ Seems KDEnlive is also using recordmydesktop under the hood for screencapture. But that was in 2009, so better options might exist today. Cheers, Kevin [1] http://sathyasays.com/2009/03/06/using-kwin-as-a-desktop-video-recording-and-screencast-tool/ [2] http://lists.kde.org/?t=13947269235r=1w=2n=6 -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: What to test for 4.13?
On Tuesday, 2014-03-11, 14:05:02, Ian Wadham wrote: I am chiefly concerned about *integration* issues between certain KDE apps and the KDE desktop --- which of course is not present when you are running Apple OS X. I believe that, once they are fixed, these issues will stay fixed until there is some major re-design of KDE or Apple OS X. I base that opinion on direct experience with UNIX, other O/S's and desktops, at the sysadmin and maintenance level, before I retired from the workforce. I am not sure how many KDE applications have any integration needs with the KDE desktop, but I would guess only very few. Most apps run fine in GNOME or other Linux desktops, quite a lot are also avaiable from the KDE Windows initiative. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: What to test for 4.13?
On Monday, 2014-03-10, 17:06:53, Ian Wadham wrote: On 09/03/2014, at 8:23 PM, Kevin Krammer wrote: Hi Ian, On Sunday, 2014-03-09, 17:33:12, Ian Wadham wrote: Hi Kevin and Frank, I think they probably are non-overlapping sets. There *is* a KDE Mac mailing list, but I receive only a few posts per year from it, as compared with several a day from Macports. Ah, interesting. This makes it very different from all other platforms (various Linux distributions, BSD, Windows, mobile platforms), where some of the packagers are also KDE developers. Macports grew out of something Apple did in the early days, mainly directed at getting any kind of free open-source software onto Apple Mac. There are also Fink and Homebrew doing similar jobs. A lot of the emphasis is on GNU utilities and languages such as Perl, TCL and Python, plus some Science packages and Fortran, used by real scientists, free database packages (mysql, mariadb, sqlite, etc.). The Macports have fantastic Unix/BSD and sysadmin skills, but not much knowledge of KDE. The KDE porting team does a good job and are currently at KDE 4.12.2, but they make not much attempt to adapt or convert KDE to run smoothly in the Apple OS X environment. One guy goes a bit deeper, with KMyMoney4, and is in touch with the developers, I think. I help him too, when I can. Both of us rely on KMM4 to run our finances … ;-) I see, that makes it indeed very different from packaging efforts on any other platform. That might of course be true, but also a bit uncommon. Packaging efforts for all other platforms is at least to some extend handled by people who are either users of the packaged software or KDE developers using the respective platform. Part of the problem may be that, until recently, it has been difficult for a KDE developer to just buy a MacBook Pro and set up a dual-boot or virtualised Linux system on it. But now it is quite easy … :-) I aim to have a go, once I have Palapeli for KDE 4.13 put to bed. The main part of the problem, i.e. Apple at least officially requring special hardware, still remains. I am not sure it is feasible to assume anyone would buy a second computer just to satisfy some hardware vendor's lock-in phantasies. I think your prejudices are showing, Kevin … :-) That might very well be. I actually know people who have a so called Hackintosh, but I've never figured out how they actually get OSX. My information, and it seems to be confirmed by other people in this thread, was that Apple did not sell OSX licenses separately, only bundled with their hardware. Another piece of information that might be outdated is that Apple's license terms, at least in some jurisdictions, do not allow to run OSX in a virtualized environment. Which made OSX almost impossible to use in continuous integration and removes the only viable option for quick test build and test runs for the average developer. Again my impression from other responses is that this is still true, but these responders might like me also not be up to date on the whole situation. Actually Apple Mac hardware is bog-standard Intel underneath and OS X is BSD UNIX underneath. Right, but that is the buys special hardware situation I was referring to before. Do you know if the Mac packaging group is just building the software or if they also run the automated tests? I don't know for sure, but I think they just build, sometimes patching to overcome incompatibility problems and build failures. I see. My assumption until this thread was that OSX as a target platform was handled similar to how all other were handled, i.e. a group of people with deeper understanding of the platform's peculiarities would build the software, fix eventual problems and upstream those fixes. Doing the latter through persons within the group who are KDE developers. My updated understanding is that the group packaging KDE software for OSX does not have any members who are KDE developers, I am not certain of that, but it is probably so. right, seems we need a different approach for this platform then. relying on a domain expoert community doesn't seem to be an available option in this case. Another source of problems is the excessive list of dependencies in KDE (see attached). A lot of that seems to be purely build dependencies, not something an end user would be affected by. Well I am. You'd better believe how long it takes to go through all that Nepomuk stuff on a limited bandwidth broadband connection, let alone compile it, if any of it has to be compiled from source. And those dependencies have caused lots of problems in Macports in the past and they used to cause me endless problems when I worked on a Linux system. Yes, sorry, probably bad phrasing on my part. You are affected because you are a developer, I meant that build dependencies are of no concern to end
Re: What to test for 4.13?
Hi Ian, On Sunday, 2014-03-09, 17:33:12, Ian Wadham wrote: Hi Kevin and Frank, On 08/03/2014, at 11:02 PM, Kevin Krammer wrote: On Saturday, 2014-03-08, 21:47:07, Ian Wadham wrote: On 08/03/2014, at 6:43 PM, Frank Reininghaus wrote: 2014-03-08 4:38 GMT+01:00 Ian Wadham: While we are on the topic of testing, how much testing is done of KDE's cross-platform and cross-desktop implementations? Unless the people who prepare the Mac packages test them, the only testing is done by you and by other users, So what I am hearing, in answer to my question, is No testing by the KDE development team. I think this would only be the case if the two groups of people, KDE Developers and KDE-on-Mac packagers/users, were non-overlapping sets. I think they probably are non-overlapping sets. There *is* a KDE Mac mailing list, but I receive only a few posts per year from it, as compared with several a day from Macports. Ah, interesting. This makes it very different from all other platforms (various Linux distributions, BSD, Windows, mobile platforms), where some of the packagers are also KDE developers. That might of course be true, but also a bit uncommon. Packaging efforts for all other platforms is at least to some extend handled by people who are either users of the packaged software or KDE developers using the respective platform. Part of the problem may be that, until recently, it has been difficult for a KDE developer to just buy a MacBook Pro and set up a dual-boot or virtualised Linux system on it. But now it is quite easy … :-) I aim to have a go, once I have Palapeli for KDE 4.13 put to bed. The main part of the problem, i.e. Apple at least officially requring special hardware, still remains. I am not sure it is feasible to assume anyone would buy a second computer just to satisfy some hardware vendor's lock-in phantasies. However, those who own Apple hardware seem to either not use OSX or not use KDE applications on OSX, otherwise there would be an overlap in the users/developers group. OTOH it has always been easy to set up Linux on an IBM-compatible PC. Sure, but I don't think developers working on Linux is the problem. I read that it is possible to run OSX on non-Apple PCs, but that doesn't seem to be as easy. Also not something that could be done officially, e.g. running OSX as a VM on a continuous integration server. Do you know if the Mac packaging group is just building the software or if they also run the automated tests? Just in the last week I have seen cases of a guy on Apple OS X who could not build kde4-baseapps Which version of kde-baseapps? Has this guy filed a bug report? He filed one at https://trac.macports.org/ticket/42673. He did not nominate a version of KDE, but it would have to be in the range KDE 4.10 to 4.12. At this stage, it looks as if the problem could be compiler-related. In this case it seems that the report has been addressed correctly, i.e. an error in packaging reported to the packager. Yep, but more of a difficulty than an error really. The user in question had a version of OS X that was three versions and about three years behind current and Apple has a habit of making quite radical changes … :-( Sure, but my main point was that the bug reported reached the correct target audience, the people who prepare the packages and who have the domain know-how regarding building on that platform. Especially things like version dependencies need to be analyized, fixed and tested by platform experts. If KDE developers cannot or will not test a release on some version of Apple hardware and OS X, what right do they have to offer it as a cross-platform and cross-desktop system? Do you mean all KDE developers or some? As I wrote above, I would be surprised if none of the packager nor users of KDE applications on Mac are KDE developers. But all doesn't seem realistic either. I guess I meant KDE as a group that releases software. Clearly some of that software is intended to be useable on Apple OS X and MS Windows because it contains conditional code for those environments. In that sense, I would say the KDE group is offering KDE software on Apple OS X and MS Windows, just as they are offering it on Linux, so they ought to organise some basic functional testing in conjunction with each new release. I do not know which group of KDE guys should do it. Clearly it would be uneconomical, in cost of hardware alone, for every KDE developer to test his or her software on every platform. But I think it would be reasonable for two or three guys to do it. My assumption until this thread was that OSX as a target platform was handled similar to how all other were handled, i.e. a group of people with deeper understanding of the platform's peculiarities would build the software, fix eventual problems and upstream those fixes. Doing the latter through
Re: What to test for 4.13?
Hi Ian, On Saturday, 2014-03-08, 21:47:07, Ian Wadham wrote: On 08/03/2014, at 6:43 PM, Frank Reininghaus wrote: 2014-03-08 4:38 GMT+01:00 Ian Wadham: While we are on the topic of testing, how much testing is done of KDE's cross-platform and cross-desktop implementations? Unless the people who prepare the Mac packages test them, the only testing is done by you and by other users, So what I am hearing, in answer to my question, is No testing by the KDE development team. I think this would only be the case if the two groups of people, KDE Developers and KDE-on-Mac packagers/users, were non-overlapping sets. That might of course be true, but also a bit uncommon. Packaging efforts for all other platforms is at least to some extend handled by people who are either users of the packaged software or KDE developers using the respective platform. most of whom unfortunately seem to be either unable or unwilling to file useful bug reports and help to debug the problems. Most of the problems that occur are in building and configuring packages across various Apple machines and versions of OS X, from several years ago to the present day. The Macports team provide about 12,000 packages and do a wonderful job of answering the users' queries on MacPorts Users macports-us...@lists.macosforge.org. The users usually file their bug reports (about builds, etc) in the Macports bugs database. Which sounds very similar to how it works on Linux. Do they also have similar policies of upstreaming bug reports of things not caused by local changes? Just in the last week I have seen cases of a guy on Apple OS X who could not build kde4-baseapps Which version of kde-baseapps? Has this guy filed a bug report? He filed one at https://trac.macports.org/ticket/42673. He did not nominate a version of KDE, but it would have to be in the range KDE 4.10 to 4.12. At this stage, it looks as if the problem could be compiler-related. In this case it seems that the report has been addresses correctly, i.e. an error in packaging reported to the packager. If KDE developers cannot or will not test a release on some version of Apple hardware and OS X, what right do they have to offer it as a cross-platform and cross-desktop system? Do you mean all KDE developers or some? As I wrote above, I would be surprised if none of the packager nor users of KDE applications on Mac are KDE developers. But all doesn't seem realistic either. And it would be nice to have some regular testing ... :-) I understand that quite a bit of regular testing is being done by you and your friends. No, not testing, they are mostly just attempting to build and *use* stuff. If they fail, I think they just go and try some other package … :-) Well, that is some for of testing. Valuable testing if the failure is reported, sophisticated testing if the test is repeated regularily. Very similar to other platforms, 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. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: kjsembed tier (Re: Build failed in Jenkins: kjsembed_master_qt5 #27)
On Saturday, 2014-03-01, 13:19:23, David Faure wrote: On Saturday 01 March 2014 12:12:37 KDE CI System wrote: CMake Error at CMakeLists.txt:30 (find_package): Could not find a configuration file for package KF5DocTools that is compatible with requested version 4.97.0. The following configuration files were considered but not accepted: /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdoctools/ins t/ lib64/cmake/KF5DocTools/KF5DocToolsConfig.cmake, version: 4.96.0 Interesting, so kjsembed lies when it says tier2, because it depends on kdoctools which also says tier2. Kevin, was 3064544f814813e4f528e7902f567e5ec4a30ffd in kjsembed wrong? If it does need another tier2 framework other then the old ki18n then yes. I checked the diagrams I was pointed at during the IRC meeting and it only had ki18n and kjs as dependencies. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring attachment: tier3-kjsembed.png signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kjsembed tier (Re: Build failed in Jenkins: kjsembed_master_qt5 #27)
On Saturday, 2014-03-01, 15:37:05, David Faure wrote: On Saturday 01 March 2014 13:37:31 Kevin Krammer wrote: On Saturday, 2014-03-01, 13:19:23, David Faure wrote: On Saturday 01 March 2014 12:12:37 KDE CI System wrote: CMake Error at CMakeLists.txt:30 (find_package): Could not find a configuration file for package KF5DocTools that is compatible with requested version 4.97.0. The following configuration files were considered but not accepted: /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdoctools /i ns t/ lib64/cmake/KF5DocTools/KF5DocToolsConfig.cmake, version: 4.96.0 Interesting, so kjsembed lies when it says tier2, because it depends on kdoctools which also says tier2. Kevin, was 3064544f814813e4f528e7902f567e5ec4a30ffd in kjsembed wrong? If it does need another tier2 framework other then the old ki18n then yes. I checked the diagrams I was pointed at during the IRC meeting and it only had ki18n and kjs as dependencies. I see. The diagrams are wrong/outdated :) Aurélien: you added kdoctools to kjsembed in c5dc9c1d03. Can you regenerate the diagrams maybe? (so we also get the ki18n tier change in there?) I'll change the tier in kjsembed to 2. Kevin: do you know if that changes the tier of anything else? I don't think so. All of the tier 4 have tons of dependencies, so none of them was affected by the ki18n change. I'll have to revert my kjsembed change to the wiki though. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116030: Extend tests to cover getConf... calls
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116030/ --- (Updated March 1, 2014, 5:54 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Chusslove Illich. Repository: ki18n Description --- Write a test config to a test location using QStandardPath's test feature. Test getConf... calls in success and fallback mode. Actually found a missing bool - script bool conversion. fixed Chusslove: how about using ktranscript.ini for the file to look up using QStandardPaths? Maybe a more obvious on other platforms? Diffs - autotests/CMakeLists.txt 6e926ba autotests/ktranscript-test.ini PRE-CREATION autotests/ktranscripttest.h 7ea7818 autotests/ktranscripttest.cpp e3a27ff autotests/test.js ad53b1b autotests/testhelpers.h PRE-CREATION autotests/testhelpers.cpp PRE-CREATION src/ktranscript.cpp 44c8b63 Diff: https://git.reviewboard.kde.org/r/116030/diff/ Testing --- All previously existing tests continue to run :) Thanks, Kevin Krammer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116050: Adjust kpty tier for changed ki18n tier
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116050/ --- (Updated Feb. 27, 2014, 2:03 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kpty Description --- ki18n changed from tier 2 to tier 1. kpty only depends on tier 1 now, becomes tier 2 Diffs - kpty.yaml 78c0a75 Diff: https://git.reviewboard.kde.org/r/116050/diff/ Testing --- Thanks, Kevin Krammer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116049: Adjust kjsembed tier for changed ki18n tier
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116049/ --- (Updated Feb. 27, 2014, 2:04 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Bernd Buschinski. Repository: kjsembed Description --- ki18n changed from tier 2 to tier 1. kjsembed only depends on tier 1 now, becomes tier 2 Diffs - kjsembed.yaml 78c0a75 Diff: https://git.reviewboard.kde.org/r/116049/diff/ Testing --- Thanks, Kevin Krammer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116075: Provide an implementation for QPlatformSystemTrayIcon
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116075/#review50909 --- src/platformtheme/kdeplatformsystemtrayicon.h https://git.reviewboard.kde.org/r/116075/#comment35727 remove virtual and add Q_DECL_OVERRIDE? or change the signature at SystemTrayMenu? currently that is a bit inconsistent :) src/platformtheme/kdeplatformsystemtrayicon.h https://git.reviewboard.kde.org/r/116075/#comment35728 see above src/platformtheme/kdeplatformsystemtrayicon.cpp https://git.reviewboard.kde.org/r/116075/#comment35729 I see lambdas being using later on, in which case this looks like a candidate for std::find_if() with a lambda predicate - Kevin Krammer On Feb. 26, 2014, 8:09 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116075/ --- (Updated Feb. 26, 2014, 8:09 a.m.) Review request for KDE Frameworks, Plasma and Marco Martin. Repository: frameworkintegration Description --- Add menu support to KDEPlatformSystemTrayIcon Uses new QPA API which got introduced in Qt 5.3. Provide an implementation for QPlatformSystemTrayIcon The idea is to force all QSystemTrayIcon to use our status notifiers as we don't want to provide an xembed based system tray in the next iteration of the Plasma desktop shell anymore. The KDEPlatformSystemTrayIcon uses a KStatusNotifierItem to implement the system tray icon. Unfortunately a complete wrapping is not yet possible as we cannot create a menu. We do not want to provide a QPlatformMenu in our PlatformTheme and thus the menu used by QSystemTrayIcon does not have a QPlatformMenu. This is adressed in Qt 5.3 which extends the QPA API. Diffs - autotests/CMakeLists.txt fb58b3a0cb9acc062be0edeb53210048e364c1be src/platformtheme/CMakeLists.txt 5fd949bee41b762120e120148de0b3b473de915c src/platformtheme/kdeplatformsystemtrayicon.h PRE-CREATION src/platformtheme/kdeplatformsystemtrayicon.cpp PRE-CREATION src/platformtheme/kdeplatformtheme.h f436eea4e3aa9cfda62654e5c6dc77aea05e8f27 src/platformtheme/kdeplatformtheme.cpp a5d86c27385447b7744cb8bca0cf65889872fb0b Diff: https://git.reviewboard.kde.org/r/116075/diff/ Testing --- Using systray from qtbase/examples/widgets/desktop/systray Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
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.
