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: 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: 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 <> 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, 4:24 p.m.) Review request for KDE Frameworks and Chusslove Illich. Changes --- Deploy a test config file instead of creating one. Removed left over debug output 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 (updated) - 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 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: 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 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: Query: Possible code contribution
Hi, On Wednesday, 2014-03-19, 23:36:27, Harsh Kumar wrote: > On 3/16/14, Kevin Krammer 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: 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 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: 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 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: 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: 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 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.cp
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: 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: 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: 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: 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/#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: [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: 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: 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: 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
Re: New test with C++11 and lambda (UDSEntry testcase)
On Saturday, 2013-09-21, Mark wrote: > Hi, > > I've just created a quite complicated testcase for frameworks which uses > the new signal/slot connection syntax (since Qt 5.0) and uses a lambda as > slot. The reason i did this is so that i can keep then entire testcase > (minus the initialization) contained in one testcase method. Otherwise i > would have to make signal/slot connections to member functions which is > probably not something you want for testcases.. Wouldn't it also be possible to use QSignalSpy? 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: kwallet-framework optionally depends on kdepimlibs
On Tuesday, 2014-01-14, 18:32:13, Valentin Rusu wrote:
> On 01/14/2014 06:27 PM, Treeve Jelbert wrote:
> > src/runtime/kwalletd/CMakeLists.txt:
> >
> > find_package(Gpgme) # Called by FindQGpgme, but since we call some gpgme
> >
> > # functions ourselves we need to link against it
> >
> > directly.
> > find_package(QGpgme) # provided by kdepimlibs
> >
> > if (GPGME_FOUND AND QGPGME_FOUND)
> >
> > add_definitions(-DHAVE_QGPGME)
> > include_directories(${GPGME_INCLUDES} ${QGPGME_INCLUDE_DIR})
> > set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${KDE_ENABLE_EXCEPTIONS}")
> >
> > endif(GPGME_FOUND AND QGPGME_FOUND)
> >
> >
> >
> > kdepimlibs does not build for me and is not a framework.
> >
> > It looks as if qgpgme should be split from kdepimlibs to become a
> > framework
>
> Yes, it'll be a good idea. I also think that qgpgme should become a
> framework. Who could do that? May I take care of it?
There is already a frameworks branch and obviously some, if not all, KDE PIM
libs are candidates for becoming frameworks.
We had a discussion about that at the last sprint, but I seem to be unable to
find the discussion's notes.
>From what I remember I think that the frameworks branch is pretty up to date.
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 115016: Make KJob usable from QML
On Tuesday, 2014-01-14, 23:12:56, Aurélien Gâteau wrote: > > On Jan. 14, 2014, 9:20 p.m., Alex Merry wrote: > > > src/lib/jobs/kjob.h, line 92 > > > <https://git.reviewboard.kde.org/r/115016/diff/1/?file=233991#file233991 > > > line92>> > > > > I don't think this will work; I'm fairly sure that notify signals > > > must have zero or one arguments, and the one argument must be the > > > same type as the property. The notify signal in this class has a > > > preceding KJob* argument.> > > Aleix Pol Gonzalez wrote: > > Quoting the documentation: > > "A NOTIFY signal is optional. If defined, it should specify one > > existing signal in that class that is emitted whenever the value of > > the property changes." > > > > Also I've been using this in a plasmoid I'm porting and it doesn't > > seem to cause problems. > Quoting the *Qt 5* documentation: > (http://doc-snapshot.qt-project.org/qt5-stable/properties.html) > > A NOTIFY signal is optional. If defined, it should specify one existing > signal in that class that is emitted whenever the value of the property > changes. NOTIFY signals for MEMBER variables must take zero or one > parameter, which must be of the same type as the property. The parameter > will take the new value of the property. > > The fix is probably just a matter of introducing a "void > percentChanged(int)" signal, and emitting it wherever percent() is emitted. No need, the percent property is not using the MEMBER option of the Q_PROPERY macro, it is using the classic READ followed by getter function 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. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Question regarding build of item models framework on Window
Hi all, you are probably not subscribed to kde-devel so you might have missed that one: http://lists.kde.org/?l=kde-devel&m=139021750622083&w=2 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: Tier status of attica & kwallet
On Wednesday, 2014-01-22, 17:35:50, Jonathan Riddell wrote: > On Thu, Jan 23, 2014 at 04:24:37AM +1100, Michael Palimaka wrote: > > attica seems to have been absorbed as a framework, but does not appear > > to have been assigned a tier. Based on its dependencies, it looks like > > it would fit in tier 1? > > The library was renamed to KF5Attica in the expectation it could be a > framework but I'd appreciate someone more knowledgeable giving it an > eye over to work out if anything else needs to be done to make it a > framework. > > > kwallet is in tier 2, but since b60582640d99e0ef603bf4e02df974793fb5ad27 > > it includes kwalletd which depends on higher tier frameworks - does it > > still belong in tier 2? > > Another possibility would be to move kwalletd into a separate git > repository but I guess nobody is likely to use the library without the > daemon so tier 3 seems more sensible. I guess it mostly depends on whether KF wallet is tied to kwalletd or is a client library for any spec conformant secret service. In the first case there is no point in stripping it out, in the second case it might be viable. I have to admit I totally lost the overview over the state of transition to secret service, so that might be another unrelated 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. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Change the ML default reply-to address
On Wednesday, 2014-01-29, 09:01:00, Martin Klapetek wrote: > Let's be pragmatic, how many times it happened to you that you actually > responded to the author alone while you actually intended to respond to the > list? How would that happen? Replying to the list always replies to the list. > It's just super annoying if you're communicating with lists like > plasma-devel which has reply-to-list and dozen more KDE MLs which also have > reply-to-list and then you're responding to k-f-devel and everytime it's > that "oh wait, I need to change the reply-to address". I am subscribed to more than two dozend KDE mailinglist (and numerous others). I post to some of the regularily while some others only sporadically. "New mail to list" and "reply to list" have *always* sent the mail to the list. The only thing that is not reliably working across lists is reply in private mail. For that to work repliably I've fallen back to using the mouse and right-clicking the right address. Pretty annoying but some mailinglists seem to have broken setups. 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: Change the ML default reply-to address
On Wednesday, 2014-01-29, 11:43:37, Martin Klapetek wrote: > On Wed, Jan 29, 2014 at 11:23 AM, Kevin Krammer wrote: > > I am subscribed to more than two dozend KDE mailinglist (and numerous > > others). > > I post to some of the regularily while some others only sporadically. > > "New mail to list" and "reply to list" have *always* sent the mail to the > > list. > > > > The only thing that is not reliably working across lists is reply in > > private > > mail. For that to work repliably I've fallen back to using the mouse and > > right-clicking the right address. Pretty annoying but some mailinglists > > seem > > to have broken setups. > > As said in the original mail, in less-advanced-than-kmail clients there is > no "reply to list" and simply hitting "reply" /always/ puts the author in > "To:" instead of the ML address for this list, therefore the suggestion :) Ah, a case of wrong-tool-for-the-job then :) > Personally I also think that all of our MLs should behave the same...sort > of like KDE-ML-policy but that's a longer run I guess... I don't think it really matters [1]. Reply to list works reliably, reply to author requires mouse interaction to be reliable, reply as a shortcut is out of the picture due to broken lists. It is a pity but using shortcuts is dying out, more and more things start to require clicking and touching :( Luckily the only affected action currently is reply to author which is not often required :) Cheers, Kevin [1] if those with limited "mail clients" prefer reply to mimick reply to list, then we should do that. Reply's consistency is broken for everyone anyway and thus mostly unused anyway. -- 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: Where to put QML Bindings for KDE frameworks?
On Wednesday, 2014-01-29, 12:22:39, David Edmundson wrote: > I don't generally think it makes sense to merge these with the > widgets. If you want to build the widgets you wouldn't want the QML > imports, if you want the QML imports you don't want to build the > widgets. If you meant QtQuick, I agree :) 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: Change the ML default reply-to address
On Wednesday, 2014-01-29, 12:30:55, Martin Gräßlin wrote: > On Wednesday 29 January 2014 11:23:31 Kevin Krammer wrote: > > I am subscribed to more than two dozend KDE mailinglist (and numerous > > others). I post to some of the regularily while some others only > > sporadically. "New mail to list" and "reply to list" have *always* sent > > the > > mail to the list. > > And I as a more than a decade KMail user just learned something new: I > haven't known that there is a reply to list option. And while trying to > write that mail I noticed the problem. I pressed "R" and got krammer in the > to field, and had to go back and tried "L" for the very first time. :-) Just in case: CTRL+SHIFT+N -> new mail to list 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: Change the ML default reply-to address
On Wednesday, 2014-01-29, 14:29:42, Mark Gaiser wrote: > Yeah, i've had that issue quite a few times. > Now since i use gmail i either have an easy reply-to-all option or > (and that's even better) a labs plugin that automatically does > reply-to-all instead of reply. Which has a different problem since this sends mails to the other person twice. Once directly and once through the list. IMHO it really sucks when that happens, polluting *my* inbox when replying to my mails on a list. Make sure you always remove the sender after you've hit reply-all for a list! 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: Change the ML default reply-to address
On Thursday, 2014-01-30, 13:55:21, Alex Merry wrote: > On 30/01/14 13:50, Aurélien Gâteau wrote: > > You can avoid this (on the receiving side) by editing your personal > > mailing list settings. Quoting mailman settings page: > > > > """ > > Avoid duplicate copies of messages? > > > > When you are listed explicitly in the To: or Cc: headers of a list > > message, you can opt to not receive another copy from the mailing list. > > Select Yes to avoid receiving copies from the mailing list; select No to > > receive copies. > > > > If the list has member personalized messages enabled, and you elect to > > receive copies, every copy will have a X-Mailman-Copy: yes header added > > to it. > > """ > > Only this ends up doing the exact opposite of what I, at least, want: I > get the message in my inbox, but it doesn't have the headers that cause > it to be filtered to the correct mailing list folder. Exactly! 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
Review Request 115485: Porting KTranscript from KJS to QtScript
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115485/ --- Review request for KDE Frameworks and Chusslove Illich. Repository: ki18n Description --- Attempt at replacing the KJS dependency with a QtScript, i.e. making ki18n a tier1 framework. Needs more testing and likely fixing Diffs - src/ktranscript.cpp 2fde5c2 CMakeLists.txt 87c27e6 src/CMakeLists.txt 55fa512 Diff: https://git.reviewboard.kde.org/r/115485/diff/ Testing --- Unittest runs, but the test script is very minimal and would need to be extendedb by someone who understands the scripting requirements. There is also a weird crash at test shutdown, in QThreadStorage. As far as I can tell I did not change anything related to threads though. 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 115485: Porting KTranscript from KJS to QtScript
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115485/ --- (Updated Feb. 5, 2014, 4:08 p.m.) Review request for KDE Frameworks and Chusslove Illich. Repository: ki18n Description --- Attempt at replacing the KJS dependency with a QtScript, i.e. making ki18n a tier1 framework. Needs more testing and likely fixing Diffs (updated) - CMakeLists.txt 3e099d5 src/CMakeLists.txt 55fa512 src/ktranscript.cpp 2fde5c2 Diff: https://git.reviewboard.kde.org/r/115485/diff/ Testing --- Unittest runs, but the test script is very minimal and would need to be extendedb by someone who understands the scripting requirements. There is also a weird crash at test shutdown, in QThreadStorage. As far as I can tell I did not change anything related to threads though. 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 115485: Porting KTranscript from KJS to QtScript
> On Feb. 5, 2014, 3:51 p.m., Aurélien Gâteau wrote: > > Wow, great work! I attempted doing this some time ago, and all I managed to > > produce was two unit tests :). Looks good to me and works fine here. Just > > two (really minor) nitpicks. Thanks :) Good to hear that it works properly, I guess we should try to increase the test coverage before we merge a change like that. I'll see what I can contribute to that effort but ideally someone who really understands how this is used can contribute a couple of advanced test cases :) - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115485/#review49036 --- On Feb. 5, 2014, 4:08 p.m., Kevin Krammer wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115485/ > --- > > (Updated Feb. 5, 2014, 4:08 p.m.) > > > Review request for KDE Frameworks and Chusslove Illich. > > > Repository: ki18n > > > Description > --- > > Attempt at replacing the KJS dependency with a QtScript, i.e. making ki18n a > tier1 framework. > Needs more testing and likely fixing > > > Diffs > - > > CMakeLists.txt 3e099d5 > src/CMakeLists.txt 55fa512 > src/ktranscript.cpp 2fde5c2 > > Diff: https://git.reviewboard.kde.org/r/115485/diff/ > > > Testing > --- > > Unittest runs, but the test script is very minimal and would need to be > extendedb by someone who understands the scripting requirements. > There is also a weird crash at test shutdown, in QThreadStorage. As far as I > can tell I did not change anything related to threads though. > > > 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 115485: Porting KTranscript from KJS to QtScript
> On Feb. 5, 2014, 3:51 p.m., Aurélien Gâteau wrote:
> > Wow, great work! I attempted doing this some time ago, and all I managed to
> > produce was two unit tests :). Looks good to me and works fine here. Just
> > two (really minor) nitpicks.
>
> Kevin Krammer wrote:
> Thanks :)
> Good to hear that it works properly, I guess we should try to increase
> the test coverage before we merge a change like that.
> I'll see what I can contribute to that effort but ideally someone who
> really understands how this is used can contribute a couple of advanced test
> cases :)
>
> Chusslove Illich wrote:
> I don't see any place where a change in semantics could have been
> introduced, so I expect it to work if it worked for the existing tests.
> But
> I'll try to add more test cases over the weekend, for the piece of mind.
>
> Side note (repeating myself for the record): I don't see significant
> benefit
> in ki18n being tier 1, and I'm not happy about switching to a JavaScript
> engine with strong ambitions in the Web world ("overmaintained"). But
> porting work has been done, and that trumps my fuzzy uneasiness.
>
Thanks for checking.
I tried to change as little as possible, but running a couple of actual usages
can't hurt.
My motivation was mainly that I promised ervin to look into this at Akademy ;-)
Didn't get around to it sooner
- Kevin
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115485/#review49036
---
On Feb. 5, 2014, 4:08 p.m., Kevin Krammer wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115485/
> ---
>
> (Updated Feb. 5, 2014, 4:08 p.m.)
>
>
> Review request for KDE Frameworks and Chusslove Illich.
>
>
> Repository: ki18n
>
>
> Description
> ---
>
> Attempt at replacing the KJS dependency with a QtScript, i.e. making ki18n a
> tier1 framework.
> Needs more testing and likely fixing
>
>
> Diffs
> -
>
> CMakeLists.txt 3e099d5
> src/CMakeLists.txt 55fa512
> src/ktranscript.cpp 2fde5c2
>
> Diff: https://git.reviewboard.kde.org/r/115485/diff/
>
>
> Testing
> ---
>
> Unittest runs, but the test script is very minimal and would need to be
> extendedb by someone who understands the scripting requirements.
> There is also a weird crash at test shutdown, in QThreadStorage. As far as I
> can tell I did not change anything related to threads though.
>
>
> Thanks,
>
> Kevin Krammer
>
>
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: HAVE_X11 usage in KIO/core
On Friday, 2014-02-07, 08:53:54, Martin Gräßlin wrote:
> Hi,
>
> I found some HAVE_X11 not defined warnings in KIO and had a look at them.
> One of them is in core/kprotocolmanager.cpp in the following snippet.
>
> // This is not the OS, but the windowing system, e.g. X11 on Unix/Linux.
> static QString platform()
> {
> #if HAVE_X11
> return QL1S("X11");
> #elif defined(Q_OS_MAC)
> return QL1S("Macintosh");
> #elif defined(Q_OS_WIN)
> return QL1S("Windows");
> #else
> return QL1S("Unknown");
> #endif
> }
>
> I'm wondering what to do about it. The best would be to use
> QGuiApplication::platformName, but it's a core app. Also finding X11 in
> CMakeLists to get the HAVE_X11 defined looks very wrong to me and not future
> safe (Wayland).
My guess is that platform() in this context means operating system, not
windowing/display system.
Hinted also by the use of Q_OS_ instead of Q_WS_
IMHO the correct change is something like this
#if defined(Q_OS_UNIX)
#if defined(Q_OS_MAC)
return QL1S("Macintosh")
#elif defined(Q_OS_LINUX)
return QL1S("Linux")
#else
return QL1S("Unix")
#endif
#elfi defined(Q_OS_WINDOWS)
return QL1S("Windows")
#else
return QL1S("Unknown")
#endif
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: HAVE_X11 usage in KIO/core
On Friday, 2014-02-07, 09:51:27, Martin Gräßlin wrote:
> On Friday 07 February 2014 09:38:41 Kevin Krammer wrote:
> > On Friday, 2014-02-07, 08:53:54, Martin Gräßlin wrote:
> > > I'm wondering what to do about it. The best would be to use
> > > QGuiApplication::platformName, but it's a core app. Also finding X11 in
> > > CMakeLists to get the HAVE_X11 defined looks very wrong to me and not
> > > future safe (Wayland).
> >
> > My guess is that platform() in this context means operating system, not
> > windowing/display system.
>
> See the comment I pasted, it's explicitly saying it's the windowing system
> and not the OS...
Ah, didn't see that. Does it actually make sense?
If yes than this obviously has be to be done at runtime, at least for
platforms with multiple UI systems:
#if defined(Q_OS_MAC)
return QL1S("Macintosh")
#elfi defined(Q_OS_WINDOWS)
return QL1S("Windows")
#else
const QVariant platformName = qApp ? qApp->property("platformName") :
QVariant();
if (platformName.isValid()) {
const QString name = platformName.toString();
if (!name.isEmpty())
return name;
}
#endif
return QL1S("Unknown");
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 115485: Porting KTranscript from KJS to QtScript
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115485/ --- (Updated Feb. 16, 2014, 4:02 p.m.) Review request for KDE Frameworks and Chusslove Illich. Changes --- Fixed functions with variable length argument lists. Fixed loading of additional scripts Repository: ki18n Description --- Attempt at replacing the KJS dependency with a QtScript, i.e. making ki18n a tier1 framework. Needs more testing and likely fixing Diffs (updated) - CMakeLists.txt 3e099d5 src/CMakeLists.txt 9e3ce9f src/ktranscript.cpp c922e91 Diff: https://git.reviewboard.kde.org/r/115485/diff/ Testing --- Unittest runs, but the test script is very minimal and would need to be extendedb by someone who understands the scripting requirements. There is also a weird crash at test shutdown, in QThreadStorage. As far as I can tell I did not change anything related to threads though. 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 115485: Porting KTranscript from KJS to QtScript
> On Feb. 5, 2014, 3:51 p.m., Aurélien Gâteau wrote:
> > Wow, great work! I attempted doing this some time ago, and all I managed to
> > produce was two unit tests :). Looks good to me and works fine here. Just
> > two (really minor) nitpicks.
>
> Kevin Krammer wrote:
> Thanks :)
> Good to hear that it works properly, I guess we should try to increase
> the test coverage before we merge a change like that.
> I'll see what I can contribute to that effort but ideally someone who
> really understands how this is used can contribute a couple of advanced test
> cases :)
>
> Chusslove Illich wrote:
> I don't see any place where a change in semantics could have been
> introduced, so I expect it to work if it worked for the existing tests.
> But
> I'll try to add more test cases over the weekend, for the piece of mind.
>
> Side note (repeating myself for the record): I don't see significant
> benefit
> in ki18n being tier 1, and I'm not happy about switching to a JavaScript
> engine with strong ambitions in the Web world ("overmaintained"). But
> porting work has been done, and that trumps my fuzzy uneasiness.
>
>
> Kevin Krammer wrote:
> Thanks for checking.
> I tried to change as little as possible, but running a couple of actual
> usages can't hurt.
>
> My motivation was mainly that I promised ervin to look into this at
> Akademy ;-)
> Didn't get around to it sooner
>
> Chusslove Illich wrote:
> I've pushed test cases for almost all functions. (Left out are getConf*
> series, because at the moment they can look only in ~/.transcriptrc.)
>
Thank you, they were really helpful!
Caught a couple of bugs
- Kevin
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115485/#review49036
---
On Feb. 16, 2014, 4:02 p.m., Kevin Krammer wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115485/
> ---
>
> (Updated Feb. 16, 2014, 4:02 p.m.)
>
>
> Review request for KDE Frameworks and Chusslove Illich.
>
>
> Repository: ki18n
>
>
> Description
> ---
>
> Attempt at replacing the KJS dependency with a QtScript, i.e. making ki18n a
> tier1 framework.
> Needs more testing and likely fixing
>
>
> Diffs
> -
>
> CMakeLists.txt 3e099d5
> src/CMakeLists.txt 9e3ce9f
> src/ktranscript.cpp c922e91
>
> Diff: https://git.reviewboard.kde.org/r/115485/diff/
>
>
> Testing
> ---
>
> Unittest runs, but the test script is very minimal and would need to be
> extendedb by someone who understands the scripting requirements.
> There is also a weird crash at test shutdown, in QThreadStorage. As far as I
> can tell I did not change anything related to threads though.
>
>
> 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 115485: Porting KTranscript from KJS to QtScript
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115485/ --- (Updated Feb. 16, 2014, 6:54 p.m.) Review request for KDE Frameworks and Chusslove Illich. Changes --- Removed qDebug() left over from debugging Repository: ki18n Description --- Attempt at replacing the KJS dependency with a QtScript, i.e. making ki18n a tier1 framework. Needs more testing and likely fixing Diffs (updated) - CMakeLists.txt 3e099d5 src/CMakeLists.txt 9e3ce9f src/ktranscript.cpp c922e91 Diff: https://git.reviewboard.kde.org/r/115485/diff/ Testing --- Unittest runs, but the test script is very minimal and would need to be extendedb by someone who understands the scripting requirements. There is also a weird crash at test shutdown, in QThreadStorage. As far as I can tell I did not change anything related to threads though. 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 115485: Porting KTranscript from KJS to QtScript
> On Feb. 16, 2014, 5:22 p.m., Albert Astals Cid wrote: > > src/ktranscript.cpp, line 1489 > > <https://git.reviewboard.kde.org/r/115485/diff/3/?file=244386#file244386line1489> > > > > Kill the qdebug (and the one a bit below)? good catch, thanks - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115485/#review49941 --- On Feb. 16, 2014, 6:54 p.m., Kevin Krammer wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115485/ > --- > > (Updated Feb. 16, 2014, 6:54 p.m.) > > > Review request for KDE Frameworks and Chusslove Illich. > > > Repository: ki18n > > > Description > --- > > Attempt at replacing the KJS dependency with a QtScript, i.e. making ki18n a > tier1 framework. > Needs more testing and likely fixing > > > Diffs > - > > CMakeLists.txt 3e099d5 > src/CMakeLists.txt 9e3ce9f > src/ktranscript.cpp c922e91 > > Diff: https://git.reviewboard.kde.org/r/115485/diff/ > > > Testing > --- > > Unittest runs, but the test script is very minimal and would need to be > extendedb by someone who understands the scripting requirements. > There is also a weird crash at test shutdown, in QThreadStorage. As far as I > can tell I did not change anything related to threads though. > > > 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 115485: Porting KTranscript from KJS to QtScript
> On Feb. 20, 2014, 2:36 p.m., Kevin Ottens wrote: > > Any concerns left on that patch? It'd be nice to have it in alpha 2. I guess the main problem is that due to a weird JavaScriptCore internal thing the unit test crashes on exit. See https://bugreports.qt-project.org/browse/QTBUG-9622 for reference. One idea I had was to compile KTranscript into the unit test directly, using a DEFINE to switch from Q_GLOBAL_STATIC to an explicitly created and destroyed instance. - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115485/#review50376 --- On Feb. 16, 2014, 6:54 p.m., Kevin Krammer wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115485/ > --- > > (Updated Feb. 16, 2014, 6:54 p.m.) > > > Review request for KDE Frameworks and Chusslove Illich. > > > Repository: ki18n > > > Description > --- > > Attempt at replacing the KJS dependency with a QtScript, i.e. making ki18n a > tier1 framework. > Needs more testing and likely fixing > > > Diffs > - > > CMakeLists.txt 3e099d5 > src/CMakeLists.txt 9e3ce9f > src/ktranscript.cpp c922e91 > > Diff: https://git.reviewboard.kde.org/r/115485/diff/ > > > Testing > --- > > Unittest runs, but the test script is very minimal and would need to be > extendedb by someone who understands the scripting requirements. > There is also a weird crash at test shutdown, in QThreadStorage. As far as I > can tell I did not change anything related to threads though. > > > Thanks, > > Kevin Krammer > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: using KDBusConnectionPool in libraries
On Friday, 2014-02-21, 08:30:02, Kevin Ottens wrote: > Hello, > > On Thursday 20 February 2014 20:03:20 Aaron J. Seigo wrote: > > I ran into an interesting situation the other day with libkactivities: it > > uses KDBusConnectionPool to create connections in a thread-safe manner. > > KDBusConnectionPool creates a connection in whatever thread it happens to > > be executed from. In libkactivities this creates a problem as a singleton > > that is internal to the library uses KDBusConnectionPool .. so whatever > > thread it happens to be called from first: that’s the thread it gets its > > QDBusConnection object put into. > > Well, isn't the problem that this singleton should be thread-safe or thread- > local in the first place? While this particular issue was triggered by D-Bus usage, I think any singleton that is intended to be used by multiple threads and has some of its functionality depend on event processing, needs to be aware of per-thread event loops. > > Or, I suppose, we could invent a policy that applications should do all > > dbus related activities in a specific thread .. though that can be > > difficult to know as dbus calls are often hidden within libraries. > > > > .. or, does anyone have a pointer to what exactly in QDBusConnection is > > not > > thread safe? > > It wasn't (Qt4 times)... I have no idea if that's still the case today. It > could be that this class isn't needed anymore. > > As for what exactly is not thread safe in QDBusConnection I don't remember. > Since it was highlighted by Nepomuk at the time and forced upon us by its > API (almost behind us too) Vishesh or Sebastian should know more (adding > them in CC). I think some of the people who were working on the inital Kontact Touch also ran into this at some point, when trying to fit several agents into one process, each running in a different thread. My guess is that it is thread-safe for sending, i.e. messages won't be interleaved, but there always needs to be a thread that runs the event loop for receiving and it is probably also the one that gets all replies and incoming calls. 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: desktoptojson and kservice
On Friday, 2014-02-21, 13:41:29, Aaron J. Seigo wrote: > While there are shortcomings in QSettings for parsing random INI files, I > don’t think any of these apply to the .desktop files we use. Would there be > any objection / reason against dropping the use of KConfig in desktop and > moving to QSettings, turning it into a Qt only application? One limitation we hit recently in Akonadi server is that QSettings can not correclty deal with comma in strings. Basically it interprets any value with a comma in it as a list instead of a string. This generated a problem in Akonadi when Akonadi Control, which is "Qt-only" used QSettings to parse .desktop files of Akonadi agents. Translators found out that if they had comma in the translation, then these strings would not show up in user interfaces anymore. The Akonadi maintainer worked around it by joining QStringList on fields that are expected to be strings, but of course that is not always the same as the original string. If we want to be able to parse .desktop files without KConfig, we need a desktop file parser. The Razor-Qt and LxQt people might have one already. 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 115936: Split ki18n ktranscript tests into one using the plugin and one instantiating/destroying the class directly
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115936/ --- (Updated Feb. 21, 2014, 4:58 p.m.) Review request for KDE Frameworks and Chusslove Illich. Changes --- Fixed a typo the CMakeLists.txt file, removed the extern "C" block from the test that uses direct instantiation Repository: ki18n Description --- Separate ktranscript plugin test into its own autotest The plugin based test of KTranscript performs all tests with a single instance of KTranscriptImp because the plugin uses Q_GLOBAL_STATIC to create and access that instance. The non-plugin test creates a new instance for every test. Currently all scripting tests are runnable in both situations, but the non-plugin test allows for tests that need a "clean slate". Diffs (updated) - autotests/CMakeLists.txt eb73d21 autotests/ktranscriptplugintest.h PRE-CREATION autotests/ktranscriptplugintest.cpp PRE-CREATION autotests/ktranscripttest.h 53f3ce0 autotests/ktranscripttest.cpp 78aecb4 src/ktranscript.cpp c922e91 src/ktranscript_p.h f1cc132 Diff: https://git.reviewboard.kde.org/r/115936/diff/ Testing --- All three tests run without failure Thanks, Kevin Krammer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115936: Split ki18n ktranscript tests into one using the plugin and one instantiating/destroying the class directly
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115936/ --- Review request for KDE Frameworks and Chusslove Illich. Repository: ki18n Description --- Separate ktranscript plugin test into its own autotest The plugin based test of KTranscript performs all tests with a single instance of KTranscriptImp because the plugin uses Q_GLOBAL_STATIC to create and access that instance. The non-plugin test creates a new instance for every test. Currently all scripting tests are runnable in both situations, but the non-plugin test allows for tests that need a "clean slate". Diffs - autotests/CMakeLists.txt eb73d21 autotests/ktranscriptplugintest.h PRE-CREATION autotests/ktranscriptplugintest.cpp PRE-CREATION autotests/ktranscripttest.h 53f3ce0 autotests/ktranscripttest.cpp 78aecb4 src/ktranscript.cpp c922e91 src/ktranscript_p.h f1cc132 Diff: https://git.reviewboard.kde.org/r/115936/diff/ Testing --- All three tests run without failure 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 115485: Porting KTranscript from KJS to QtScript
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115485/ --- (Updated Feb. 21, 2014, 4:30 p.m.) Review request for KDE Frameworks and Chusslove Illich. Changes --- Add dependency to test refactoring review Repository: ki18n Description --- Attempt at replacing the KJS dependency with a QtScript, i.e. making ki18n a tier1 framework. Needs more testing and likely fixing Diffs - CMakeLists.txt 3e099d5 src/CMakeLists.txt 9e3ce9f src/ktranscript.cpp c922e91 Diff: https://git.reviewboard.kde.org/r/115485/diff/ Testing --- Unittest runs, but the test script is very minimal and would need to be extendedb by someone who understands the scripting requirements. There is also a weird crash at test shutdown, in QThreadStorage. As far as I can tell I did not change anything related to threads though. 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 115936: Split ki18n ktranscript tests into one using the plugin and one instantiating/destroying the class directly
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115936/ --- (Updated Feb. 22, 2014, 1:42 p.m.) Review request for KDE Frameworks and Chusslove Illich. Changes --- Renamed the tests as suggested. Kept one test in ktranscriptcleantest as a template, with a comment that it can be replaced by the first actual clean-slate test Repository: ki18n Description --- Separate ktranscript plugin test into its own autotest The plugin based test of KTranscript performs all tests with a single instance of KTranscriptImp because the plugin uses Q_GLOBAL_STATIC to create and access that instance. The non-plugin test creates a new instance for every test. Currently all scripting tests are runnable in both situations, but the non-plugin test allows for tests that need a "clean slate". Diffs (updated) - autotests/CMakeLists.txt eb73d21 autotests/ktranscriptcleantest.h PRE-CREATION autotests/ktranscriptcleantest.cpp PRE-CREATION autotests/ktranscripttest.h 53f3ce0 autotests/ktranscripttest.cpp 78aecb4 src/ktranscript.cpp c922e91 src/ktranscript_p.h f1cc132 Diff: https://git.reviewboard.kde.org/r/115936/diff/ Testing --- All three tests run without failure 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 115485: Porting KTranscript from KJS to QtScript
> On Feb. 22, 2014, 1:35 p.m., Chusslove Illich wrote:
> > I tried to run a standalone non-GUI program using ki18n:
> >
> > #include
> > #include
> >
> > int main (int argc, char *argv[])
> > {
> > setlocale (LC_ALL, "");
> > KLocalizedString::setApplicationDomain("test-ki18n-01");
> > qDebug() << i18n("Delete %1?", i18n("file"));
> > return 0;
> > }
> >
> > and got abort with this message:
> >
> > QScriptEngine: Must construct a Q(Core)Application before a QScriptEngine
> >
> > It does work when I add only
> >
> > #include
> > ...
> > QCoreApplication a(argc, argv);
> >
> > What is the reason that this is necessary? If one does want to use ki18n in
> > non-Qt-UI program, would it be inappropriate (in whatever way) to
> > nevertheless require creation of QCoreApplication?
> >
QCoreApplication is for non-UI Qt applications, QGuiApplication and its
subclass QApplication are the ones for UI programs.
I was under the impression that translations always require the presence of a
QCoreApplication (or derived) instance. Qt's own tr() does.
- Kevin
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115485/#review50522
---
On Feb. 21, 2014, 4:30 p.m., Kevin Krammer wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115485/
> ---
>
> (Updated Feb. 21, 2014, 4:30 p.m.)
>
>
> Review request for KDE Frameworks and Chusslove Illich.
>
>
> Repository: ki18n
>
>
> Description
> ---
>
> Attempt at replacing the KJS dependency with a QtScript, i.e. making ki18n a
> tier1 framework.
> Needs more testing and likely fixing
>
>
> Diffs
> -
>
> CMakeLists.txt 3e099d5
> src/CMakeLists.txt 9e3ce9f
> src/ktranscript.cpp c922e91
>
> Diff: https://git.reviewboard.kde.org/r/115485/diff/
>
>
> Testing
> ---
>
> Unittest runs, but the test script is very minimal and would need to be
> extendedb by someone who understands the scripting requirements.
> There is also a weird crash at test shutdown, in QThreadStorage. As far as I
> can tell I did not change anything related to threads though.
>
>
> 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 115936: Split ki18n ktranscript tests into one using the plugin and one instantiating/destroying the class directly
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115936/ --- (Updated Feb. 22, 2014, 1:48 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Chusslove Illich. Repository: ki18n Description --- Separate ktranscript plugin test into its own autotest The plugin based test of KTranscript performs all tests with a single instance of KTranscriptImp because the plugin uses Q_GLOBAL_STATIC to create and access that instance. The non-plugin test creates a new instance for every test. Currently all scripting tests are runnable in both situations, but the non-plugin test allows for tests that need a "clean slate". Diffs - autotests/CMakeLists.txt eb73d21 autotests/ktranscriptcleantest.h PRE-CREATION autotests/ktranscriptcleantest.cpp PRE-CREATION autotests/ktranscripttest.h 53f3ce0 autotests/ktranscripttest.cpp 78aecb4 src/ktranscript.cpp c922e91 src/ktranscript_p.h f1cc132 Diff: https://git.reviewboard.kde.org/r/115936/diff/ Testing --- All three tests run without failure 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 115485: Porting KTranscript from KJS to QtScript
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115485/ --- (Updated Feb. 22, 2014, 1:58 p.m.) Review request for KDE Frameworks and Chusslove Illich. Changes --- Updated for rebase Repository: ki18n Description --- Attempt at replacing the KJS dependency with a QtScript, i.e. making ki18n a tier1 framework. Needs more testing and likely fixing Diffs (updated) - CMakeLists.txt 06fb696 autotests/CMakeLists.txt c4d6b9b src/CMakeLists.txt 9e3ce9f src/ktranscript.cpp b9e0551 Diff: https://git.reviewboard.kde.org/r/115485/diff/ Testing --- Unittest runs, but the test script is very minimal and would need to be extendedb by someone who understands the scripting requirements. There is also a weird crash at test shutdown, in QThreadStorage. As far as I can tell I did not change anything related to threads though. 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 115485: Porting KTranscript from KJS to QtScript
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115485/ --- (Updated Feb. 22, 2014, 2 p.m.) Review request for KDE Frameworks and Chusslove Illich. Changes --- missed some debug statements, again :-/ Repository: ki18n Description --- Attempt at replacing the KJS dependency with a QtScript, i.e. making ki18n a tier1 framework. Needs more testing and likely fixing Diffs (updated) - autotests/CMakeLists.txt c4d6b9b src/CMakeLists.txt 9e3ce9f src/ktranscript.cpp b9e0551 CMakeLists.txt 06fb696 Diff: https://git.reviewboard.kde.org/r/115485/diff/ Testing --- Unittest runs, but the test script is very minimal and would need to be extendedb by someone who understands the scripting requirements. There is also a weird crash at test shutdown, in QThreadStorage. As far as I can tell I did not change anything related to threads though. 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 115485: Porting KTranscript from KJS to QtScript
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115485/ --- (Updated Feb. 22, 2014, 2:15 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Chusslove Illich. Repository: ki18n Description --- Attempt at replacing the KJS dependency with a QtScript, i.e. making ki18n a tier1 framework. Needs more testing and likely fixing Diffs - autotests/CMakeLists.txt c4d6b9b src/CMakeLists.txt 9e3ce9f src/ktranscript.cpp b9e0551 CMakeLists.txt 06fb696 Diff: https://git.reviewboard.kde.org/r/115485/diff/ Testing --- Unittest runs, but the test script is very minimal and would need to be extendedb by someone who understands the scripting requirements. There is also a weird crash at test shutdown, in QThreadStorage. As far as I can tell I did not change anything related to threads though. Thanks, Kevin Krammer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Porting feedback: Hiding the Help button in KConfigDialog
On Sunday, 2014-02-23, 10:54:01, Kevin Ottens wrote: > On Sunday 23 February 2014 10:08:13 David Faure wrote: > > On Monday 17 February 2014 16:00:08 Eike Hein wrote: > > > Hi, > > > > > > in the KDialog-based KConfigDialog of yesteryear, it was fairly easy > > > > > > to hide the Help button: > > > dialog->button(KDialog::Help)->hide(); > > > > > > This is useful for apps that don't (yet) ship a handbook, since it > > > avoids mounting user frustration when a click on Help actually re- > > > sults in a nasty error message (though it's actually looking less > > > nasty these days). > > > > > > In Frameworks, this isn't possible any longer since the buttons > > > reside in a private QDialogButtonBox. Might be nice to get it back > > > tho ... > > > > Kévin? (this is your port). > > Hmmm yes, I was sure I replied in this thread though... apparently not. :-) > > > Should we add an accessor for the QDialogButtonBox in KConfigDialog? > > > > On one hand this could interfer with some of the internal handling > > (enabling/disabling "Defaults", "Apply", "Restore"...) but on the other > > hand this was possible before too (using KDialog members), and it gives > > most flexibility to the apps (e.g. adding another button, even). > > Yep, was my thought as well in the imaginary email I sent. :-) > > The more secure alternative would be hideButton() and addButton() which > would take respectively a button code and a pointer to a button. That'd > avoid breaking the encapsulation. > > I don't think I have a preference between the two. One breaks encapsulation > badly, the other one carries the risk of API explosion later on (if we want > to provide more control than just hiding). My initial thought was to suggest doing the same as in the Qt4 version, i.e. having a button() method to allows access to be buttons. That would make it less implementation specific, i.e. would still work if QDialogButtonBox is replaced with something else in the future. But usage of the button box already leaks, there are two protected accessors 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: Porting feedback: Hiding the Help button in KConfigDialog
On Sunday, 2014-02-23, 18:41:38, David Faure wrote: > On Sunday 23 February 2014 14:17:29 Kevin Krammer wrote: > > But usage of the button box already leaks, there are two protected > > accessors to it. > > In which class? You lost me. KPageDialog, base class of KConfigDialog according to the API docs http://api.kde.org/frameworks-api/frameworks5-apidocs/kwidgetsaddons/html/classKPageDialog.html 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: kguiaddons uses qpa headers?
On Sunday, 2014-02-23, 17:02:55, John Layt wrote: > Hi, > > I'm building all of Frameworks from scratch for the first time, using the > openSUSE packages for Qt 5.2, and qguiaddons fails with: > > [ 24%] Building CXX object > src/CMakeFiles/KF5GuiAddons.dir/util/kmodifierkeyinfoprovider_x11.cpp.o > /media/build/kdesrc- > build/src/k5/frameworks/kguiaddons/src/util/kmodifierkeyinfoprovider_x11.cpp > :26:42: fatal error: qpa/qplatformnativeinterface.h: No such file or > directory > > This is because qpa headers are considered private and are packaged > separately by openSUSE. I'm not sure depending on private/qpa headers is > such a good thing? Or is there no other option here? I am not sure it is wise to consider the QPA headers as private, most of them are not. QPlatformInterface, for example, is clearly an exposed type, there is an accessor in QGuiApplication that returns a pointer to it. Obviously the returned object and its functionality is platform specific, but afterall its very purpose is to enable platform integration that goes beyond the things that can be wrapped in an abstraction across multiple platforms. 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
Review Request 115979: Cleanup after QtScript port
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115979/ --- Review request for KDE Frameworks and Chusslove Illich. Repository: ki18n Description --- Update framework tier. Remove unused enum. Remove no longer applicable search for KJS. Consistent block braces for if statements. Diffs - KF5I18nConfig.cmake.in 7225bf5 ki18n.yaml 9b601d5 src/ktranscript.cpp 4cdae75 Diff: https://git.reviewboard.kde.org/r/115979/diff/ Testing --- Everything still builds and tests succeed. 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 115979: Cleanup after QtScript port
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115979/ --- (Updated Feb. 23, 2014, 9:25 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Chusslove Illich. Repository: ki18n Description --- Update framework tier. Remove unused enum. Remove no longer applicable search for KJS. Consistent block braces for if statements. Diffs - KF5I18nConfig.cmake.in 7225bf5 ki18n.yaml 9b601d5 src/ktranscript.cpp 4cdae75 Diff: https://git.reviewboard.kde.org/r/115979/diff/ Testing --- Everything still builds and tests succeed. Thanks, Kevin Krammer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115983: Reduce memory leaks
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115983/ --- Review request for KDE Frameworks and Chusslove Illich. Repository: ki18n Description --- Create the script engine as a QObject child of the interface and delete all interfaces in KTranscriptImp's destructor. valgrind --tool=memcheck ./ktranscripttest before: ==10664== HEAP SUMMARY: ==10664== in use at exit: 445,913 bytes in 2,753 blocks ==10664== total heap usage: 27,995 allocs, 25,242 frees, 6,059,328 bytes allocated ==10664== ==10664== LEAK SUMMARY: ==10664==definitely lost: 0 bytes in 0 blocks ==10664==indirectly lost: 0 bytes in 0 blocks ==10664== possibly lost: 1,488 bytes in 3 blocks ==10664==still reachable: 444,425 bytes in 2,750 blocks ==10664== suppressed: 0 bytes in 0 blocks after: ==11788== HEAP SUMMARY: ==11788== in use at exit: 13,778 bytes in 66 blocks ==11788== total heap usage: 28,003 allocs, 27,937 frees, 6,064,040 bytes allocated ==11788== ==11788== LEAK SUMMARY: ==11788==definitely lost: 0 bytes in 0 blocks ==11788==indirectly lost: 0 bytes in 0 blocks ==11788== possibly lost: 1,488 bytes in 3 blocks ==11788==still reachable: 12,290 bytes in 63 blocks ==11788== suppressed: 0 bytes in 0 blocks Diffs - src/ktranscript.cpp 1ce0d1a Diff: https://git.reviewboard.kde.org/r/115983/diff/ Testing --- All tests still run successfully 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 115983: Reduce memory leaks
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115983/#review50614 --- It is obviously not really a leak since the KTranscriptImp object is never deleted during runtime. So this just cleans up before process exit - Kevin Krammer On Feb. 23, 2014, 9:52 p.m., Kevin Krammer wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115983/ > --- > > (Updated Feb. 23, 2014, 9:52 p.m.) > > > Review request for KDE Frameworks and Chusslove Illich. > > > Repository: ki18n > > > Description > --- > > Create the script engine as a QObject child of the interface and > delete all interfaces in KTranscriptImp's destructor. > > valgrind --tool=memcheck ./ktranscripttest > > before: > > > ==10664== HEAP SUMMARY: > ==10664== in use at exit: 445,913 bytes in 2,753 blocks > ==10664== total heap usage: 27,995 allocs, 25,242 frees, 6,059,328 bytes > allocated > ==10664== > ==10664== LEAK SUMMARY: > ==10664==definitely lost: 0 bytes in 0 blocks > ==10664==indirectly lost: 0 bytes in 0 blocks > ==10664== possibly lost: 1,488 bytes in 3 blocks > ==10664==still reachable: 444,425 bytes in 2,750 blocks > ==10664== suppressed: 0 bytes in 0 blocks > > > after: > > ==11788== HEAP SUMMARY: > ==11788== in use at exit: 13,778 bytes in 66 blocks > ==11788== total heap usage: 28,003 allocs, 27,937 frees, 6,064,040 bytes > allocated > ==11788== > ==11788== LEAK SUMMARY: > ==11788==definitely lost: 0 bytes in 0 blocks > ==11788==indirectly lost: 0 bytes in 0 blocks > ==11788== possibly lost: 1,488 bytes in 3 blocks > ==11788==still reachable: 12,290 bytes in 63 blocks > ==11788== suppressed: 0 bytes in 0 blocks > > > Diffs > - > > src/ktranscript.cpp 1ce0d1a > > Diff: https://git.reviewboard.kde.org/r/115983/diff/ > > > Testing > --- > > All tests still run successfully > > > 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 115983: Reduce memory leaks
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115983/#review50615 --- It is obviously not really a leak since the KTranscriptImp object is never deleted during runtime. So this just cleans up before process exit - Kevin Krammer On Feb. 23, 2014, 9:52 p.m., Kevin Krammer wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115983/ > --- > > (Updated Feb. 23, 2014, 9:52 p.m.) > > > Review request for KDE Frameworks and Chusslove Illich. > > > Repository: ki18n > > > Description > --- > > Create the script engine as a QObject child of the interface and > delete all interfaces in KTranscriptImp's destructor. > > valgrind --tool=memcheck ./ktranscripttest > > before: > > > ==10664== HEAP SUMMARY: > ==10664== in use at exit: 445,913 bytes in 2,753 blocks > ==10664== total heap usage: 27,995 allocs, 25,242 frees, 6,059,328 bytes > allocated > ==10664== > ==10664== LEAK SUMMARY: > ==10664==definitely lost: 0 bytes in 0 blocks > ==10664==indirectly lost: 0 bytes in 0 blocks > ==10664== possibly lost: 1,488 bytes in 3 blocks > ==10664==still reachable: 444,425 bytes in 2,750 blocks > ==10664== suppressed: 0 bytes in 0 blocks > > > after: > > ==11788== HEAP SUMMARY: > ==11788== in use at exit: 13,778 bytes in 66 blocks > ==11788== total heap usage: 28,003 allocs, 27,937 frees, 6,064,040 bytes > allocated > ==11788== > ==11788== LEAK SUMMARY: > ==11788==definitely lost: 0 bytes in 0 blocks > ==11788==indirectly lost: 0 bytes in 0 blocks > ==11788== possibly lost: 1,488 bytes in 3 blocks > ==11788==still reachable: 12,290 bytes in 63 blocks > ==11788== suppressed: 0 bytes in 0 blocks > > > Diffs > - > > src/ktranscript.cpp 1ce0d1a > > Diff: https://git.reviewboard.kde.org/r/115983/diff/ > > > Testing > --- > > All tests still run successfully > > > 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 115983: Reduce memory leaks
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115983/ --- (Updated Feb. 23, 2014, 10:14 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Chusslove Illich. Repository: ki18n Description --- Create the script engine as a QObject child of the interface and delete all interfaces in KTranscriptImp's destructor. valgrind --tool=memcheck ./ktranscripttest before: ==10664== HEAP SUMMARY: ==10664== in use at exit: 445,913 bytes in 2,753 blocks ==10664== total heap usage: 27,995 allocs, 25,242 frees, 6,059,328 bytes allocated ==10664== ==10664== LEAK SUMMARY: ==10664==definitely lost: 0 bytes in 0 blocks ==10664==indirectly lost: 0 bytes in 0 blocks ==10664== possibly lost: 1,488 bytes in 3 blocks ==10664==still reachable: 444,425 bytes in 2,750 blocks ==10664== suppressed: 0 bytes in 0 blocks after: ==11788== HEAP SUMMARY: ==11788== in use at exit: 13,778 bytes in 66 blocks ==11788== total heap usage: 28,003 allocs, 27,937 frees, 6,064,040 bytes allocated ==11788== ==11788== LEAK SUMMARY: ==11788==definitely lost: 0 bytes in 0 blocks ==11788==indirectly lost: 0 bytes in 0 blocks ==11788== possibly lost: 1,488 bytes in 3 blocks ==11788==still reachable: 12,290 bytes in 63 blocks ==11788== suppressed: 0 bytes in 0 blocks Diffs - src/ktranscript.cpp 1ce0d1a Diff: https://git.reviewboard.kde.org/r/115983/diff/ Testing --- All tests still run successfully 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 115485: Porting KTranscript from KJS to QtScript
> On Feb. 22, 2014, 3:24 p.m., Michael Palimaka wrote: > > If this is tier 1 now, please don't forget to update the wiki and the yaml > > file. > > Hrvoje Senjan wrote: > Also find_dependency(KF5JS "@KF5_VERSION@") can go away =) Both good catches. All in now - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115485/#review50535 --- On Feb. 22, 2014, 2:15 p.m., Kevin Krammer wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115485/ > --- > > (Updated Feb. 22, 2014, 2:15 p.m.) > > > Review request for KDE Frameworks and Chusslove Illich. > > > Repository: ki18n > > > Description > --- > > Attempt at replacing the KJS dependency with a QtScript, i.e. making ki18n a > tier1 framework. > Needs more testing and likely fixing > > > Diffs > - > > autotests/CMakeLists.txt c4d6b9b > src/CMakeLists.txt 9e3ce9f > src/ktranscript.cpp b9e0551 > CMakeLists.txt 06fb696 > > Diff: https://git.reviewboard.kde.org/r/115485/diff/ > > > Testing > --- > > Unittest runs, but the test script is very minimal and would need to be > extendedb by someone who understands the scripting requirements. > There is also a weird crash at test shutdown, in QThreadStorage. As far as I > can tell I did not change anything related to threads though. > > > Thanks, > > Kevin Krammer > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
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/ --- 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/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 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 Feb. 25, 2014, 4:17 p.m.) Review request for KDE Frameworks and Chusslove Illich. Changes --- Added function to remove test config after test and call it from cleanupTestCase. Renamed new config file to ktranscript.ini, should fit better in cross-platform world 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 (updated) - autotests/CMakeLists.txt 6e926ba 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
Review Request 116049: Adjust tier for changed ki18n tier
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116049/ --- 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
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/ --- 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
Review Request 116051: Adjust kunitconversion tier for changed ki18n tier
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116051/ --- Review request for KDE Frameworks, John Layt and Petri Damstén. Repository: kunitconversion Description --- ki18n changed from tier 2 to tier 1. kunitconversion only depends on tier 1 now, becomes tier 2 Diffs - kunitconversion.yaml 78c0a75 Diff: https://git.reviewboard.kde.org/r/116051/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. 25, 2014, 5:25 p.m.) Review request for KDE Frameworks and Bernd Buschinski. Changes --- update title to include target framework name Summary (updated) - Adjust kjsembed tier for changed ki18n tier 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 116051: Adjust kunitconversion tier for changed ki18n tier
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116051/ --- (Updated Feb. 25, 2014, 6:16 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, John Layt and Petri Damstén. Repository: kunitconversion Description --- ki18n changed from tier 2 to tier 1. kunitconversion only depends on tier 1 now, becomes tier 2 Diffs - kunitconversion.yaml 78c0a75 Diff: https://git.reviewboard.kde.org/r/116051/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: Sonnet status?
On Wednesday, 2012-11-21, David Faure wrote:
> On Wednesday 21 November 2012 21:00:27 Martin Sandsmark wrote:
> Hmm, I'm not sure why I wrote "for one setting", grepping again shows much
> more.
>
> ./settings.cpp:192:const QStringList ignores =
> conf.readEntry(ignoreEntry, QStringList()); ./settings.cpp:227:
> d->defaultClient = conf.readEntry("defaultClient", ./settings.cpp:229:
> d->defaultLanguage = conf.readEntry(
> ./settings.cpp:233:d->checkUppercase = conf.readEntry(
> ./settings.cpp:236:d->skipRunTogether = conf.readEntry(
> ./settings.cpp:239:d->backgroundCheckerEnabled = conf.readEntry(
> ./settings.cpp:242:d->checkerEnabledByDefault = conf.readEntry(
> ./settings.cpp:245:d->disablePercentage =
> conf.readEntry("Sonnet_AsYouTypeDisablePercentage", 42);
> ./settings.cpp:246:d->disableWordCount =
> conf.readEntry("Sonnet_AsYouTypeDisableWordCount", 100);
>
> (The last two look like overkill, they are not written out by save(), I
> think it was just someone too afraid to commit hardcoded numbers...)
>
> > Could I just use QSettings there? Or is there a better solution?
>
> I don't really like porting our code from KConfig to QSettings in general,
> given that the Qt developers are already turning their back to QSettings,
> and given that QSettings doesn't support kiosk nor $XDG_CONFIG_DIRS.
> However, in this case it seems to be a simple set of user settings, not
> much point in system-wide settings for such things, so a plain text file
> would do, so QSettings will do too.
> So, OK for this one, but I really don't want to see all of KF5 ported to
> QSettings.
Or maybe just "save" into a QVariantHash and let the calling code decide how
to store 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: Review Request: port Sonnet to QSettings
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107791/#review23643 --- IMHO this is wrong. Not code wise but conceptual. As far as I understand QSettings is basically deprecated, it is just not official marked as such because there is no replacement. This would be porting away from a fully functional, way more advanced and maintained settings. If the sole goal of this endavor is to remove the KConfig dependency than this ought to be done by either having an interface that can be implemented through KConfig or by passing values as QVariant maps or hashes. - Kevin Krammer On Dec. 17, 2012, 9:15 p.m., Martin Tobias Holmedahl Sandsmark wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107791/ > --- > > (Updated Dec. 17, 2012, 9:15 p.m.) > > > Review request for KDE Frameworks, kdelibs and David Faure. > > > Description > --- > > Ported everything away from KConfig to QSettings. > > I couldn't really find any users of the ::save function, so I think the > source incompatible change would be worth it. Alternatively we could add a > deprecated dummy function that takes in a KConfig object and just ignores it, > and uses QSettings. > > > Diffs > - > > kdeui/sonnet/configdialog.h 7c4993b > kdeui/sonnet/configdialog.cpp 625441b > kdeui/sonnet/configwidget.h 023b659 > kdeui/sonnet/configwidget.cpp 549d5af > kdeui/sonnet/highlighter.cpp 6cbb14c > kdeui/widgets/ktextedit.cpp 71d2a9f > staging/sonnet/src/core/backgroundchecker.h f0da3a3 > staging/sonnet/src/core/backgroundchecker.cpp dc05b94 > staging/sonnet/src/core/globals.cpp bf4f504 > staging/sonnet/src/core/loader.cpp 887aee5 > staging/sonnet/src/core/settings.cpp 59cb593 > staging/sonnet/src/core/settings_p.h e14bad7 > staging/sonnet/src/core/speller.h 37dd82f > staging/sonnet/src/core/speller.cpp f831f55 > > Diff: http://git.reviewboard.kde.org/r/107791/diff/ > > > Testing > --- > > it builds. > > > Thanks, > > Martin Tobias Holmedahl Sandsmark > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request: port Sonnet to QSettings
> On Dec. 17, 2012, 10:38 p.m., Kevin Krammer wrote: > > IMHO this is wrong. > > Not code wise but conceptual. As far as I understand QSettings is basically > > deprecated, it is just not official marked as such because there is no > > replacement. This would be porting away from a fully functional, way more > > advanced and maintained settings. > > > > If the sole goal of this endavor is to remove the KConfig dependency than > > this ought to be done by either having an interface that can be implemented > > through KConfig or by passing values as QVariant maps or hashes. > > > > Oswald Buddenhagen wrote: > and where exactly do you see that kconfig maintainer? ;) > > it's unfortunate that the chosen config class is part of the API. > judging by uses, would it be reasonable to just disable that part of the > API indefinitely? > less drastically, would it be acceptable to pass a file name instead of a > config object? that would of course incur some overhead (assuming we are > passing the application's main config file). "it's unfortunate that the chosen config class is part of the API." Indeed. Most likely out of convenience. Hence the idea to just replace it with a generic key/value object that doesn't do any specific form of I/O and can allowing the using application to decide on persistant storage. But if I understand you correctly you would rather go for the full solution and make those properties directly read-/writable, right? - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107791/#review23643 --- On Dec. 17, 2012, 9:15 p.m., Martin Tobias Holmedahl Sandsmark wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107791/ > --- > > (Updated Dec. 17, 2012, 9:15 p.m.) > > > Review request for KDE Frameworks, kdelibs and David Faure. > > > Description > --- > > Ported everything away from KConfig to QSettings. > > I couldn't really find any users of the ::save function, so I think the > source incompatible change would be worth it. Alternatively we could add a > deprecated dummy function that takes in a KConfig object and just ignores it, > and uses QSettings. > > > Diffs > - > > kdeui/sonnet/configdialog.h 7c4993b > kdeui/sonnet/configdialog.cpp 625441b > kdeui/sonnet/configwidget.h 023b659 > kdeui/sonnet/configwidget.cpp 549d5af > kdeui/sonnet/highlighter.cpp 6cbb14c > kdeui/widgets/ktextedit.cpp 71d2a9f > staging/sonnet/src/core/backgroundchecker.h f0da3a3 > staging/sonnet/src/core/backgroundchecker.cpp dc05b94 > staging/sonnet/src/core/globals.cpp bf4f504 > staging/sonnet/src/core/loader.cpp 887aee5 > staging/sonnet/src/core/settings.cpp 59cb593 > staging/sonnet/src/core/settings_p.h e14bad7 > staging/sonnet/src/core/speller.h 37dd82f > staging/sonnet/src/core/speller.cpp f831f55 > > Diff: http://git.reviewboard.kde.org/r/107791/diff/ > > > Testing > --- > > it builds. > > > Thanks, > > Martin Tobias Holmedahl Sandsmark > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request: port Sonnet to QSettings
> On Dec. 17, 2012, 10:38 p.m., Kevin Krammer wrote: > > IMHO this is wrong. > > Not code wise but conceptual. As far as I understand QSettings is basically > > deprecated, it is just not official marked as such because there is no > > replacement. This would be porting away from a fully functional, way more > > advanced and maintained settings. > > > > If the sole goal of this endavor is to remove the KConfig dependency than > > this ought to be done by either having an interface that can be implemented > > through KConfig or by passing values as QVariant maps or hashes. > > > > Oswald Buddenhagen wrote: > and where exactly do you see that kconfig maintainer? ;) > > it's unfortunate that the chosen config class is part of the API. > judging by uses, would it be reasonable to just disable that part of the > API indefinitely? > less drastically, would it be acceptable to pass a file name instead of a > config object? that would of course incur some overhead (assuming we are > passing the application's main config file). > > Kevin Krammer wrote: > "it's unfortunate that the chosen config class is part of the API." > > Indeed. Most likely out of convenience. Hence the idea to just replace it > with a generic key/value object that doesn't do any specific form of I/O and > can allowing the using application to decide on persistant storage. But if I > understand you correctly you would rather go for the full solution and make > those properties directly read-/writable, right? > > Oswald Buddenhagen wrote: > the idea with the file name has the advantage that it is most natural, > but sort of slow, and it may actually not work - if the app uses kconfig, but > sonnet uses qsettings on the same file, you may actually get garbage out of > it. > > i'd strongly recommend not using a variant map, etc., as using it would > require lots of boilerplate code. > > if you make it so that instantiating is nothing else than > new Sonnet::ConfigDialog(new KConfigWrapper(new > KConfigGroup(KGlobal::config(), "Spellchecking"))); > it may be ok. still a bit ... weird. > you could make kconfiggroup directly implement the interface, but then > you'd get an asymmetry with qsettings. > also, where would KMapInterface be defined? where would the qsettings > wrapper live? > or maybe upstream QMapInterface and make QSettings implement it, too? > would it even fit the API? > > > Martin Tobias Holmedahl Sandsmark wrote: > What about not exposing any of the config storage details at all? We have > the application name, that should be enough to store application specific > settings. I agree with Ossi that filename would not work as you would need the same config handling facility on both sides of the API anyway. I am not sure though that he means with boilerplate code being needed. The access of the settings object right now seems to be pretty much just value lookups, potentially with default value. Something QHash::value() supports as far as I can see. Anyway, that was just an idea on how to keep the "load/save" behavior, I agree with Martin that Sonnet should not be exposed to storage at all, it should just work with the values it was configured with by the code using it. - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107791/#review23643 --- On Dec. 17, 2012, 9:15 p.m., Martin Tobias Holmedahl Sandsmark wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107791/ > --- > > (Updated Dec. 17, 2012, 9:15 p.m.) > > > Review request for KDE Frameworks, kdelibs and David Faure. > > > Description > --- > > Ported everything away from KConfig to QSettings. > > I couldn't really find any users of the ::save function, so I think the > source incompatible change would be worth it. Alternatively we could add a > deprecated dummy function that takes in a KConfig object and just ignores it, > and uses QSettings. > > > Diffs > - > > kdeui/sonnet/configdialog.h 7c4993b > kdeui/sonnet/configdialog.cpp 625441b > kdeui/sonnet/configwidget.h 023b659 > kdeui/sonnet/configwidget.cpp 549d5af > kdeui/sonnet/highlighter.cpp 6cbb14c > kdeui/widgets/ktextedit.cpp 71d2a9f > staging/sonnet/src/core/backgroun
Re: Review Request: port Sonnet to QSettings
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107791/#review24025 --- I am a bit puzzled by the usage of QSettings for file I/O. My, rather limited, understanding of QSettings in Qt5 context is that is mostly the same as in Qt4 and Qt4's version is AFAIK neither capable of doing hierachical files nor immutable settings nor environment/tool-output dependent values. All of which KConfig can do and which could have been deployed (especially hierachy and immutability). Or maybe I am misunderstanding the purpose of this endeavour, i.e. is this just exploring options and not idended to be ever merged into KF5? kdeui/sonnet/configdialog.h <http://git.reviewboard.kde.org/r/107791/#comment18309> explicit kdeui/sonnet/configdialog.h <http://git.reviewboard.kde.org/r/107791/#comment18310> Is this method necessary anymore? There is only one constructor, right? kdeui/sonnet/configwidget.h <http://git.reviewboard.kde.org/r/107791/#comment18311> explicit kdeui/sonnet/configwidget.cpp <http://git.reviewboard.kde.org/r/107791/#comment18313> Probably also move into constructor? kdeui/widgets/ktextedit.cpp <http://git.reviewboard.kde.org/r/107791/#comment18314> Especially since it seems to hardcode QSettings usage without any option for a KDE application to read from KConfig instead - Kevin Krammer On Dec. 27, 2012, 12:52 a.m., Martin Tobias Holmedahl Sandsmark wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107791/ > --- > > (Updated Dec. 27, 2012, 12:52 a.m.) > > > Review request for KDE Frameworks, kdelibs and David Faure. > > > Description > --- > > Ported everything away from KConfig to QSettings. > > I couldn't really find any users of the ::save function, so I think the > source incompatible change would be worth it. Alternatively we could add a > deprecated dummy function that takes in a KConfig object and just ignores it, > and uses QSettings. > > > Diffs > - > > kdeui/sonnet/configdialog.h 7c4993b > kdeui/sonnet/configdialog.cpp 625441b > kdeui/sonnet/configwidget.h 023b659 > kdeui/sonnet/configwidget.cpp 549d5af > kdeui/sonnet/highlighter.cpp 6cbb14c > kdeui/sonnet/tests/test_configdialog.cpp 4c4fd21 > kdeui/widgets/ktextedit.h d0c1c4d > kdeui/widgets/ktextedit.cpp 71d2a9f > staging/sonnet/src/core/backgroundchecker.h f0da3a3 > staging/sonnet/src/core/backgroundchecker.cpp dc05b94 > staging/sonnet/src/core/globals.cpp bf4f504 > staging/sonnet/src/core/loader.cpp 887aee5 > staging/sonnet/src/core/settings.cpp 59cb593 > staging/sonnet/src/core/settings_p.h e14bad7 > staging/sonnet/src/core/speller.h 37dd82f > staging/sonnet/src/core/speller.cpp f831f55 > > Diff: http://git.reviewboard.kde.org/r/107791/diff/ > > > Testing > --- > > it builds. > > > Thanks, > > Martin Tobias Holmedahl Sandsmark > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request: port Sonnet to QSettings
> On Dec. 27, 2012, 10:33 a.m., Kevin Krammer wrote: > > I am a bit puzzled by the usage of QSettings for file I/O. > > > > My, rather limited, understanding of QSettings in Qt5 context is that is > > mostly the same as in Qt4 and Qt4's version is AFAIK neither capable of > > doing hierachical files nor immutable settings nor environment/tool-output > > dependent values. > > All of which KConfig can do and which could have been deployed (especially > > hierachy and immutability). > > > > Or maybe I am misunderstanding the purpose of this endeavour, i.e. is this > > just exploring options and not idended to be ever merged into KF5? > > David Faure wrote: > Right, QSettings doesn't do these things (well, it does hierarchical, but > only two levels -- this is the most common use case, though). > But this is about simple spell-checking... why would an administrator > need immutable settings, or environment variables / tool output in config > keys? This is typically user preferences. > > Any Qt-only library would do exactly this (use QSettings internally, > waiting for a better solution in Qt). > > Yes, someone should really work on getting a better configuration > framework into Qt (e.g. splitting out windows registry stuff out of > QSettings, to make QSettings INI-only, add a KConfigGroup equivalent to > QSettings, and make it support multiple levels of hierarchy via > QStandardPaths). Two levels are most likley the most common case because most systems do not have any system administrator. Once you have admin customization you have at least three (package, admin, user). I don't have any evidence for nor against usage of Kiosk features in regard to spell checking, I am just pointing out that the solution proposed here does have none of those. I also don't think it matters that a Qt-only library would do exactly this, a Qt-only library would not have been part of a solution that offered those option in the first place. The reuse of the filename "sonnetrc" suggest to me that the intention is to use the same file. A KConfig based application and a QSettings based application will behave inconsitently if using the same file. Or is this a per-application stored file? Do we assume that KDE application developers who's programs are being used in an "Enterprise" setup will fork the library and reimplement the config with KConfig or do we want them to use the KF5 version? The later will either require that the library does not handle config itself or at least allows applications to intercept config access or provide config that takes precendence over stored config. IMHO the most sensible case is to let the application handle config I/O, allowing it to store the config in a way that is most approriate for its usage. If that is a KConfig INI file, a simple QSetting INI file or a JSON file shouldn't really matter to an engine which only is interested in the values. - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107791/#review24025 --- On Dec. 27, 2012, 12:52 a.m., Martin Tobias Holmedahl Sandsmark wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107791/ > --- > > (Updated Dec. 27, 2012, 12:52 a.m.) > > > Review request for KDE Frameworks, kdelibs and David Faure. > > > Description > --- > > Ported everything away from KConfig to QSettings. > > I couldn't really find any users of the ::save function, so I think the > source incompatible change would be worth it. Alternatively we could add a > deprecated dummy function that takes in a KConfig object and just ignores it, > and uses QSettings. > > > Diffs > - > > kdeui/sonnet/configdialog.h 7c4993b > kdeui/sonnet/configdialog.cpp 625441b > kdeui/sonnet/configwidget.h 023b659 > kdeui/sonnet/configwidget.cpp 549d5af > kdeui/sonnet/highlighter.cpp 6cbb14c > kdeui/sonnet/tests/test_configdialog.cpp 4c4fd21 > kdeui/widgets/ktextedit.h d0c1c4d > kdeui/widgets/ktextedit.cpp 71d2a9f > staging/sonnet/src/core/backgroundchecker.h f0da3a3 > staging/sonnet/src/core/backgroundchecker.cpp dc05b94 > staging/sonnet/src/core/globals.cpp bf4f504 > staging/sonnet/src/core/loader.cpp 887aee5 > staging/sonnet/src/core/settings.cpp 59cb593 > staging/sonnet/src/core/settings_p.h e14bad7 > staging/sonnet/src/core/speller.h 37dd82f
Re: Review Request: port Sonnet to QSettings
On Thursday, 2012-12-27, Martin Tobias Holmedahl Sandsmark wrote: > On Thu, Dec 27, 2012 at 12:18:21PM -0000, Kevin Krammer wrote: > > Two levels are most likley the most common case because most systems do > > not have any system administrator. Once you have admin customization you > > have at least three (package, admin, user). I don't have any evidence > > for nor against usage of Kiosk features in regard to spell checking, I > > am just pointing out that the solution proposed here does have none of > > those. > > Well, the library in question here does spell checking, so that's what we > should focus on. IMHO spell checking doesn't need any of the extra features > offered by KConfig. Indeed, it should be doing any form of config IO. It can't know whether any of its options need to be persisted, or are supplied hardcoded by the using code or offered to the user but volatile or offered the users and stored persistently or confgured by the system administrator or configured by the system vendor. Due to the old code we can deduce that the option values were potentially stored persistently, allowing user, administrator and system vendor to provide, override and lock-down each of them. But as you said yourself: it does spell checking, it does not have to care about settings persistence at all. > > The reuse of the filename "sonnetrc" suggest to me that the intention is > > to use the same file. A KConfig based application and a QSettings based > > application will behave inconsitently if using the same file. Or is this > > a per-application stored file? > > Do I use sonnetrc anywhere? In that case I missed something. You are right, sonnet does not. Somehow the change request seems to have picked up an unrelated change in kdeui/widgets/ktextedit.cpp:71 > > Do we assume that KDE application developers who's programs are being > > used in an "Enterprise" setup will fork the library and reimplement the > > config with KConfig or do we want them to use the KF5 version? The later > > will either require that the library does not handle config itself or at > > least allows applications to intercept config access or provide config > > that takes precendence over stored config. > > If they care about that they can just load using whatever config system > they want, and set the loaded options manually. My point exactly! > I also don't think this is a very likely scenario, tbh. No idea, maybe they all just hard-code values. The old code's usage of KConfig and the config access in ktextedit.cpp suggests that some applications wanted to settings to stay configurable. In either case nothing the spell checker needs to care about. It uses the values, it has no interest what so ever in how it got them in the first place. > > IMHO the most sensible case is to let the application handle config I/O, > > allowing it to store the config in a way that is most approriate for its > > usage. If that is a KConfig INI file, a simple QSetting INI file or a > > JSON file shouldn't really matter to an engine which only is interested > > in the values. > > I think the most sensible is to not let the application developers bother > their pretty little heads with storing the config at all if they don't want > to. Of course, I had assumed that all settings had hard-coded default values. I was referring to application developers who want their apps spell checking capabilities configurable. Those developers already bothered their pretty little heads with config storing and loading, again removing the need for the spell checker to bother. > With what I have proposed here they can reimplement the config storage if > they want to, but by default It Just Works™. My problem with understanding this is: why does the spell checker need the capability to secretly access persistent config? Removing its internal config access will still have it "Just Works" by default (again assuming that those variables are at least initialized properly). Lets look at Sonnet::Speller (judging by its export macro a public class). It has two methods, save and restore, that have no indication what so ever on where they would save to or restore from. Hyperspace probably. It does not, however, have any way to retrieve the Sonnet::Settings object on which's content it supposeldy operates. Or when I look at Sonnet::ConfigWidget, supposedly at widget providing consistent user interface for Sonnet options. Again some ominous save() method without any way to tell it where and how to save and again not way to retrieve the Sonnet::Settings object this is supposedly working on. So I looked at Sonnet::Loader which seemed to be referred to a lot regarding settings. Finally, a way to acce
Re: Finalized proposal for changes to i18n in KF5
On Friday, 2013-01-04, Oswald Buddenhagen wrote: > random ramblings: > > i don't like the recommendation for extracted vs. disambiguating > comments (and closed-source authors will typically do the exact opposite > anyway). The opposite thing as in only having comments and not caring at all about ambiguity and that it makes the translations of their software suck? If so, why should we care? We offer the options of doing it better and have recommendations based on more than a decade of large scale i18n. Is there any reason at all other than lazy programmers to even have i18n functions that are not i18nc variants (i.e. require a comment)? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: "kde5" or "kf5" ?
On Sunday, 2013-02-17, David Faure wrote: > The thing is, it could be either a pure QStandardPaths equivalent, or for > more compatibility with kde4-config it would also still answer requests > for e.g. --path xdgdata-icon, even if internally that's just > GenericDataLocation + "/icons". > > In the first case we would call it something like qpaths and even put it > into Qt, while in the second case it could be called kf5-config. > > Well, maximing compatibility (= minimizing porting efforts for users) is > good, so let's go for kf5-config. IMHO something like qpath sounds better. I don't think there is a lot of usage of those special paths and even if there is any script would have to be updated to the new executable name anyway. 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
