Re: Review Request 119267: Adding KWindowSystem::setOnActivities(WId win, const QStringList activities) method
On July 31, 2014, 2:03 p.m., Thomas Lübking wrote: src/kwindowinfo_x11.cpp, line 305 https://git.reviewboard.kde.org/r/119267/diff/2/?file=292848#file292848line305 Any chance we can make this a function return in netwm.h to be used by the lib, kactivities and kwin and plasma and whoever else? NETWM::allActivityUUID() or so? Ivan Čukić wrote: The problem is that the null uuid is not really meant to be visible to the outside world. So, while the kwindowsystem can have the relevant definition in a single location and refered from the two places it is currently present in (src/netwm.cpp and this), it should not be visible from the outside world. That is the reason for the above check - if the window has null uuid for activity, and empty string list is returned by the method. All the clients of kwindowsystem should be able to be implemented without knowing that null uuid is a special value. For kactivities, the value is used only if the daemon is not running - in that case, the library returns a single activity (because we need to have at least one at all times to avoid special cases in all clients) whose id is null uuid. Still, most clients should have no idea that it is not a proper activity. In kwin, it was used since (as usual, alongside plasma) kwin is 1% and null uuid was suitable to represent 'all activities' with or without kactivitymanagerd running. Thomas Lübking wrote: supersecret netwm.h #define KDE_ALL_ACTIVITY_UUID ---- ? What I basically do not like about this string is that several components need to silently agree on a certain string (w/o any compiletime sanity check) - and this particular one also is easily broken (nobody will notice that there's a 0 too few or much ;-) I think exposing a method in NETWM would be fine. It's API nobody should use - it's X11 specific and too low level for anybody except KWin and KWindowSystem to use. Export it, mark it as internal and if it changes KWin will have been warned ;-) - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119267/#review63557 --- On Aug. 7, 2014, 7:15 a.m., Ivan Čukić wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119267/ --- (Updated Aug. 7, 2014, 7:15 a.m.) Review request for KDE Frameworks, kwin and Martin Gräßlin. Repository: kwindowsystem Description --- Currently, the library only has the method for retrieving a list of activities a window belongs to. This is adding a method which provides changing the list of activities for a window. Diffs - autotests/kwindowinfox11test.cpp 50ce806 src/kwindowinfo_x11.cpp 041dfd3 src/kwindowsystem.h 0b58e71 src/kwindowsystem.cpp fb59603 src/kwindowsystem_p.h 8861844 src/kwindowsystem_p_x11.h 9baa6ae src/kwindowsystem_x11.cpp 2016820 src/netwm.h 2d812a7 src/netwm.cpp 1daad1e src/netwm_p.h a201cb6 Diff: https://git.reviewboard.kde.org/r/119267/diff/ Testing --- Yes, works with the new activity switcher. Thanks, Ivan Čukić ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119267: Adding KWindowSystem::setOnActivities(WId win, const QStringList activities) method
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119267/#review64230 --- Ship it! src/kwindowsystem.h https://git.reviewboard.kde.org/r/119267/#comment44880 I think we are now too late for 5.1 :-) src/netwm.cpp https://git.reviewboard.kde.org/r/119267/#comment44881 I'm wondering about the type - most string properties are utf8 type. The ids are base64, aren't they? So string type is in fact sufficient? - Martin Gräßlin On Aug. 7, 2014, 7:15 a.m., Ivan Čukić wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119267/ --- (Updated Aug. 7, 2014, 7:15 a.m.) Review request for KDE Frameworks, kwin and Martin Gräßlin. Repository: kwindowsystem Description --- Currently, the library only has the method for retrieving a list of activities a window belongs to. This is adding a method which provides changing the list of activities for a window. Diffs - autotests/kwindowinfox11test.cpp 50ce806 src/kwindowinfo_x11.cpp 041dfd3 src/kwindowsystem.h 0b58e71 src/kwindowsystem.cpp fb59603 src/kwindowsystem_p.h 8861844 src/kwindowsystem_p_x11.h 9baa6ae src/kwindowsystem_x11.cpp 2016820 src/netwm.h 2d812a7 src/netwm.cpp 1daad1e src/netwm_p.h a201cb6 Diff: https://git.reviewboard.kde.org/r/119267/diff/ Testing --- Yes, works with the new activity switcher. Thanks, Ivan Čukić ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119530: kcoreaddons: Fix kautosave doesn't work with more than 1 file per application
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119530/#review64231 --- Nice patch, I love the ton of unittests :) autotests/kautosavefiletest.cpp https://git.reviewboard.kde.org/r/119530/#comment44882 This isn't needed. init() is called before every test method. So need to call it once more at the very beginning (initTestCase). autotests/kautosavefiletest.cpp https://git.reviewboard.kde.org/r/119530/#comment44883 Coding style: please remove spaces within parentheses (use search/replace or run the astyle-kdelibs script after reading the howto in there). kdelibs4 was very inconsistent, but KF5 is very consistent. autotests/kautosavefiletest.cpp https://git.reviewboard.kde.org/r/119530/#comment44884 why no QVERIFY() here? autotests/kautosavefiletest.cpp https://git.reviewboard.kde.org/r/119530/#comment44885 same autotests/kautosavefiletest.cpp https://git.reviewboard.kde.org/r/119530/#comment44886 I think you can remove these two stubs, given all the tests you added :) src/lib/io/kautosavefile.h https://git.reviewboard.kde.org/r/119530/#comment44887 Well, it's less convenient for people who want a non-pointer member, for instance. Look at QFile: it has a QFile(QObject * parent) constructor, and a setFileName method to set the filename. Whatever one might think of the usefulness of that, I think it's good for KAutoSaveFile to be close to QFile. So I would suggest to remove these two lines. src/lib/io/kautosavefile.h https://git.reviewboard.kde.org/r/119530/#comment44888 How can you drop something you don't have? I'm a bit confused by the wording. src/lib/io/kautosavefile.h https://git.reviewboard.kde.org/r/119530/#comment44889 Ideally the two usage scenarios would be described in the class documentation, rather than only in the destructor. src/lib/io/kautosavefile.h https://git.reviewboard.kde.org/r/119530/#comment44891 (as above, I'm not sure about this todo) src/lib/io/kautosavefile.h https://git.reviewboard.kde.org/r/119530/#comment44892 Ah, but no... you cannot add new virtual methods, that's binary incompatible. Does it have to be virtual? Adding a non-virtual method is fine (add a @since 5.2 to its documentation). src/lib/io/kautosavefile.h https://git.reviewboard.kde.org/r/119530/#comment44893 If you want a method to be removed later (= KF6), you can already mark it as deprecated. But isn't allStaleFiles(app) nicer to read/write than staleFiles(QUrl(), app)? When reading such code, it's not clear why there's an empty url argument, while allStaleFiles is clear to the reader. Whether the method is useful, though, I don't know. In any case, let's decide: either keep, or deprecate. A @todo remove is kind of a half-baked decision which will never happen ;) src/lib/io/kautosavefile.cpp https://git.reviewboard.kde.org/r/119530/#comment44894 The usual naming for this (in all of Qt and KF5) is rather kautosavefile_p.h src/lib/io/kautosavefile.cpp https://git.reviewboard.kde.org/r/119530/#comment44902 Isn't the autosavefile location the same as this foo.kalock file's path but without the .kalock extension? Then I don't see much point in storing it inside the .kalock file again. src/lib/io/kautosavefile.cpp https://git.reviewboard.kde.org/r/119530/#comment44895 16? I think you mean 8. 2^3=8 and your table below has 8 lines, coincidentally ;) src/lib/io/kautosavefileprivate.h https://git.reviewboard.kde.org/r/119530/#comment44896 no need for if before delete, delete null is valid (and a no-op) src/lib/io/kautosavefileprivate.h https://git.reviewboard.kde.org/r/119530/#comment44897 Hihi, goodOpen, that's so French ;) src/lib/io/kautosavefileprivate.cpp https://git.reviewboard.kde.org/r/119530/#comment44899 coding style: no spaces within (...) and also no space before commas [this applies to the whole patch] src/lib/io/kautosavefileprivate.cpp https://git.reviewboard.kde.org/r/119530/#comment44898 if it's not open, no need to close it src/lib/io/kautosavefileprivate.cpp https://git.reviewboard.kde.org/r/119530/#comment44900 there's a fromLatin1(QByteArray) in Qt5 = you can and should remove the .constData() src/lib/io/kautosavefileprivate.cpp https://git.reviewboard.kde.org/r/119530/#comment44901 them - they - David Faure On July 29, 2014, 9:54 a.m., Andreas Xavier wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119530/ --- (Updated July 29, 2014, 9:54 a.m.) Review request for KDE Frameworks and David Faure. Repository: kcoreaddons Description
Re: Web Shortcuts KCM
On Wednesday 06 August 2014 08:58:07 Eike Hein wrote: On 08/04/2014 10:09 AM, David Faure wrote: So yep, that's not going away any time soon ;) Alright, so that leaves the licensing problem, right? Do I need to rewrite the KCM? Can I even? Do we contact Yves Arrouye for relicensing? I seem to have missed something. What's the licensing problem exactly? The fact that the KCM is GPL? But if it's launched via kcmshell5 that should be fine, no? Not sure about the case where it's dynamically loaded by the app process though. In any case you could ask the contributors for relicensing, before you spend a lot of time rewriting it (you can, but it's such a waste - and a risk for regressions / missing features) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Enabling Exceptions in CMake
On Mon, Aug 11, 2014 at 10:22 AM, David Narvaez david.narv...@computer.org wrote: On Sun, Aug 10, 2014 at 5:03 PM, Aleix Pol aleix...@kde.org wrote: From kde-modules/KDECompilerSettings.cmake # kde_enable_exceptions() # # Enables exceptions for C++ source files compiled for the # CMakeLists.txt file in the current directory and all subdirectories. See http://api.kde.org/ecm/kde-module/KDECompilerSettings.html I know that, I'll repeat my question: But I don't see exceptions mentioned in the ECM SIC page[0], should that documentation be there? i.e., is this considered an SIC? David E. Narvaez Ah sorry, I didn't follow through. Well, you can document it together with the funcion that enables exceptions at least. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Enabling Exceptions in CMake
On Mon, Aug 11, 2014 at 4:52 AM, Aleix Pol aleix...@kde.org wrote: Well, you can document it together with the funcion that enables exceptions at least. OK, documented at https://techbase.kde.org/index.php?title=Development/ECM_SourceIncompatChangesdiff=82951oldid=82898 David E. Narvaez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119681: Duplicate header guard from notifybylogfile.h in notifybyaudio.h
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119681/#review64244 --- Ship it! Awkward mistake :) Thanks! - Martin Klapetek On Aug. 9, 2014, 7:20 p.m., Andreas Xavier wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119681/ --- (Updated Aug. 9, 2014, 7:20 p.m.) Review request for KDE Frameworks and Martin Klapetek. Repository: knotifications Description --- Duplicate header guard from notifybylogfile.h in notifybyaudio.h Diffs - src/notifybyaudio.h 27cf4cb Diff: https://git.reviewboard.kde.org/r/119681/diff/ Testing --- I compiled. There are no unit tests. Thanks, Andreas Xavier ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119267: Adding KWindowSystem::setOnActivities(WId win, const QStringList activities) method
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119267/ --- (Updated Aug. 11, 2014, 9:47 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, kwin and Martin Gräßlin. Repository: kwindowsystem Description --- Currently, the library only has the method for retrieving a list of activities a window belongs to. This is adding a method which provides changing the list of activities for a window. Diffs - autotests/kwindowinfox11test.cpp 50ce806 src/kwindowinfo_x11.cpp 041dfd3 src/kwindowsystem.h 0b58e71 src/kwindowsystem.cpp fb59603 src/kwindowsystem_p.h 8861844 src/kwindowsystem_p_x11.h 9baa6ae src/kwindowsystem_x11.cpp 2016820 src/netwm.h 2d812a7 src/netwm.cpp 1daad1e src/netwm_p.h a201cb6 Diff: https://git.reviewboard.kde.org/r/119267/diff/ Testing --- Yes, works with the new activity switcher. Thanks, Ivan Čukić ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build became unstable: kwindowsystem_master_qt5 » All,LINBUILDER #88
See http://build.kde.org/job/kwindowsystem_master_qt5/Variation=All,label=LINBUILDER/88/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: For Book Sprint team: Frameworks Cookbook
Hello everyone, As Mirko mentioned, we think that the sections you will be writing for the book will be good subjects for defensive publications. Densive publications are like anti-patents. They are used to protect ideas and innovative hacks *against* subsequent patent filing. So with a little bit of extra work, you could kill two birds with one stone: your documentation will not only be useful for other developers and users, it can also be turned into something useful against software patents! If you are interested, feel free to drop in #linuxdefenders on freenode’s IRC servers. ↪ 2014-08-10 Sun 18:57, Mirko Boehm mi...@kde.org: Hugo is in CC in this email. Hugo, you might want to introduce your self and subscribe to the mailing list. [X] Done. I’m an attorney in training at the Paris Bar currently working with Linux Defenders for OIN. I have been involved with the Free Software Foundation Europe since 2009, including in its legal team¹ and I also lead the ToS;DR project² (“Terms of Service; Didn’t Read”). So I’ve been involved in free software for quite some time already, which should hopefully help me understand what your documentation describes and allow me to help and guide you on making it fit for a defensive publication! 1. https://fsfe.org/legal 2. https://tosdr.org I’m looking forward to working with you and hearing about new features ☺ Best regards, -- Hugo Roy LinuxDefenders.org pgpS7JbsIWtBa.pgp Description: PGP signature ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Snippetextractor comments in framework examples
Hi! El 11/08/2014 10:35, Rohan Garg ro...@kde.org escribió: Hi everyone As part of writing the KDE Frameworks 5 book, we were wondering if it's fine with all the framework maintainers if we started adding snippetextractor comments in the examples to be able to directly quote things in the book from the examples in the framework we're writing about. I don't mind (KCompletion). I didn't write them, so if the examples don't fit, please tell me and I'll modify them. Cheers, David Gil You can find a example of what these look like over here [1] Snippetextractor can be found on github here [2] Cheers Rohan Garg [1] http://quickgit.kde.org/?p=karchive.gita=commitdiffh=32e1b1c0027ca5ef582890f743cf7b708ef19523hp=6159717825bb87754787a5887f2d2d6cd2c621b1 [2] https://github.com/endocode/snippetextractor ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Breeze widget style for KF5
Hi all, For the last couple of weeks and after discussion with Nuno, Marco, Andrew and some others, I've worked on implementing most of the ideas from git://anongit.kde.org/breeze.git http://anongit.kde.org/breeze.git (more precisely from the QML demos at widgetstyles/qtquickcontrolsstyle) into a native widget style for KF5. Some screenshots below: dolphin: http://wstaw.org/m/2014/08/11/dolphin.png oxygen-demo: http://wstaw.org/m/2014/08/11/oxygen-demo.png http://wstaw.org/m/2014/08/11/oxygen-demo1.png http://wstaw.org/m/2014/08/11/oxygen-demo2.png Now this is of course not complete, but at least it is usable (I'm using it now). It naturally uses a lot of the code from oxygen, though for now I've preferred making a deep copy than actually sharing the code via libraries. Also it should be more efficient and have less 'issues' because it uses no pixmap caching but direct rendering to the widgets everywhere, mostly because said rendering is simpler than for oxygen. This should make it more easily dpi independent when this gets implemented inside Qt5. For the moment the code is in the following scratch repository: git://anongit.kde.org/scratch/hpereiradacosta/breeze Ultimately I'd like to - push this to some official repository (where should that be ? kde/workspace/breeze/kstyle ?) - make it the 'official' kf5 style (instead of the current QtCurve settings) - have feedback - iron out the remaining issues Among the things that are most notably missing are: a configuration ui (!) (though I foresee less things to be configurable than with oxygen) ... and then I'd like to: - make a gtk style - possibly make a kde4/qt4 style, - backport the improvement made to the code base (it is always good to revisit one's code) to oxygen@kf5 etc. Comments, objections, blessings, are welcome Best, Hugo ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Breeze widget style for KF5
On Monday 11 August 2014 12:29:05 Hugo Pereira Da Costa wrote: Hi all, For the last couple of weeks and after discussion with Nuno, Marco, Andrew and some others, I've worked on implementing most of the ideas from git://anongit.kde.org/breeze.git http://anongit.kde.org/breeze.git (more precisely from the QML demos at widgetstyles/qtquickcontrolsstyle) into a native widget style for KF5. Some screenshots below: dolphin: http://wstaw.org/m/2014/08/11/dolphin.png oxygen-demo: http://wstaw.org/m/2014/08/11/oxygen-demo.png http://wstaw.org/m/2014/08/11/oxygen-demo1.png http://wstaw.org/m/2014/08/11/oxygen-demo2.png Now this is of course not complete, but at least it is usable (I'm using it now). It naturally uses a lot of the code from oxygen, though for now I've preferred making a deep copy than actually sharing the code via libraries. Also it should be more efficient and have less 'issues' because it uses no pixmap caching but direct rendering to the widgets everywhere, mostly because said rendering is simpler than for oxygen. This should make it more easily dpi independent when this gets implemented inside Qt5. For the moment the code is in the following scratch repository: git://anongit.kde.org/scratch/hpereiradacosta/breeze Ultimately I'd like to - push this to some official repository (where should that be ? kde/workspace/breeze/kstyle ?) - make it the 'official' kf5 style (instead of the current QtCurve settings) - have feedback - iron out the remaining issues Among the things that are most notably missing are: a configuration ui (!) (though I foresee less things to be configurable than with oxygen) ... and then I'd like to: - make a gtk style - possibly make a kde4/qt4 style, - backport the improvement made to the code base (it is always good to revisit one's code) to oxygen@kf5 etc. Comments, objections, blessings, are welcome As someone with no clue: a) what's the advantage of having a native widget style, compared to using QtCurve settings? Are there things missing / not implementable in QtCurve? b) do you share the git history, i.e. did you do a proper fork, or did you reimport the sources and started from scratch (I hope not). Bye -- Milian Wolff m...@milianw.de http://milianw.de ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Breeze widget style for KF5
Hi Milian On Monday 11 August 2014 12:29:05 Hugo Pereira Da Costa wrote: Hi all, For the last couple of weeks and after discussion with Nuno, Marco, Andrew and some others, I've worked on implementing most of the ideas from git://anongit.kde.org/breeze.git http://anongit.kde.org/breeze.git (more precisely from the QML demos at widgetstyles/qtquickcontrolsstyle) into a native widget style for KF5. Some screenshots below: dolphin: http://wstaw.org/m/2014/08/11/dolphin.png oxygen-demo: http://wstaw.org/m/2014/08/11/oxygen-demo.png http://wstaw.org/m/2014/08/11/oxygen-demo1.png http://wstaw.org/m/2014/08/11/oxygen-demo2.png Now this is of course not complete, but at least it is usable (I'm using it now). It naturally uses a lot of the code from oxygen, though for now I've preferred making a deep copy than actually sharing the code via libraries. Also it should be more efficient and have less 'issues' because it uses no pixmap caching but direct rendering to the widgets everywhere, mostly because said rendering is simpler than for oxygen. This should make it more easily dpi independent when this gets implemented inside Qt5. For the moment the code is in the following scratch repository: git://anongit.kde.org/scratch/hpereiradacosta/breeze Ultimately I'd like to - push this to some official repository (where should that be ? kde/workspace/breeze/kstyle ?) - make it the 'official' kf5 style (instead of the current QtCurve settings) - have feedback - iron out the remaining issues Among the things that are most notably missing are: a configuration ui (!) (though I foresee less things to be configurable than with oxygen) ... and then I'd like to: - make a gtk style - possibly make a kde4/qt4 style, - backport the improvement made to the code base (it is always good to revisit one's code) to oxygen@kf5 etc. Comments, objections, blessings, are welcome As someone with no clue: a) what's the advantage of having a native widget style, compared to using QtCurve settings? None, except that you need someone working on qtcurve Are there things missing / not implementable in QtCurve? Everything is implemementable in QtCurve, though not via a simple text config file. So here also, you need someone to do it. b) do you share the git history, i.e. did you do a proper fork, or did you reimport the sources and started from scratch (I hope not). For breeze I reimported the needed parts of oxygen sources and started from scratch, mostly because a large fraction of the code from oxygen is overkill for Breeze's needs. Bye ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Breeze widget style for KF5
On Monday 11 of August 2014 13:05:19 Hugo Pereira Da Costa wrote: Hi Milian As someone with no clue: a) what's the advantage of having a native widget style, compared to using QtCurve settings? None, except that you need someone working on qtcurve Are there things missing / not implementable in QtCurve? Everything is implemementable in QtCurve, though not via a simple text config file. So here also, you need someone to do it. As someone else just watching: QtCurve is a KDE project now, shouldn't this help a bit? b) do you share the git history, i.e. did you do a proper fork, or did you reimport the sources and started from scratch (I hope not). For breeze I reimported the needed parts of oxygen sources and started from scratch, mostly because a large fraction of the code from oxygen is overkill for Breeze's needs. ... which does not mean that history (which could contain important hints about the code) should be nuked. Ciao -- Luigi ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Breeze widget style for KF5
On 08/11/2014 01:10 PM, Luigi Toscano wrote: On Monday 11 of August 2014 13:05:19 Hugo Pereira Da Costa wrote: Hi Milian As someone with no clue: a) what's the advantage of having a native widget style, compared to using QtCurve settings? None, except that you need someone working on qtcurve Are there things missing / not implementable in QtCurve? Everything is implemementable in QtCurve, though not via a simple text config file. So here also, you need someone to do it. As someone else just watching: QtCurve is a KDE project now, shouldn't this help a bit? ... not my take. I am not volunteering (for lack of time and code knowledge) to work on QtCurve code base. Nor did it come in the discussions when I volunteered on starting with a breeze widget style 'from scratch', based on the code I knew best. b) do you share the git history, i.e. did you do a proper fork, or did you reimport the sources and started from scratch (I hope not). For breeze I reimported the needed parts of oxygen sources and started from scratch, mostly because a large fraction of the code from oxygen is overkill for Breeze's needs. ... which does not mean that history (which could contain important hints about the code) should be nuked. No history got nuked. Oxygen's history is still there (in oxygen's repository), and will stay there, with all relevant hints. The Breeze style I worked on is a new project, for which I imported some code from elsewhere (here oxygen). Ciao ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Breeze widget style for KF5
On Monday 11 August 2014 13:10:39 Luigi Toscano wrote: On Monday 11 of August 2014 13:05:19 Hugo Pereira Da Costa wrote: Hi Milian As someone with no clue: a) what's the advantage of having a native widget style, compared to using QtCurve settings? None, except that you need someone working on qtcurve Are there things missing / not implementable in QtCurve? Everything is implemementable in QtCurve, though not via a simple text config file. So here also, you need someone to do it. As someone else just watching: QtCurve is a KDE project now, shouldn't this help a bit? hey guys, I find this a rather strange topic for discussion. We are very happy that Hugo stepped up to write a native style. Questioning why he didn't use QtCurve seems absurd to me. Cheers Martin 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: Breeze widget style for KF5
On Monday 11 of August 2014 14:08:35 Martin Gräßlin wrote: On Monday 11 August 2014 13:10:39 Luigi Toscano wrote: On Monday 11 of August 2014 13:05:19 Hugo Pereira Da Costa wrote: Hi Milian As someone with no clue: a) what's the advantage of having a native widget style, compared to using QtCurve settings? None, except that you need someone working on qtcurve Are there things missing / not implementable in QtCurve? Everything is implemementable in QtCurve, though not via a simple text config file. So here also, you need someone to do it. As someone else just watching: QtCurve is a KDE project now, shouldn't this help a bit? hey guys, I find this a rather strange topic for discussion. We are very happy that Hugo stepped up to write a native style. Questioning why he didn't use QtCurve seems absurd to me. I find this answer a bit overracting. I didn't do questioning police-style; I asked. End of story. If you don't expect question, don't put Comments, objections, blessings, are welcome at the end. Ciao -- Luigi ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119711: Use CMAKE_INSTALL_FULL_LIBEXECDIR_KF5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119711/ --- (Updated Aug. 11, 2014, 12:30 p.m.) Review request for KDE Frameworks and David Faure. Repository: kinit Description --- Resolves the problem of passing relative vs. absolute KF5_LIBEXEC_INSTALL_DIR/LIBEXEC_INSTALL_DIR. Diffs - src/klauncher/klauncher.cpp 124011e src/start_kdeinit/CMakeLists.txt 56a91e3 src/start_kdeinit/start_kdeinit.c 02d4d54 src/start_kdeinit/start_kdeinit_wrapper.c f35c4a9 src/config-kdeinit.h.cmake 76cd867 src/kdeinit/CMakeLists.txt 8a84774 src/kdeinit/kinit.cpp 296ebfd src/klauncher/CMakeLists.txt 8a251ff Diff: https://git.reviewboard.kde.org/r/119711/diff/ Testing --- Before it searches for /usr//usr/libexec and after all is fine. Thanks, Nicolas Lécureuil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119698: Save radio button index in QGroupBox that are composed only by radio buttons
On ago. 10, 2014, 9:01 p.m., Aleix Pol Gonzalez wrote: src/kconfigdialogmanager.cpp, line 61 https://git.reviewboard.kde.org/r/119698/diff/1/?file=303639#file303639line61 It could be a QSetQGroupBox*, you're already doing the cast and checking it's not null anyway. It could be, but in other places i use the set, i have a QWidget* at hand and not a QGroupBox*, which would mean having to add a few more dynamic_casts for nothing. So i'd prefer not to do it. On ago. 10, 2014, 9:01 p.m., Aleix Pol Gonzalez wrote: src/kconfigdialogmanager.cpp, line 227 https://git.reviewboard.kde.org/r/119698/diff/1/?file=303639#file303639line227 You probably want to remove the widget if the widget is deleted, even though you're not accessing through them. kconfigdialogmanager is a more static thing, i don't think people is adding and removing widgets from the configuration dialog on runtime, so adding extra code to remove the group box from the set when the groupbox is deleted seems like extra work that won't really give us any benefit. On ago. 10, 2014, 9:01 p.m., Albert Astals Cid wrote: And maybe you can use the more generic type QAbstractButton, only maybe, I'm unsure, up to you. I'll go QAbstractButton - Albert --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119698/#review64202 --- On ago. 10, 2014, 8:28 p.m., Albert Astals Cid wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119698/ --- (Updated ago. 10, 2014, 8:28 p.m.) Review request for KDE Frameworks. Repository: kconfigwidgets Description --- We are suggesting people to port from deprecated KButtonGroup to QGroupBox but the dialog manager does not behave the same. This patch fixes it by assuming that in a groupbox that is composed exclusively by radio buttons and whose config item is an int to save the index of the checked radio button instead of if the group box itself is checked. Diffs - src/kconfigdialogmanager.cpp 94d3cd1 Diff: https://git.reviewboard.kde.org/r/119698/diff/ Testing --- KGeography frameworks with KButtonGroup ported to QGroupBox works. Thanks, Albert Astals Cid ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119698: Save radio button index in QGroupBox that are composed only by radio buttons
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119698/ --- (Updated ago. 11, 2014, 12:39 p.m.) Review request for KDE Frameworks. Repository: kconfigwidgets Description --- We are suggesting people to port from deprecated KButtonGroup to QGroupBox but the dialog manager does not behave the same. This patch fixes it by assuming that in a groupbox that is composed exclusively by radio buttons and whose config item is an int to save the index of the checked radio button instead of if the group box itself is checked. Diffs (updated) - src/kconfigdialogmanager.cpp 94d3cd1 Diff: https://git.reviewboard.kde.org/r/119698/diff/ Testing --- KGeography frameworks with KButtonGroup ported to QGroupBox works. Thanks, Albert Astals Cid ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119698: Save radio button index in QGroupBox that are composed only by radio buttons
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119698/ --- (Updated ago. 11, 2014, 12:40 p.m.) Review request for KDE Frameworks. Repository: kconfigwidgets Description --- We are suggesting people to port from deprecated KButtonGroup to QGroupBox but the dialog manager does not behave the same. This patch fixes it by assuming that in a groupbox that is composed exclusively by radio buttons and whose config item is an int to save the index of the checked radio button instead of if the group box itself is checked. Diffs (updated) - src/kconfigdialogmanager.cpp 94d3cd1 Diff: https://git.reviewboard.kde.org/r/119698/diff/ Testing --- KGeography frameworks with KButtonGroup ported to QGroupBox works. Thanks, Albert Astals Cid ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119711: Use CMAKE_INSTALL_FULL_LIBEXECDIR_KF5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119711/#review64260 --- I'm getting this error: chown: cannot access „/usr//usr/lib64/libexec/kf5/start_kdeinit“: Directory or file doesn't exist - Lukáš Tinkl On Srp. 11, 2014, 2:30 odp., Nicolas Lécureuil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119711/ --- (Updated Srp. 11, 2014, 2:30 odp.) Review request for KDE Frameworks and David Faure. Repository: kinit Description --- Resolves the problem of passing relative vs. absolute KF5_LIBEXEC_INSTALL_DIR/LIBEXEC_INSTALL_DIR. Diffs - src/klauncher/klauncher.cpp 124011e src/start_kdeinit/CMakeLists.txt 56a91e3 src/start_kdeinit/start_kdeinit.c 02d4d54 src/start_kdeinit/start_kdeinit_wrapper.c f35c4a9 src/config-kdeinit.h.cmake 76cd867 src/kdeinit/CMakeLists.txt 8a84774 src/kdeinit/kinit.cpp 296ebfd src/klauncher/CMakeLists.txt 8a251ff Diff: https://git.reviewboard.kde.org/r/119711/diff/ Testing --- Before it searches for /usr//usr/libexec and after all is fine. Thanks, Nicolas Lécureuil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 119714: Fix the build on Windows using MSVC 2013
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119714/ --- Review request for KDE Frameworks, Christoph Cullmann and Joseph Wenninger. Repository: ktexteditor Description --- The compiler was complaining about ambiguous method resolution using QAbstractItemModel::createIndex (because of the last parameter) so just remove it since QAbstractItemModel::createIndex has a default value for the last parameter in one of the overloads which is just what it's needed. Diffs - src/completion/katekeywordcompletion.cpp e30a64d7de3be0f6470303024b0fd0fc034a12dd Diff: https://git.reviewboard.kde.org/r/119714/diff/ Testing --- Built and run kate. Thanks, Cristian Oneț ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 119713: Don't use hicolor if we have breeze or oxygen are available
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119713/ --- Review request for KDE Frameworks. Repository: kconfigwidgets Description --- I am running KGeography in a user which has oxygen icons available but since i'm not running neither the kde QPT nor oxygen style nor anything, while moving from KIcon to QIcon::fromTheme i lost most of my icons (since there is no kiconloader in the middle anymore), and the same for kstandardaction icons. This patch makes it so that if you are using kstandardactions and your icon theme is hicolor but you have breeze or oxygen installed it changes the theme to one of those. I am unconvinced if we want this here or if i want this in my (and potentially) every application so when we run in Gnome or Unity, our apps get icons what were getting in kde4 times because they were using KIcon and they would lose now because of the QIcon::fromTheme recommendation. Diffs - src/kstandardaction.cpp a18527b Diff: https://git.reviewboard.kde.org/r/119713/diff/ Testing --- KGeography menu items have icons again. Thanks, Albert Astals Cid ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119714: Fix the build on Windows using MSVC 2013
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119714/#review64262
---
Ship it!
This should be save, default paramater is 0 anyways and internally in cute, the
result is the same. It should not make a difference which overload is used.
inline QModelIndex(int arow, int acolumn, void *ptr, const QAbstractItemModel
*amodel)
: r(arow), c(acolumn), i(reinterpret_castquintptr(ptr)), m(amodel) {}
Q_DECL_CONSTEXPR inline QModelIndex(int arow, int acolumn, quintptr id,
const QAbstractItemModel *amode$
: r(arow), c(acolumn), i(id), m(amodel) {}
- Joseph Wenninger
On Aug. 11, 2014, 1:24 nachm., Cristian Oneț wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119714/
---
(Updated Aug. 11, 2014, 1:24 nachm.)
Review request for KDE Frameworks, Christoph Cullmann and Joseph Wenninger.
Repository: ktexteditor
Description
---
The compiler was complaining about ambiguous method resolution using
QAbstractItemModel::createIndex (because of the last parameter) so just
remove it since QAbstractItemModel::createIndex has a default value
for the last parameter in one of the overloads which is just what it's
needed.
Diffs
-
src/completion/katekeywordcompletion.cpp
e30a64d7de3be0f6470303024b0fd0fc034a12dd
Diff: https://git.reviewboard.kde.org/r/119714/diff/
Testing
---
Built and run kate.
Thanks,
Cristian Oneț
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119698: Save radio button index in QGroupBox that are composed only by radio buttons
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119698/#review64263 --- Ship it! Makes sense to me. - Aleix Pol Gonzalez On Aug. 11, 2014, 12:40 p.m., Albert Astals Cid wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119698/ --- (Updated Aug. 11, 2014, 12:40 p.m.) Review request for KDE Frameworks. Repository: kconfigwidgets Description --- We are suggesting people to port from deprecated KButtonGroup to QGroupBox but the dialog manager does not behave the same. This patch fixes it by assuming that in a groupbox that is composed exclusively by radio buttons and whose config item is an int to save the index of the checked radio button instead of if the group box itself is checked. Diffs - src/kconfigdialogmanager.cpp 94d3cd1 Diff: https://git.reviewboard.kde.org/r/119698/diff/ Testing --- KGeography frameworks with KButtonGroup ported to QGroupBox works. Thanks, Albert Astals Cid ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119713: Don't use hicolor if we have breeze or oxygen are available
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119713/#review64264 --- src/kstandardaction.cpp https://git.reviewboard.kde.org/r/119713/#comment44914 Wouldn't it be better to use something like this? QIcon::setThemeSearchPaths(QIcon::themeSearchPaths()+thePathFor(breeze)); - Aleix Pol Gonzalez On Aug. 11, 2014, 1:24 p.m., Albert Astals Cid wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119713/ --- (Updated Aug. 11, 2014, 1:24 p.m.) Review request for KDE Frameworks. Repository: kconfigwidgets Description --- I am running KGeography in a user which has oxygen icons available but since i'm not running neither the kde QPT nor oxygen style nor anything, while moving from KIcon to QIcon::fromTheme i lost most of my icons (since there is no kiconloader in the middle anymore), and the same for kstandardaction icons. This patch makes it so that if you are using kstandardactions and your icon theme is hicolor but you have breeze or oxygen installed it changes the theme to one of those. I am unconvinced if we want this here or if i want this in my (and potentially) every application so when we run in Gnome or Unity, our apps get icons what were getting in kde4 times because they were using KIcon and they would lose now because of the QIcon::fromTheme recommendation. Diffs - src/kstandardaction.cpp a18527b Diff: https://git.reviewboard.kde.org/r/119713/diff/ Testing --- KGeography menu items have icons again. Thanks, Albert Astals Cid ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119711: Use CMAKE_INSTALL_FULL_LIBEXECDIR_KF5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119711/#review64266 --- +1 from me, I'd wait for dfaure for the final ship it tho :) - Lukáš Tinkl On Srp. 11, 2014, 4:22 odp., Nicolas Lécureuil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119711/ --- (Updated Srp. 11, 2014, 4:22 odp.) Review request for KDE Frameworks and David Faure. Repository: kinit Description --- Resolves the problem of passing relative vs. absolute KF5_LIBEXEC_INSTALL_DIR/LIBEXEC_INSTALL_DIR. Diffs - src/config-kdeinit.h.cmake 76cd867 src/kdeinit/CMakeLists.txt 8a84774 src/kdeinit/kinit.cpp 296ebfd src/klauncher/CMakeLists.txt 8a251ff src/klauncher/klauncher.cpp 124011e src/start_kdeinit/CMakeLists.txt 56a91e3 src/start_kdeinit/start_kdeinit.c 02d4d54 src/start_kdeinit/start_kdeinit_wrapper.c f35c4a9 Diff: https://git.reviewboard.kde.org/r/119711/diff/ Testing --- Before it searches for /usr//usr/libexec and after all is fine. Thanks, Nicolas Lécureuil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119711: Use CMAKE_INSTALL_FULL_LIBEXECDIR_KF5
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119711/
---
(Updated Aug. 11, 2014, 2:22 p.m.)
Review request for KDE Frameworks and David Faure.
Changes
---
Update patch fixing usage of ${CMAKE_INSTALL_PREFIX} ( thanks to ltinkl ).
Repository: kinit
Description
---
Resolves the problem of passing relative vs. absolute
KF5_LIBEXEC_INSTALL_DIR/LIBEXEC_INSTALL_DIR.
Diffs (updated)
-
src/config-kdeinit.h.cmake 76cd867
src/kdeinit/CMakeLists.txt 8a84774
src/kdeinit/kinit.cpp 296ebfd
src/klauncher/CMakeLists.txt 8a251ff
src/klauncher/klauncher.cpp 124011e
src/start_kdeinit/CMakeLists.txt 56a91e3
src/start_kdeinit/start_kdeinit.c 02d4d54
src/start_kdeinit/start_kdeinit_wrapper.c f35c4a9
Diff: https://git.reviewboard.kde.org/r/119711/diff/
Testing
---
Before it searches for /usr//usr/libexec and after all is fine.
Thanks,
Nicolas Lécureuil
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119711: Use CMAKE_INSTALL_FULL_LIBEXECDIR_KF5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119711/#review64267 --- src/kdeinit/kinit.cpp https://git.reviewboard.kde.org/r/119711/#comment44918 This can't work, it's replacing a full path with a relative path. The goal of this code was s/libexec/lib/ AFAICS, just like the next block does s/bin/lib/ (and then they append the filename). - David Faure On Aug. 11, 2014, 2:22 p.m., Nicolas Lécureuil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119711/ --- (Updated Aug. 11, 2014, 2:22 p.m.) Review request for KDE Frameworks and David Faure. Repository: kinit Description --- Resolves the problem of passing relative vs. absolute KF5_LIBEXEC_INSTALL_DIR/LIBEXEC_INSTALL_DIR. Diffs - src/config-kdeinit.h.cmake 76cd867 src/kdeinit/CMakeLists.txt 8a84774 src/kdeinit/kinit.cpp 296ebfd src/klauncher/CMakeLists.txt 8a251ff src/klauncher/klauncher.cpp 124011e src/start_kdeinit/CMakeLists.txt 56a91e3 src/start_kdeinit/start_kdeinit.c 02d4d54 src/start_kdeinit/start_kdeinit_wrapper.c f35c4a9 Diff: https://git.reviewboard.kde.org/r/119711/diff/ Testing --- Before it searches for /usr//usr/libexec and after all is fine. Thanks, Nicolas Lécureuil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119711: Use CMAKE_INSTALL_FULL_LIBEXECDIR_KF5
On Aug. 11, 2014, 2:47 p.m., David Faure wrote: src/kdeinit/kinit.cpp, line 503 https://git.reviewboard.kde.org/r/119711/diff/2/?file=303743#file303743line503 This can't work, it's replacing a full path with a relative path. The goal of this code was s/libexec/lib/ AFAICS, just like the next block does s/bin/lib/ (and then they append the filename). you are right, i reverted this part. - Nicolas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119711/#review64267 --- On Aug. 11, 2014, 2:54 p.m., Nicolas Lécureuil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119711/ --- (Updated Aug. 11, 2014, 2:54 p.m.) Review request for KDE Frameworks and David Faure. Repository: kinit Description --- Resolves the problem of passing relative vs. absolute KF5_LIBEXEC_INSTALL_DIR/LIBEXEC_INSTALL_DIR. Diffs - src/start_kdeinit/CMakeLists.txt 56a91e3 src/start_kdeinit/start_kdeinit.c 02d4d54 src/start_kdeinit/start_kdeinit_wrapper.c f35c4a9 src/config-kdeinit.h.cmake 76cd867 src/kdeinit/CMakeLists.txt 8a84774 src/kdeinit/kinit.cpp 296ebfd src/klauncher/CMakeLists.txt 8a251ff src/klauncher/klauncher.cpp 124011e Diff: https://git.reviewboard.kde.org/r/119711/diff/ Testing --- Before it searches for /usr//usr/libexec and after all is fine. Thanks, Nicolas Lécureuil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119711: Use CMAKE_INSTALL_FULL_LIBEXECDIR_KF5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119711/ --- (Updated Aug. 11, 2014, 2:54 p.m.) Review request for KDE Frameworks and David Faure. Repository: kinit Description --- Resolves the problem of passing relative vs. absolute KF5_LIBEXEC_INSTALL_DIR/LIBEXEC_INSTALL_DIR. Diffs (updated) - src/start_kdeinit/CMakeLists.txt 56a91e3 src/start_kdeinit/start_kdeinit.c 02d4d54 src/start_kdeinit/start_kdeinit_wrapper.c f35c4a9 src/config-kdeinit.h.cmake 76cd867 src/kdeinit/CMakeLists.txt 8a84774 src/kdeinit/kinit.cpp 296ebfd src/klauncher/CMakeLists.txt 8a251ff src/klauncher/klauncher.cpp 124011e Diff: https://git.reviewboard.kde.org/r/119711/diff/ Testing --- Before it searches for /usr//usr/libexec and after all is fine. Thanks, Nicolas Lécureuil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119714: Fix the build on Windows using MSVC 2013
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119714/#review64270 --- Ship it! Ship It! - Milian Wolff On Aug. 11, 2014, 1:24 p.m., Cristian Oneț wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119714/ --- (Updated Aug. 11, 2014, 1:24 p.m.) Review request for KDE Frameworks, Christoph Cullmann and Joseph Wenninger. Repository: ktexteditor Description --- The compiler was complaining about ambiguous method resolution using QAbstractItemModel::createIndex (because of the last parameter) so just remove it since QAbstractItemModel::createIndex has a default value for the last parameter in one of the overloads which is just what it's needed. Diffs - src/completion/katekeywordcompletion.cpp e30a64d7de3be0f6470303024b0fd0fc034a12dd Diff: https://git.reviewboard.kde.org/r/119714/diff/ Testing --- Built and run kate. Thanks, Cristian Oneț ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119713: Don't use hicolor if we have breeze or oxygen are available
On ago. 11, 2014, 1:54 p.m., Aleix Pol Gonzalez wrote: src/kstandardaction.cpp, line 48 https://git.reviewboard.kde.org/r/119713/diff/1/?file=303736#file303736line48 Wouldn't it be better to use something like this? QIcon::setThemeSearchPaths(QIcon::themeSearchPaths()+thePathFor(breeze)); Icon::themeSearchPaths() contains (/home/kdeunstable/instalado/share/icons, /usr/share/icons, :/icons) which actually already contains the breeze and oxygen folders, it's just that unconfigured Qt5 defauls to hicolor which means you get no icon at all. I also undestand that forcing icons this way it's weird, not really convinced this is the way to go. - Albert --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119713/#review64264 --- On ago. 11, 2014, 1:24 p.m., Albert Astals Cid wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119713/ --- (Updated ago. 11, 2014, 1:24 p.m.) Review request for KDE Frameworks. Repository: kconfigwidgets Description --- I am running KGeography in a user which has oxygen icons available but since i'm not running neither the kde QPT nor oxygen style nor anything, while moving from KIcon to QIcon::fromTheme i lost most of my icons (since there is no kiconloader in the middle anymore), and the same for kstandardaction icons. This patch makes it so that if you are using kstandardactions and your icon theme is hicolor but you have breeze or oxygen installed it changes the theme to one of those. I am unconvinced if we want this here or if i want this in my (and potentially) every application so when we run in Gnome or Unity, our apps get icons what were getting in kde4 times because they were using KIcon and they would lose now because of the QIcon::fromTheme recommendation. Diffs - src/kstandardaction.cpp a18527b Diff: https://git.reviewboard.kde.org/r/119713/diff/ Testing --- KGeography menu items have icons again. Thanks, Albert Astals Cid ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119714: Fix the build on Windows using MSVC 2013
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119714/ --- (Updated Aug. 11, 2014, 3:46 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, Christoph Cullmann and Joseph Wenninger. Repository: ktexteditor Description --- The compiler was complaining about ambiguous method resolution using QAbstractItemModel::createIndex (because of the last parameter) so just remove it since QAbstractItemModel::createIndex has a default value for the last parameter in one of the overloads which is just what it's needed. Diffs - src/completion/katekeywordcompletion.cpp e30a64d7de3be0f6470303024b0fd0fc034a12dd Diff: https://git.reviewboard.kde.org/r/119714/diff/ Testing --- Built and run kate. Thanks, Cristian Oneț ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Build failed in Jenkins: plasma-framework_master_qt5 » NoX11,LINBUILDER #683
See http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/683/changes Changes: [notmart] use open in [notmart] add file definition for colors -- [...truncated 251 lines...] Generating datamodel.moc http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/ws/src/declarativeimports/core/datamodel.cpp:0: Note: No relevant classes found. No output generated. Generating moc_framesvgtest.cpp Note: Writing plasmapkg2.1 Generating moc_coronatest.cpp [ 11%] [ 11%] Built target framesvgtest_automoc Built target coronatest_automoc Scanning dependencies of target packageurlinterceptortest_automoc [ 12%] [ 12%] Scanning dependencies of target pluginloadertest_automoc Built target -srv-jenkins-workspace-plasma-framework-master-qt5-Variation-NoX11-label-LINBUILDER-build-docs-plasmapkg-plasmapkg2-1 [ 13%] Automatic moc for target pluginloadertest Automatic moc for target packageurlinterceptortest Scanning dependencies of target sortfiltermodeltest_automoc Generating moc_packageurlinterceptortest.cpp Generating moc_pluginloadertest.cpp Generating moc_packagestructuretest.cpp [ 13%] [ 13%] [ 14%] [ 14%] Built target packageurlinterceptortest_automoc Built target packagestructuretest_automoc Built target pluginloadertest_automoc Automatic moc for target sortfiltermodeltest Scanning dependencies of target storagetest_automoc Generating datasource.moc http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/ws/src/declarativeimports/core/datasource.cpp:0: Note: No relevant classes found. No output generated. Scanning dependencies of target plugintest_automoc Scanning dependencies of target dpitest_automoc [ 16%] [ 16%] Automatic moc for target storagetest Automatic moc for target plugintest [ 17%] Automatic moc for target dpitest Generating moc_qmenu.cpp Generating moc_qmenuitem.cpp Generating moc_qrangemodel.cpp [ 17%] Built target plasmacomponentsplugin_automoc Scanning dependencies of target plasma_engine_testengine_automoc Generating moc_dpitest.cpp [ 18%] [ 18%] Built target dpitest_automoc Generating plasma-dataengine-testengine.json Generating moc_plugintest.cpp [ 18%] Built target plugintest_automoc Generated http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/ws/build/tests/testengine/plasma-dataengine-testengine.json [ 19%] Generating framesvgitem.moc http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/ws/src/declarativeimports/core/framesvgitem.cpp:0: Note: No relevant classes found. No output generated. Generating sortfiltermodeltest.moc http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/ws/autotests/sortfiltermodeltest.cpp:0: Note: No relevant classes found. No output generated. Automatic moc for target plasma_engine_testengine Scanning dependencies of target platformcomponentsplugin Scanning dependencies of target calendarplugin [ 19%] Building CXX object src/declarativeimports/platformcomponents/CMakeFiles/platformcomponentsplugin.dir/platformextensionplugin.cpp.o [ 20%] Building CXX object src/declarativeimports/calendar/CMakeFiles/calendarplugin.dir/calendarplugin.cpp.o Generating moc_storage_p.cpp Generating moc_storagethread_p.cpp Generating moc_storagetest.cpp Generating datamodel.moc http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/ws/src/declarativeimports/core/datamodel.cpp:0: Note: No relevant classes found. No output generated. Generating testengine.moc http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/ws/tests/testengine/testengine.cpp:171: Warning: Plugin Metadata file plasma-dataengine-testengine.desktop does not contain a valid JSON object. Declaration will be ignored [ 20%] Built target storagetest_automoc Generating iconitem.moc http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/ws/src/declarativeimports/core/iconitem.cpp:0: Note: No relevant classes found. No output generated. [ 21%] Generating platformstatusadaptor.cpp, platformstatusadaptor.h [ 21%] Generating platformstatusadaptor.moc Generating moc_testengine.cpp [ 21%] Generating moc_appletinterface.cpp Generating moc_containmentinterface.cpp Generating declarativeappletscript.moc Generating moc_wallpaperinterface.cpp Generating moc_declarativeappletscript.cpp Built target plasma_engine_testengine_automoc [ 22%] [ 22%] Built target plasma_appletscript_declarative_automoc [ 22%] Building CXX object src/declarativeimports/calendar/CMakeFiles/calendarplugin.dir/calendar.cpp.o Building CXX object src/declarativeimports/platformcomponents/CMakeFiles/platformcomponentsplugin.dir/application.cpp.o Generating moc_appletquickitem.cpp Generating moc_configmodel.cpp Generating moc_configview.cpp Generating moc_dialog.cpp Generating moc_dialogshadows_p.cpp Generating
Build failed in Jenkins: plasma-framework_master_qt5 » All,LINBUILDER #683
See http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/683/changes Changes: [notmart] use open in [notmart] add file definition for colors -- [...truncated 255 lines...] Built target coronatest_automoc Scanning dependencies of target packageurlinterceptortest_automoc Scanning dependencies of target pluginloadertest_automoc Generating moc_colorscope.cpp Generating corebindingsplugin.moc http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/ws/src/declarativeimports/core/corebindingsplugin.cpp:0: Note: No relevant classes found. No output generated. [ 12%] [ 12%] Automatic moc for target packageurlinterceptortest Automatic moc for target pluginloadertest Generating moc_packagestructuretest.cpp [ 12%] Built target packagestructuretest_automoc Scanning dependencies of target sortfiltermodeltest_automoc [ 13%] Automatic moc for target sortfiltermodeltest Generating moc_pluginloadertest.cpp Generating moc_packageurlinterceptortest.cpp [ 13%] Built target pluginloadertest_automoc [ 13%] Built target packageurlinterceptortest_automoc Scanning dependencies of target storagetest_automoc [ 14%] Automatic moc for target storagetest Scanning dependencies of target plugintest_automoc [ 15%] Automatic moc for target plugintest Generating moc_qmenu.cpp Generating moc_qmenuitem.cpp Generating moc_qrangemodel.cpp [ 15%] Built target plasmacomponentsplugin_automoc Scanning dependencies of target dpitest_automoc [ 16%] Automatic moc for target dpitest Generating datamodel.moc http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/ws/src/declarativeimports/core/datamodel.cpp:0: Note: No relevant classes found. No output generated. Generating moc_plugintest.cpp Note: Writing plasmapkg2.1 [ 16%] Built target plugintest_automoc Generating sortfiltermodeltest.moc http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/ws/autotests/sortfiltermodeltest.cpp:0: Note: No relevant classes found. No output generated. Generating moc_dpitest.cpp Scanning dependencies of target plasma_engine_testengine_automoc [ 16%] [ 16%] [ 17%] Built target dpitest_automoc Built target -srv-jenkins-workspace-plasma-framework-master-qt5-Variation-All-label-LINBUILDER-build-docs-plasmapkg-plasmapkg2-1 Generating plasma-dataengine-testengine.json Generated http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/ws/build/tests/testengine/plasma-dataengine-testengine.json [ 18%] Automatic moc for target plasma_engine_testengine Scanning dependencies of target calendarplugin Scanning dependencies of target platformcomponentsplugin [ 19%] Building CXX object src/declarativeimports/calendar/CMakeFiles/calendarplugin.dir/calendarplugin.cpp.o [ 19%] Generating datasource.moc http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/ws/src/declarativeimports/core/datasource.cpp:0: Note: No relevant classes found. No output generated. Building CXX object src/declarativeimports/platformcomponents/CMakeFiles/platformcomponentsplugin.dir/platformextensionplugin.cpp.o Generating moc_storage_p.cpp Generating moc_storagethread_p.cpp Generating moc_storagetest.cpp [ 19%] Built target storagetest_automoc [ 20%] Building CXX object src/declarativeimports/platformcomponents/CMakeFiles/platformcomponentsplugin.dir/application.cpp.o Generating datamodel.moc http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/ws/src/declarativeimports/core/datamodel.cpp:0: Note: No relevant classes found. No output generated. Generating testengine.moc http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/ws/tests/testengine/testengine.cpp:171: Warning: Plugin Metadata file plasma-dataengine-testengine.desktop does not contain a valid JSON object. Declaration will be ignored Generating moc_testengine.cpp [ 20%] Built target plasma_engine_testengine_automoc Generating framesvgitem.moc http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/ws/src/declarativeimports/core/framesvgitem.cpp:0: Note: No relevant classes found. No output generated. [ 21%] Building CXX object src/declarativeimports/calendar/CMakeFiles/calendarplugin.dir/calendar.cpp.o Generating datasource.moc http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/ws/src/declarativeimports/core/datasource.cpp:0: Note: No relevant classes found. No output generated. Generating moc_appletinterface.cpp Generating moc_containmentinterface.cpp Generating declarativeappletscript.moc Generating moc_wallpaperinterface.cpp Generating moc_declarativeappletscript.cpp [ 21%] Built target plasma_appletscript_declarative_automoc [ 21%] Building CXX object src/declarativeimports/calendar/CMakeFiles/calendarplugin.dir/calendardata.cpp.o Generating iconitem.moc
Jenkins build is back to normal : plasma-framework_master_qt5 » NoX11,LINBUILDER #684
See http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/684/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is back to normal : plasma-framework_master_qt5 » All,LINBUILDER #684
See http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/684/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119713: Don't use hicolor if we have breeze or oxygen are available
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119713/ --- (Updated ago. 11, 2014, 4:15 p.m.) Review request for KDE Frameworks. Repository: kconfigwidgets Description (updated) --- I am running KGeography in a user which has oxygen icons available but since i'm not running neither the kde QPT nor oxygen style nor anything, while moving from KIcon to QIcon::fromTheme i lost most of my icons (since there is no kiconloader in the middle anymore), and the same for kstandardaction icons. This patch makes it so that if you are using kstandardactions and your icon theme is hicolor but you have breeze or oxygen installed it changes the theme to one of those. I am unconvinced if we want this here or if i want this in my (and potentially) every application so when we run in Gnome or Unity, our apps get icons what were getting in kde4 times because they were using KIcon and they would lose now because of the QIcon::fromTheme recommendation. Obviously the missing icons also get fixed by QT_QPA_PLATFORMTHEME=kde but one can not expect to have this define when on non Plasma desktops and since in the past KIcon gave you oxygen-icons even if you were not on plasma i think it makes sense to do this. Diffs - src/kstandardaction.cpp a18527b Diff: https://git.reviewboard.kde.org/r/119713/diff/ Testing --- KGeography menu items have icons again. Thanks, Albert Astals Cid ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119713: Don't use hicolor if we have breeze or oxygen are available
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119713/ --- (Updated ago. 11, 2014, 4:47 p.m.) Review request for KDE Frameworks. Repository: kconfigwidgets Description --- I am running KGeography in a user which has oxygen icons available but since i'm not running neither the kde QPT nor oxygen style nor anything, while moving from KIcon to QIcon::fromTheme i lost most of my icons (since there is no kiconloader in the middle anymore), and the same for kstandardaction icons. This patch makes it so that if you are using kstandardactions and your icon theme is hicolor but you have breeze or oxygen installed it changes the theme to one of those. I am unconvinced if we want this here or if i want this in my (and potentially) every application so when we run in Gnome or Unity, our apps get icons what were getting in kde4 times because they were using KIcon and they would lose now because of the QIcon::fromTheme recommendation. Obviously the missing icons also get fixed by QT_QPA_PLATFORMTHEME=kde but one can not expect to have this define when on non Plasma desktops and since in the past KIcon gave you oxygen-icons even if you were not on plasma i think it makes sense to do this. Diffs (updated) - src/kstandardaction.cpp a18527b Diff: https://git.reviewboard.kde.org/r/119713/diff/ Testing --- KGeography menu items have icons again. Thanks, Albert Astals Cid ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119713: Don't use hicolor if we have breeze or oxygen are available
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119713/ --- (Updated ago. 11, 2014, 4:47 p.m.) Review request for KDE Frameworks. Repository: kconfigwidgets Description --- I am running KGeography in a user which has oxygen icons available but since i'm not running neither the kde QPT nor oxygen style nor anything, while moving from KIcon to QIcon::fromTheme i lost most of my icons (since there is no kiconloader in the middle anymore), and the same for kstandardaction icons. This patch makes it so that if you are using kstandardactions and your icon theme is hicolor but you have breeze or oxygen installed it changes the theme to one of those. I am unconvinced if we want this here or if i want this in my (and potentially) every application so when we run in Gnome or Unity, our apps get icons what were getting in kde4 times because they were using KIcon and they would lose now because of the QIcon::fromTheme recommendation. Obviously the missing icons also get fixed by QT_QPA_PLATFORMTHEME=kde but one can not expect to have this define when on non Plasma desktops and since in the past KIcon gave you oxygen-icons even if you were not on plasma i think it makes sense to do this. Diffs (updated) - src/kstandardaction.cpp a18527b Diff: https://git.reviewboard.kde.org/r/119713/diff/ Testing --- KGeography menu items have icons again. Thanks, Albert Astals Cid ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Web Shortcuts KCM
On 08/11/2014 09:45 AM, David Faure wrote: In any case you could ask the contributors for relicensing, before you spend a lot of time rewriting it (you can, but it's such a waste - and a risk for regressions / missing features) I'll try to track them down. Maybe Riddell can help me actually, he has experience with this sort of thing ... AFAIUI we do need it for plugin loading, yeah ... Cheers, Eike ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119711: Use CMAKE_INSTALL_FULL_LIBEXECDIR_KF5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119711/#review64284 --- src/start_kdeinit/start_kdeinit.c https://git.reviewboard.kde.org/r/119711/#comment44931 this won't work with relative/non-explicit BIN_INSTALL_DIR - Hrvoje Senjan On Aug. 11, 2014, 4:54 p.m., Nicolas Lécureuil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119711/ --- (Updated Aug. 11, 2014, 4:54 p.m.) Review request for KDE Frameworks and David Faure. Repository: kinit Description --- Resolves the problem of passing relative vs. absolute KF5_LIBEXEC_INSTALL_DIR/LIBEXEC_INSTALL_DIR. Diffs - src/start_kdeinit/CMakeLists.txt 56a91e3 src/start_kdeinit/start_kdeinit.c 02d4d54 src/start_kdeinit/start_kdeinit_wrapper.c f35c4a9 src/config-kdeinit.h.cmake 76cd867 src/kdeinit/CMakeLists.txt 8a84774 src/kdeinit/kinit.cpp 296ebfd src/klauncher/CMakeLists.txt 8a251ff src/klauncher/klauncher.cpp 124011e Diff: https://git.reviewboard.kde.org/r/119711/diff/ Testing --- Before it searches for /usr//usr/libexec and after all is fine. Thanks, Nicolas Lécureuil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119711: Use CMAKE_INSTALL_FULL_LIBEXECDIR_KF5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119711/ --- (Updated Aug. 11, 2014, 5:51 p.m.) Review request for KDE Frameworks and David Faure. Repository: kinit Description --- Resolves the problem of passing relative vs. absolute KF5_LIBEXEC_INSTALL_DIR/LIBEXEC_INSTALL_DIR. Diffs (updated) - src/start_kdeinit/start_kdeinit.c 02d4d54 src/start_kdeinit/start_kdeinit_wrapper.c f35c4a9 src/config-kdeinit.h.cmake 76cd867 src/kdeinit/CMakeLists.txt 8a84774 src/kdeinit/kinit.cpp 296ebfd src/klauncher/CMakeLists.txt 8a251ff src/klauncher/klauncher.cpp 124011e src/start_kdeinit/CMakeLists.txt 56a91e3 Diff: https://git.reviewboard.kde.org/r/119711/diff/ Testing --- Before it searches for /usr//usr/libexec and after all is fine. Thanks, Nicolas Lécureuil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119711: Use CMAKE_INSTALL_FULL_LIBEXECDIR_KF5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119711/#review64290 --- Ship it! Ship It! - Lukáš Tinkl On Srp. 11, 2014, 7:51 odp., Nicolas Lécureuil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119711/ --- (Updated Srp. 11, 2014, 7:51 odp.) Review request for KDE Frameworks and David Faure. Repository: kinit Description --- Resolves the problem of passing relative vs. absolute KF5_LIBEXEC_INSTALL_DIR/LIBEXEC_INSTALL_DIR. Diffs - src/start_kdeinit/start_kdeinit.c 02d4d54 src/start_kdeinit/start_kdeinit_wrapper.c f35c4a9 src/config-kdeinit.h.cmake 76cd867 src/kdeinit/CMakeLists.txt 8a84774 src/kdeinit/kinit.cpp 296ebfd src/klauncher/CMakeLists.txt 8a251ff src/klauncher/klauncher.cpp 124011e src/start_kdeinit/CMakeLists.txt 56a91e3 Diff: https://git.reviewboard.kde.org/r/119711/diff/ Testing --- Before it searches for /usr//usr/libexec and after all is fine. Thanks, Nicolas Lécureuil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Breeze widget style for KF5
On Mon, Aug 11, 2014 at 12:29 PM, Hugo Pereira Da Costa hugo.pere...@free.fr wrote: Hi all, For the last couple of weeks and after discussion with Nuno, Marco, Andrew and some others, I've worked on implementing most of the ideas from git://anongit.kde.org/breeze.git (more precisely from the QML demos at widgetstyles/qtquickcontrolsstyle) into a native widget style for KF5. Some screenshots below: dolphin: http://wstaw.org/m/2014/08/11/dolphin.png oxygen-demo: http://wstaw.org/m/2014/08/11/oxygen-demo.png http://wstaw.org/m/2014/08/11/oxygen-demo1.png http://wstaw.org/m/2014/08/11/oxygen-demo2.png Now this is of course not complete, but at least it is usable (I'm using it now). It naturally uses a lot of the code from oxygen, though for now I've preferred making a deep copy than actually sharing the code via libraries. Also it should be more efficient and have less 'issues' because it uses no pixmap caching but direct rendering to the widgets everywhere, mostly because said rendering is simpler than for oxygen. This should make it more easily dpi independent when this gets implemented inside Qt5. For the moment the code is in the following scratch repository: git://anongit.kde.org/scratch/hpereiradacosta/breeze Ultimately I'd like to - push this to some official repository (where should that be ? kde/workspace/breeze/kstyle ?) - make it the 'official' kf5 style (instead of the current QtCurve settings) - have feedback - iron out the remaining issues Among the things that are most notably missing are: a configuration ui (!) (though I foresee less things to be configurable than with oxygen) ... and then I'd like to: - make a gtk style - possibly make a kde4/qt4 style, - backport the improvement made to the code base (it is always good to revisit one's code) to oxygen@kf5 etc. Comments, objections, blessings, are welcome Best, Hugo ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel I - nearly - like it :) In oxygen-demo2.png you show the UI controls. It looks good, but a bit too flat for my taste. Could you do very subtle small color changes? In dolphin, the blue border is so.. in your face. Sure, there is probably a need for that border to indicate the part of dolphin that has focus, but does the border have to be so bright shiny blue? A white border with a small blue tint would be a nice experiment i think. Nice job thus far! I don't care if you use QtCurve or something else. As long as it looks good and is performant. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119711: Use CMAKE_INSTALL_FULL_LIBEXECDIR_KF5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119711/ --- (Updated Aug. 11, 2014, 6:23 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Faure. Repository: kinit Description --- Resolves the problem of passing relative vs. absolute KF5_LIBEXEC_INSTALL_DIR/LIBEXEC_INSTALL_DIR. Diffs - src/start_kdeinit/start_kdeinit.c 02d4d54 src/start_kdeinit/start_kdeinit_wrapper.c f35c4a9 src/config-kdeinit.h.cmake 76cd867 src/kdeinit/CMakeLists.txt 8a84774 src/kdeinit/kinit.cpp 296ebfd src/klauncher/CMakeLists.txt 8a251ff src/klauncher/klauncher.cpp 124011e src/start_kdeinit/CMakeLists.txt 56a91e3 Diff: https://git.reviewboard.kde.org/r/119711/diff/ Testing --- Before it searches for /usr//usr/libexec and after all is fine. Thanks, Nicolas Lécureuil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Breeze widget style for KF5
Hi Hugo, This is fantastic! I'm so excited to see how far your efforts have progressed. On Mon, Aug 11, 2014 at 3:29 AM, Hugo Pereira Da Costa wrote: Ultimately I'd like to - push this to some official repository (where should that be ? kde/workspace/breeze/kstyle ?) I'm ambivalent on where this is housed. You're certainly welcome to push it to the Breeze project repo (widgetstyles/kstyle) if there's no consensus on where to house it. - make it the 'official' kf5 style (instead of the current QtCurve settings) No objections from the VDG corner of course. :-) - have feedback I only have one or two questions. Generally though, this appears to be quite a faithful implementation of Breeze UI controls design captured in the QtQuick implementation. - What corner radius is that? It looks a touch larger than I remember. They might need to be a touch sharper everywhere (maybe round down instead of up on corner radii?). - If it's not too much trouble, we can eliminate the box around the header ( http://wstaw.org/m/2014/08/11/dolphin.png). - The tabs look great. :-) - The circular slider looks awesome ( http://wstaw.org/m/2014/08/11/oxygen-demo2.png). :-) - We (the VDG) will likely need to revisit the progress bar design since we didn't account for the % label which currently moves it off-center. We'll work on that and deliver an updated design that considers that. For now, it's fine as is. - I know this'll seem like a nit-pick, but is it possible to have the ends of the slider and the progress bar have a similar margin so they share the same alignment line (http://wstaw.org/m/2014/08/11/oxygen-demo2.png)? I completely understand why they look that way right now functionally, but this tweak would be primarily for visual not functional reasons. I'll need update the QtQuick implementation as well. - There may be one or two other very minor things, but I'll wait till you find a home for this and start ironing out any outstanding issues. - Overall it looks fantastic! Among the things that are most notably missing are: a configuration ui (!) (though I foresee less things to be configurable than with oxygen) ... and then I'd like to: - make a gtk style - possibly make a kde4/qt4 style, - backport the improvement made to the code base (it is always good to revisit one's code) to oxygen@kf5 etc. +1. I don't have much to recommend for configuration right now so, unless there are accessibility-related config stuff, I'd be ok if you decided that the config is relatively lower priority compared to the other stuff here. Wow. Super-excited by this Hugo! just holler if you have any questions from the VDG side of things. Much much respect, Andrew ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 118155: adapt to ecm_add_tests so that tests can be found
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118155/#review64304 --- The patch does not apply. - Albert Astals Cid On mai. 15, 2014, 3 p.m., Patrick Spendrin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118155/ --- (Updated mai. 15, 2014, 3 p.m.) Review request for KDE Frameworks, kdewin and Plasma. Repository: plasma-framework Description --- adapt to ecm_add_tests so that tests can be found Diffs - autotests/CMakeLists.txt dcee37f0771753d3e381e9d77f351cff16531e93 Diff: https://git.reviewboard.kde.org/r/118155/diff/ Testing --- mingw Thanks, Patrick Spendrin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build became unstable: kdelibs_stable #1167
See http://build.kde.org/job/kdelibs_stable/1167/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119699: KIO: add public API isClipboardDataCut/setClipboardDataCut.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119699/#review64315 --- Ship it! Looks good to me! - Eike Hein On Aug. 10, 2014, 8:59 p.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119699/ --- (Updated Aug. 10, 2014, 8:59 p.m.) Review request for KDE Frameworks and Eike Hein. Repository: kio Description --- This replaces the various copies of the code dealing with that in KIO, and will replace the original code in libkonq's KonqMimeData (which will then be removed). Unittest moved from libkonq and ported to non-deprecated KF5 API. Diffs - autotests/CMakeLists.txt 4d845cc924883c9b56f188e926918110987175b7 autotests/fileundomanagertest.cpp 12d9013160dbd4432bca512b329a3b3566e33a61 autotests/pastetest.h PRE-CREATION autotests/pastetest.cpp PRE-CREATION src/filewidgets/kfilepreviewgenerator.cpp b14b1d5f3aaa3b8a31bb3936ab6c4a77ae49b5ba src/widgets/paste.h 085d047a3d225f4c70a1a05568b00ae24649a144 src/widgets/paste.cpp b2a84b0dd7ee000cbdfbfba289f7afbcc9c41d17 Diff: https://git.reviewboard.kde.org/r/119699/diff/ Testing --- Compiles, fileundomanagertest still passes. Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
OSX/CI: kgeography fails to build on branch frameworks
[ 44%] /Users/marko/WC/KDECI-builds/kgeography/src/kgeography.cpp:18:10: fatal error: 'kicon.h' file not found #include kicon.h ^ Building CXX object src/CMakeFiles/kgeography.dir/mypopup.cpp.o [ 48%] Building CXX object src/CMakeFiles/kgeography.dir/popupmanager.cpp.o [ 51%] Building CXX object src/CMakeFiles/kgeography.dir/flagdivisionasker.cpp.o 1 error generated. make[2]: *** [src/CMakeFiles/kgeography.dir/kgeography.cpp.o] Error 1 make[2]: *** Waiting for unfinished jobs [ 55%] Building CXX object src/CMakeFiles/kgeography.dir/askwidget.cpp.o make[1]: *** [src/CMakeFiles/kgeography.dir/all] Error 2 make: *** [all] Error 2 KDE Continuous Integration Build == Building Project: kgeography - Branch frameworks ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is back to stable : kdelibs_stable #1168
See http://build.kde.org/job/kdelibs_stable/1168/ ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Breeze widget style for KF5
On Monday 11 August 2014 14:20:26 Luigi Toscano wrote: On Monday 11 of August 2014 14:08:35 Martin Gräßlin wrote: On Monday 11 August 2014 13:10:39 Luigi Toscano wrote: On Monday 11 of August 2014 13:05:19 Hugo Pereira Da Costa wrote: Hi Milian As someone with no clue: a) what's the advantage of having a native widget style, compared to using QtCurve settings? None, except that you need someone working on qtcurve Are there things missing / not implementable in QtCurve? Everything is implemementable in QtCurve, though not via a simple text config file. So here also, you need someone to do it. As someone else just watching: QtCurve is a KDE project now, shouldn't this help a bit? hey guys, I find this a rather strange topic for discussion. We are very happy that Hugo stepped up to write a native style. Questioning why he didn't use QtCurve seems absurd to me. I find this answer a bit overracting. I didn't do questioning police-style; I asked. End of story. If you don't expect question, don't put Comments, objections, blessings, are welcome at the end. I agree. Really, I'm thankful for Hugo is doing and has done for KDE. But since I have no clue about styles (I even said so!) I wanted to ask what the advantage of a native style over a QtCurve config file are. Hugo answered that. So whats the deal Martin? Bye -- Milian Wolff m...@milianw.de http://milianw.de ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: OSX/CI: kgeography fails to build on branch frameworks
2014-08-11 21:30 GMT+02:00 Marko Käning mk-li...@email.de: [ 44%] /Users/marko/WC/KDECI-builds/kgeography/src/kgeography.cpp:18:10: fatal error: 'kicon.h' file not found #include kicon.h ^ Building CXX object src/CMakeFiles/kgeography.dir/mypopup.cpp.o [ 48%] Building CXX object src/CMakeFiles/kgeography.dir/popupmanager.cpp.o [ 51%] Building CXX object src/CMakeFiles/kgeography.dir/flagdivisionasker.cpp.o 1 error generated. make[2]: *** [src/CMakeFiles/kgeography.dir/kgeography.cpp.o] Error 1 make[2]: *** Waiting for unfinished jobs [ 55%] Building CXX object src/CMakeFiles/kgeography.dir/askwidget.cpp.o make[1]: *** [src/CMakeFiles/kgeography.dir/all] Error 2 make: *** [all] Error 2 KDE Continuous Integration Build == Building Project: kgeography - Branch frameworks I get this on Windows too, and I bet I would get it on Linux if kdelibs4 header files aren't installed. -- Nicolás ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Breeze widget style for KF5
On Monday 11 August 2014 13:05:19 Hugo Pereira Da Costa wrote: Hi Milian On Monday 11 August 2014 12:29:05 Hugo Pereira Da Costa wrote: Hi all, For the last couple of weeks and after discussion with Nuno, Marco, Andrew and some others, I've worked on implementing most of the ideas from git://anongit.kde.org/breeze.git http://anongit.kde.org/breeze.git (more precisely from the QML demos at widgetstyles/qtquickcontrolsstyle) into a native widget style for KF5. Some screenshots below: dolphin: http://wstaw.org/m/2014/08/11/dolphin.png oxygen-demo: http://wstaw.org/m/2014/08/11/oxygen-demo.png http://wstaw.org/m/2014/08/11/oxygen-demo1.png http://wstaw.org/m/2014/08/11/oxygen-demo2.png Now this is of course not complete, but at least it is usable (I'm using it now). It naturally uses a lot of the code from oxygen, though for now I've preferred making a deep copy than actually sharing the code via libraries. Also it should be more efficient and have less 'issues' because it uses no pixmap caching but direct rendering to the widgets everywhere, mostly because said rendering is simpler than for oxygen. This should make it more easily dpi independent when this gets implemented inside Qt5. For the moment the code is in the following scratch repository: git://anongit.kde.org/scratch/hpereiradacosta/breeze Ultimately I'd like to - push this to some official repository (where should that be ? kde/workspace/breeze/kstyle ?) - make it the 'official' kf5 style (instead of the current QtCurve settings) - have feedback - iron out the remaining issues Among the things that are most notably missing are: a configuration ui (!) (though I foresee less things to be configurable than with oxygen) ... and then I'd like to: - make a gtk style - possibly make a kde4/qt4 style, - backport the improvement made to the code base (it is always good to revisit one's code) to oxygen@kf5 etc. Comments, objections, blessings, are welcome As someone with no clue: a) what's the advantage of having a native widget style, compared to using QtCurve settings? None, except that you need someone working on qtcurve OT: isn't someone working on QtCurve? I thought so, now that it got imported into KDE infrastructure. Are there things missing / not implementable in QtCurve? Everything is implemementable in QtCurve, though not via a simple text config file. So here also, you need someone to do it. OK thanks for the clarification. And to make this explicit once more: I don't care whether it's a native style or a QtCurve config, I'm just interested in the differences/advantages. I'm very glad someone (i.e. you, Hugo) is working on this new style, it promises to be a very nice one and I'm looking forward to using it, unrelated of its underlying architecture. So yes, thanks for working on it. b) do you share the git history, i.e. did you do a proper fork, or did you reimport the sources and started from scratch (I hope not). For breeze I reimported the needed parts of oxygen sources and started from scratch, mostly because a large fraction of the code from oxygen is overkill for Breeze's needs. Could someone with enough git foo please replay Hugo's commits on a fork of QtCurve? Having the history in another repository means it does not exist. People won't bother finding the file (esp. if it eventually gets renamed or moved) in another repository just to do a git blame on it in the future. Bye -- Milian Wolff m...@milianw.de http://milianw.de ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: OSX/CI: kgeography fails to build on branch frameworks
El Dilluns, 11 d'agost de 2014, a les 21:30:07, Marko Käning va escriure: [ 44%] /Users/marko/WC/KDECI-builds/kgeography/src/kgeography.cpp:18:10: fatal error: 'kicon.h' file not found #include kicon.h ^ Building CXX object src/CMakeFiles/kgeography.dir/mypopup.cpp.o [ 48%] Building CXX object src/CMakeFiles/kgeography.dir/popupmanager.cpp.o [ 51%] Building CXX object src/CMakeFiles/kgeography.dir/flagdivisionasker.cpp.o 1 error generated. make[2]: *** [src/CMakeFiles/kgeography.dir/kgeography.cpp.o] Error 1 make[2]: *** Waiting for unfinished jobs [ 55%] Building CXX object src/CMakeFiles/kgeography.dir/askwidget.cpp.o make[1]: *** [src/CMakeFiles/kgeography.dir/all] Error 2 make: *** [all] Error 2 I appreciate your efforts for building kgeography_frameworks, please try again since i just pushed some code to it. But, i think you should not try to build more thing than the linux CI, it's just asking for trouble :D Cheers, Albert KDE Continuous Integration Build == Building Project: kgeography - Branch frameworks ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: OSX/CI: kgeography fails to build on branch frameworks
Hi Albert, On 11 Aug 2014, at 23:05 , Albert Astals Cid aa...@kde.org wrote: I appreciate your efforts for building kgeography_frameworks, please try again since i just pushed some code to it. just did. All is fine now. :) But, i think you should not try to build more thing than the linux CI, it's just asking for trouble :D Well, I have been already regularly building kgeography on OSX/CI w/o trouble... You see, there’s not so much trouble as you are afraid of! ;) Thanks for taking care of this so quickly. Greets, Marko ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119530: kcoreaddons: Fix kautosave doesn't work with more than 1 file per application
On Aug. 11, 2014, 8:23 a.m., David Faure wrote: Nice patch, I love the ton of unittests :) Awesome review. Thanks. I think I fixed all the concerns, I ran astyle and posted a new diff. On Aug. 11, 2014, 8:23 a.m., David Faure wrote: autotests/kautosavefiletest.cpp, line 56 https://git.reviewboard.kde.org/r/119530/diff/1/?file=294193#file294193line56 Coding style: please remove spaces within parentheses (use search/replace or run the astyle-kdelibs script after reading the howto in there). kdelibs4 was very inconsistent, but KF5 is very consistent. I have run astyle-kdelibs On Aug. 11, 2014, 8:23 a.m., David Faure wrote: autotests/kautosavefiletest.cpp, line 60 https://git.reviewboard.kde.org/r/119530/diff/1/?file=294193#file294193line60 why no QVERIFY() here? init() is not a test. It is only intended to setup a clean test state. If errors are indicated in the initialization code, then it really indicates an error in the previous test or KSomeOtherApplication. It would also mean that if a test crash you would have to run the unittests twice: once to generate the error in the initialization basically telling you that the previous test crashed, and once to get the new results. On Aug. 11, 2014, 8:23 a.m., David Faure wrote: src/lib/io/kautosavefile.h, line 162 https://git.reviewboard.kde.org/r/119530/diff/1/?file=294195#file294195line162 How can you drop something you don't have? I'm a bit confused by the wording. This was bleed through of the implementation detail of keeping the .kalock file, which is required when using kautosavefile as backup. The .kalock file preserves the link between the kautosave file and the real file. On Aug. 11, 2014, 8:23 a.m., David Faure wrote: src/lib/io/kautosavefile.h, line 232 https://git.reviewboard.kde.org/r/119530/diff/1/?file=294195#file294195line232 Ah, but no... you cannot add new virtual methods, that's binary incompatible. Does it have to be virtual? Adding a non-virtual method is fine (add a @since 5.2 to its documentation). It was supposed to be a reimplmentation of the remove in QFile. I thought it fell under the https://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++#Adding_a_reimplemented_virtual_function exception. open, close, resize and destructor are all virtual. remove is not and I missed that. Calling remove on an unlocked kautosavefile will remove it regardless of lock, and break the intended usage. I don't see a way around it while preserving compatibility with Qfile. I added a warning in the header about the breakage. I added housekeeping code in the stalefile code. If people are passing KAutoSaveFiles around as Qfile (,which is expected usage) something will inevitably call remove(), so housekeeping is required. I fixed unit tests that called remove() expecting to not be able to remove unlocked files. I added a unit test of the housekeeping. On Aug. 11, 2014, 8:23 a.m., David Faure wrote: src/lib/io/kautosavefile.h, line 273 https://git.reviewboard.kde.org/r/119530/diff/1/?file=294195#file294195line273 If you want a method to be removed later (= KF6), you can already mark it as deprecated. But isn't allStaleFiles(app) nicer to read/write than staleFiles(QUrl(), app)? When reading such code, it's not clear why there's an empty url argument, while allStaleFiles is clear to the reader. Whether the method is useful, though, I don't know. In any case, let's decide: either keep, or deprecate. A @todo remove is kind of a half-baked decision which will never happen ;) I agree @todo remove is half-baked. Initially, there were 2 parallel implementations of almost identical behavior with independent bugs. The semantics for the staleFiles are inconsistent. Passing no filename returns all the files. Passing no appname returns files for just this 1 app. There is no way to get all the autosave files for 1 file for all apps (which you care aboue if multiple apps are using the same library to edit the same file), or to get all the autosave files for all apps. There is no way to clean up, or even show autosave files that are accumulating in the directory. The files returned are not necessarily stale, there could be a live locker, which requires looping over all of the files to attempt to lock it before checking if it is the one that you want. If there is a live locker there is no way to find out, although KAutoSave definitely knows. There is no way to fetch only crash recovery kautosaves. I am not sure what the correct mix of functions is, but I'd suggest something like: getLockInfo(pid, hostname, appname) static autoSaveFiles(filename = defaults to all filenames , flags = defaults to all types: locked unlocked, crashed not running(clean exit) running locker , app = defaults to all apps); This allows people to do what they want: Did I crash,
Re: Review Request 119530: kcoreaddons: Fix kautosave doesn't work with more than 1 file per application
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119530/ --- (Updated Aug. 11, 2014, 9:22 p.m.) Review request for KDE Frameworks and David Faure. Repository: kcoreaddons Description --- kautosave doesn't work when any app tries to use a second filename, because it doesn't filter on filename. The unit tests can be droppped into master to show the problem, if you remove the include on line 21. This patch: 1. Adds unit tests to test more behavior mentioned in the header. 2. Fixes kautosave working with multple files per application. 3. Fixes filenaming brittleness, which would cause kautosave to randomly fail when the last 3 randomly generated characters in the filename matched any 3 consequtive chracters in the managed filename. Diffs (updated) - src/lib/io/kautosavefile_p.cpp PRE-CREATION src/lib/io/kautosavefile_p.h PRE-CREATION src/lib/io/kautosavefile.cpp 13a13d7 src/lib/io/kautosavefile.h 05cc3ae src/lib/CMakeLists.txt 26eb5a1 autotests/kautosavefiletest.h cf70f4c autotests/kautosavefiletest.cpp ec0309e ! PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119530/diff/ Testing --- Ran unit tests. Ran kdeedu with kanagram. Thanks, Andreas Xavier ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
OSX/CI: kmymoney fails to build on branch framework
Why is the build failing here with an Alarm clock”? --- /Users/marko/WC/KDECI-builds/kmymoney/kmymoney/views/kmymoneyview.cpp:2287:16: warning: 'KIcon' is deprecated [-Wdeprecated-declarations] frm-setIcon(KIcon(icon)); ^ /opt/kde/install/darwin/mavericks/clang/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kicon.h:46:41: note: 'KIcon' declared here class KDELIBS4SUPPORT_DEPRECATED_EXPORT KIcon : public QIcon ^ 55 warnings generated. make[1]: *** [kmymoney/views/CMakeFiles/views.dir/all] Alarm clock: 14 make: *** [all] Error 2 make: INTERNAL: Exiting with 1 jobserver tokens available; should be 7! KDE Continuous Integration Build == Building Project: kmymoney - Branch frameworks ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119681: Duplicate header guard from notifybylogfile.h in notifybyaudio.h
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119681/ --- (Updated Aug. 11, 2014, 9:32 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Martin Klapetek. Repository: knotifications Description --- Duplicate header guard from notifybylogfile.h in notifybyaudio.h Diffs - src/notifybyaudio.h 27cf4cb Diff: https://git.reviewboard.kde.org/r/119681/diff/ Testing --- I compiled. There are no unit tests. Thanks, Andreas Xavier ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KPlotting and KUnitConversion
On Monday 11 August 2014 18:41:33 Garret Wassermann wrote: Simple is good, this is why I enjoy the KPlotting library. Might I ask what use cases you have in mind for the framework so I can better make suggestions? KPlotting is intended for applications, where the plot isn't a central part of the application, but simply a means to visualize a set of data points that are secondary to the application. It is a bit like comparing QTextEdit and KatePart. You probably would not want to use the former in KDevelop or Kile, while it is fine in an application, where you just need to enter some comment. Does KPlotting have a QML widget/graph, or is strictly a QtWidget at this point? If only QtWidget, do you think a QML plot is a priority and/or better suited to an interactive plot? KPlotWidget is a QWidget class. I am not familiar with QML either, but if you manage to add QML support that reuses the logic about axis scaling, label placement, etc. then let me see it. If possible, please keep the discussion on the list. I also added the kde-edu list to CC, because KPlotWidget is used by many educational applications. Maybe while those applications get ported to KF5, we can get some additional input for improvements, without bloating it. Thanks for your interest. Christoph Feck (kdepepo) ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 119723: Show q_properties at the top of class documentation
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119723/ --- Review request for KDE Frameworks and Aurélien Gâteau. Repository: kapidox Description --- Show q_properties at the top of class documentation This brings it in line with Qt, and makes it hopefully a bit easier for QML users to find things. Original doxygenlayout xml is the template doxygen file but with properties moved. Longer term I want to make it autopopulate @accessor methods so it jumps to the relevant bit of doc. Diffs - src/kapidox/data/DoxygenLayout.xml PRE-CREATION src/kapidox/generator.py 203586e Diff: https://git.reviewboard.kde.org/r/119723/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119723: Show q_properties at the top of class documentation
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119723/#review64337 --- I like it. How hard would it be then to remvoe the properties' methods (get/set/signal) from the rest of the documentation? It would be really cool to document them all together. - Aleix Pol Gonzalez On Aug. 11, 2014, 10:35 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119723/ --- (Updated Aug. 11, 2014, 10:35 p.m.) Review request for KDE Frameworks and Aurélien Gâteau. Repository: kapidox Description --- Show q_properties at the top of class documentation This brings it in line with Qt, and makes it hopefully a bit easier for QML users to find things. Original doxygenlayout xml is the template doxygen file but with properties moved. Longer term I want to make it autopopulate @accessor methods so it jumps to the relevant bit of doc. Diffs - src/kapidox/data/DoxygenLayout.xml PRE-CREATION src/kapidox/generator.py 203586e Diff: https://git.reviewboard.kde.org/r/119723/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Breeze widget style for KF5
On Monday 11 August 2014 22:49:43 Milian Wolff wrote: On Monday 11 August 2014 14:20:26 Luigi Toscano wrote: On Monday 11 of August 2014 14:08:35 Martin Gräßlin wrote: On Monday 11 August 2014 13:10:39 Luigi Toscano wrote: On Monday 11 of August 2014 13:05:19 Hugo Pereira Da Costa wrote: Hi Milian As someone with no clue: a) what's the advantage of having a native widget style, compared to using QtCurve settings? None, except that you need someone working on qtcurve Are there things missing / not implementable in QtCurve? Everything is implemementable in QtCurve, though not via a simple text config file. So here also, you need someone to do it. As someone else just watching: QtCurve is a KDE project now, shouldn't this help a bit? hey guys, I find this a rather strange topic for discussion. We are very happy that Hugo stepped up to write a native style. Questioning why he didn't use QtCurve seems absurd to me. I find this answer a bit overracting. I didn't do questioning police-style; I asked. End of story. If you don't expect question, don't put Comments, objections, blessings, are welcome at the end. I agree. Really, I'm thankful for Hugo is doing and has done for KDE. But since I have no clue about styles (I even said so!) I wanted to ask what the advantage of a native style over a QtCurve config file are. Hugo answered that. So whats the deal Martin? Sorry, I didn't want to overreact. I was a little bit afraid that this drifts in a direction which can be read as Hugo did all wrong. Cheers Martin 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
