Re: setting default widgetStyle (and ColorScheme)
On Saturday, November 28, 2015 7:58:47 PM CET René J. V. Bertin wrote: > Olivier Goffart wrote: > > A pure KF5 appliation would anyway use the KDE platform theme plugin > > provided by KDE Frameworks. (in frameworkintegration) > > (So in other words: that code should not be executed when kde frameworks > > is > > installed, in theory) > > So... No, it doesn't. Not on OS X when using the default QPA plugin (Cocoa). > From the looks of it that one lacks support for theme plugins. Or rather, > it doesn't return the appropriate thing(s) from > QGuiApplicationPrivate::platform_integration->themeNames(). > > Now the question is, should KF5 applications be able to use the KDE platform > theme plugin provided by kf5-frameworkintegration if that framework is > installed? In my opinion: no. I even think the frameworkintegration framework should get removed from frameworks and moved into Plasma Workspace. Because that's what it is about: integrating Qt applications into plasma. 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
Jenkins-kde-ci: kio master stable-kf5-qt5 » Linux,gcc - Build # 166 - Fixed!
GENERAL INFO BUILD SUCCESS Build URL: https://build.kde.org/job/kio%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/166/ Project: PLATFORM=Linux,compiler=gcc Date of build: Mon, 30 Nov 2015 06:23:52 + Build duration: 5 min 10 sec CHANGE SET Revision 47db48dc85422f3bfad0af19dfd776524ff8d5bf by montel: (Use i18n here) change: edit autotests/http/CMakeLists.txt change: edit src/ioslaves/http/httpfilter.cpp JUNIT RESULTS Name: (root) Failed: 0 test(s), Passed: 47 test(s), Skipped: 0 test(s), Total: 47 test(s) COBERTURA RESULTS Cobertura Coverage Report PACKAGES 20/20 (100%)FILES 253/331 (76%)CLASSES 253/331 (76%)LINE 24813/50035 (50%)CONDITIONAL 13415/20717 (65%) By packages autotests FILES 61/61 (100%)CLASSES 61/61 (100%)LINE 7047/7264 (97%)CONDITIONAL 3849/7067 (54%) autotests.http FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 475/476 (100%)CONDITIONAL 166/272 (61%) autotests.kcookiejar FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 182/199 (91%)CONDITIONAL 60/90 (67%) src.core FILES 94/116 (81%)CLASSES 94/116 (81%)LINE 7397/14021 (53%)CONDITIONAL 3873/5383 (72%) src.core.kssl FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 3/6 (50%) src.filewidgets FILES 20/36 (56%)CLASSES 20/36 (56%)LINE 2286/7590 (30%)CONDITIONAL 915/1409 (65%) src.ioslaves.file FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 430/843 (51%)CONDITIONAL 313/459 (68%) src.ioslaves.http FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 750/3799 (20%)CONDITIONAL 547/678 (81%) src.ioslaves.http.kcookiejar FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 642/804 (80%)CONDITIONAL 602/758 (79%) src.ioslaves.trash FILES 7/9 (78%)CLASSES 7/9 (78%)LINE 684/1182 (58%)CONDITIONAL 358/495 (72%) src.ioslaves.trash.tests FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 690/768 (90%)CONDITIONAL 433/820 (53%) src.kioslave FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/26 (54%)CONDITIONAL 5/10 (50%) src.kntlm FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 302/388 (78%)CONDITIONAL 86/108 (80%) src.kpasswdserver FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 389/600 (65%)CONDITIONAL 284/412 (69%) src.kpasswdserver.autotests FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 280/285 (98%)CONDITIONAL 146/254 (57%) src.urifilters.fixhost FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 32/35 (91%)CONDITIONAL 42/52 (81%) src.urifilters.ikws FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 248/743 (33%)CONDITIONAL 147/194 (76%) src.urifilters.localdomain FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 20/27 (74%)CONDITIONAL 14/18 (78%) src.urifilters.shorturi FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 226/256 (88%)CONDITIONAL 292/358 (82%) src.widgets FILES 29/62 (47%)CLASSES 29/62 (47%)LINE 2684/10636 (25%)CONDITIONAL 1280/1874 (68%)___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins-kde-ci: kio master stable-kf5-qt5 » Linux,gcc - Build # 166 - Fixed!
GENERAL INFO BUILD SUCCESS Build URL: https://build.kde.org/job/kio%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/166/ Project: PLATFORM=Linux,compiler=gcc Date of build: Mon, 30 Nov 2015 06:23:52 + Build duration: 5 min 10 sec CHANGE SET Revision 47db48dc85422f3bfad0af19dfd776524ff8d5bf by montel: (Use i18n here) change: edit autotests/http/CMakeLists.txt change: edit src/ioslaves/http/httpfilter.cpp JUNIT RESULTS Name: (root) Failed: 0 test(s), Passed: 47 test(s), Skipped: 0 test(s), Total: 47 test(s) COBERTURA RESULTS Cobertura Coverage Report PACKAGES 20/20 (100%)FILES 253/331 (76%)CLASSES 253/331 (76%)LINE 24813/50035 (50%)CONDITIONAL 13415/20717 (65%) By packages autotests FILES 61/61 (100%)CLASSES 61/61 (100%)LINE 7047/7264 (97%)CONDITIONAL 3849/7067 (54%) autotests.http FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 475/476 (100%)CONDITIONAL 166/272 (61%) autotests.kcookiejar FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 182/199 (91%)CONDITIONAL 60/90 (67%) src.core FILES 94/116 (81%)CLASSES 94/116 (81%)LINE 7397/14021 (53%)CONDITIONAL 3873/5383 (72%) src.core.kssl FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 3/6 (50%) src.filewidgets FILES 20/36 (56%)CLASSES 20/36 (56%)LINE 2286/7590 (30%)CONDITIONAL 915/1409 (65%) src.ioslaves.file FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 430/843 (51%)CONDITIONAL 313/459 (68%) src.ioslaves.http FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 750/3799 (20%)CONDITIONAL 547/678 (81%) src.ioslaves.http.kcookiejar FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 642/804 (80%)CONDITIONAL 602/758 (79%) src.ioslaves.trash FILES 7/9 (78%)CLASSES 7/9 (78%)LINE 684/1182 (58%)CONDITIONAL 358/495 (72%) src.ioslaves.trash.tests FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 690/768 (90%)CONDITIONAL 433/820 (53%) src.kioslave FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/26 (54%)CONDITIONAL 5/10 (50%) src.kntlm FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 302/388 (78%)CONDITIONAL 86/108 (80%) src.kpasswdserver FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 389/600 (65%)CONDITIONAL 284/412 (69%) src.kpasswdserver.autotests FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 280/285 (98%)CONDITIONAL 146/254 (57%) src.urifilters.fixhost FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 32/35 (91%)CONDITIONAL 42/52 (81%) src.urifilters.ikws FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 248/743 (33%)CONDITIONAL 147/194 (76%) src.urifilters.localdomain FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 20/27 (74%)CONDITIONAL 14/18 (78%) src.urifilters.shorturi FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 226/256 (88%)CONDITIONAL 292/358 (82%) src.widgets FILES 29/62 (47%)CLASSES 29/62 (47%)LINE 2684/10636 (25%)CONDITIONAL 1280/1874 (68%)___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 126199: Don't warn when SVG(Z) icons are provided with multiple sizes/levels of detail
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126199/ --- Review request for KDE Frameworks and Alex Merry. Repository: extra-cmake-modules Description --- This change adds SVG(Z) extensions to the list of allowed icons for specific sizes. This technically works and is practiced, e.g. for some Breeze icons. Reasoning: Some SVG icons do not scale well down from 32 to 22 or up from 16 to 22. For such cases icons are typically specially crafted for 22 and 16, at least. Then there's no single icon that be marked as "sc". So warnings such as: CMake Warning at /ECMInstallIcons.cmake:272 (message): Fixed-size icon foo.svg is not PNG or MNG ... are misleading. Diffs - modules/ECMInstallIcons.cmake 549ebe1 Diff: https://git.reviewboard.kde.org/r/126199/diff/ Testing --- ECM no longer warns for projects that use .svg icons of multiple variants (e.g. kreport.git master) Thanks, Jarosław Staniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme (and autotests)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126198/ --- (Updated Nov. 29, 2015, 8:53 p.m.) Review request for KDE Software on Mac OS X and KDE Frameworks. Changes --- This revision fixes the menu item shortcut issue by always returning the keybindings from the native platform theme, and by cutting down on the number of themeHints provided by the KDEPlatformPlugin. A lesson learned by Microsoft long ago: menu shortcuts shouldn't be translated nor set to key combinations from foreign systems. :) Repository: frameworkintegration Description --- The KdePlatformTheme plugin can be enabled on OS X with a minimal patch to Qt5; all that is required is to include the `qgenericunixservices` and `qgenericunixthemes` components in the build, and to append `"kde"` to the list returned by `QCocoaIntegration::themeNames()` for instance under the condition that `KDE_SESSION_VERSION` is set to a suitable value in the environment. This will allow KF5 and Qt5 applications to use the theme selected through KDE if FrameworkIntegration is installed and KDE_SESSION_VERSION is set, which seems like a sufficiently specific set of conditions that is easy to avoid by users who prefer to use the Mac native theme. While requestion the KDE theme is also possible through `-style kde` or `env QT_STYLE_OVERRIDE=kde` the use of the KdePlatformTheme plugin appears to be the only way to get the full theme, including the font and colour selection. In my opinion it is above all the font customisation which is a very welcome feature for Qt/Mac; by default Qt applications use the default system font (Lucida Grande 13pt or even 14pt) throughout. This is a good UI font, but not at that size (and most "native" OS X applications indeed use a range of smaller sizes, depending on role. It does have introduce a number of regressions, which the current patch aims to address. The most visible and problematic of these regressions is the loss of the Mac-style menu bar and thus of all menu items (actions). The fix is straightforward : on OS X (and similarly affected platforms?), an instance of the native Cocoa platform theme is created through the private API, and used as a fallback rather than immediately falling back to the default implementations from `QPlatformTheme`. In addition, methods missing from (not overridden by) `KdePlatformTheme` are provided on OS X and call the corresponding methods from the native theme. It is this change which restores the menubar and even the Dock menu functionality. One minor regression remains but should be easy to fix (elsewhere?): the Preferences menu loses its keyboard shortcut (Command-,). Given the fallback nature of the native platform instance I have preferred to print a warning rather than using something like `qFatal`, above all because the message printed by qFatal tends to get lost on OS X. I can replace my use of `qWarning` with a dialog giving the choice between continuing or exiting the application - code that would be called in the menu methods because only there is it certain that the application actually needs a menubar. In line with experience and feedback from the KDE(4)-Mac community I have decided to force the use of native dialogs rather than the ones from the KdePlatformPlugin. In addition I set the fallback value for `ShowIconsOnPushButtons` to false in line with platform guidelines, and ensure that the autotests are not built as app bundles. Diffs (updated) - autotests/CMakeLists.txt 7c2129c src/kstyle/kstyle.cpp 6ba5d51 src/platformtheme/kdeplatformtheme.h 97d09df src/platformtheme/kdeplatformtheme.cpp 80dbcb7 src/platformtheme/khintssettings.cpp 8adf6c5 Diff: https://git.reviewboard.kde.org/r/126198/diff/ Testing --- On Mac OS X with Qt 5.5.1, KF5 frameworks 5.16.0 and QtCurve git/head. I have not verified to what extent my use of a private `QGuiApplication` API links builds to a specific Qt version (I consider that nothing shocking and a minor price to pay). >>> Do I need to add some glue to the CMake file so that it will warn if the >>> private headerfiles are not available? Apparently no changes were required >>> to find them. Thanks, René J.V. Bertin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 126198: [OS X] adaptations for the KdePlatformTheme (and autotests)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126198/ --- Review request for KDE Software on Mac OS X and KDE Frameworks. Repository: frameworkintegration Description --- The KdePlatformTheme plugin can be enabled on OS X with a minimal patch to Qt5; all that is required is to include the `qgenericunixservices` and `qgenericunixthemes` components in the build, and to append `"kde"` to the list returned by `QCocoaIntegration::themeNames()` for instance under the condition that `KDE_SESSION_VERSION` is set to a suitable value in the environment. This will allow KF5 and Qt5 applications to use the theme selected through KDE if FrameworkIntegration is installed and KDE_SESSION_VERSION is set, which seems like a sufficiently specific set of conditions that is easy to avoid by users who prefer to use the Mac native theme. While requestion the KDE theme is also possible through `-style kde` or `env QT_STYLE_OVERRIDE=kde` the use of the KdePlatformTheme plugin appears to be the only way to get the full theme, including the font and colour selection. In my opinion it is above all the font customisation which is a very welcome feature for Qt/Mac; by default Qt applications use the default system font (Lucida Grande 13pt or even 14pt) throughout. This is a good UI font, but not at that size (and most "native" OS X applications indeed use a range of smaller sizes, depending on role. It does have introduce a number of regressions, which the current patch aims to address. The most visible and problematic of these regressions is the loss of the Mac-style menu bar and thus of all menu items (actions). The fix is straightforward : on OS X (and similarly affected platforms?), an instance of the native Cocoa platform theme is created through the private API, and used as a fallback rather than immediately falling back to the default implementations from `QPlatformTheme`. In addition, methods missing from (not overridden by) `KdePlatformTheme` are provided on OS X and call the corresponding methods from the native theme. It is this change which restores the menubar and even the Dock menu functionality. One minor regression remains but should be easy to fix (elsewhere?): the Preferences menu loses its keyboard shortcut (Command-,). Given the fallback nature of the native platform instance I have preferred to print a warning rather than using something like `qFatal`, above all because the message printed by qFatal tends to get lost on OS X. I can replace my use of `qWarning` with a dialog giving the choice between continuing or exiting the application - code that would be called in the menu methods because only there is it certain that the application actually needs a menubar. In line with experience and feedback from the KDE(4)-Mac community I have decided to force the use of native dialogs rather than the ones from the KdePlatformPlugin. In addition I set the fallback value for `ShowIconsOnPushButtons` to false in line with platform guidelines, and ensure that the autotests are not built as app bundles. Diffs - src/platformtheme/khintssettings.cpp 8adf6c5 src/platformtheme/kdeplatformtheme.cpp 80dbcb7 src/kstyle/kstyle.cpp 6ba5d51 src/platformtheme/kdeplatformtheme.h 97d09df autotests/CMakeLists.txt 7c2129c Diff: https://git.reviewboard.kde.org/r/126198/diff/ Testing --- On Mac OS X with Qt 5.5.1, KF5 frameworks 5.16.0 and QtCurve git/head. I have not verified to what extent my use of a private `QGuiApplication` API links builds to a specific Qt version (I consider that nothing shocking and a minor price to pay). >>> Do I need to add some glue to the CMake file so that it will warn if the >>> private headerfiles are not available? Apparently no changes were required >>> to find them. Thanks, René J.V. Bertin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle
On Nov. 25, 2015, 6:18 p.m., René J.V. Bertin wrote: > > See qtbase/src/plugins/platforms/cocoa/qcocoaintegration.mm and > > qcocoahelpers.mm > > René J.V. Bertin wrote: > Isn't copy/paste a great tool? :) > > Anyway, `qt_mac_transformProccessToForegroundApplication` only reads the > `LSUIElement` key to determine whether an application is allowed to be > transformed to a foreground application, and I don't see any evidence that it > is published. It appears to be intended to be called by default, unless the > env. variable `QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM` is set. Which > is a bit surprising, but doing a `putenv` of that variable at the start of > `kdemain` indeed does appear to have the desired effect. ping? - René J.V. --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126170/#review88838 --- On Nov. 25, 2015, 7:12 p.m., René J.V. Bertin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126170/ > --- > > (Updated Nov. 25, 2015, 7:12 p.m.) > > > Review request for KDE Software on Mac OS X and KDE Frameworks. > > > Repository: kded > > > Description > --- > > There should be no reason to build `kded5` as an app bundle on OS X, and with > recent feedback in mind I postulated that marking it "nongui" > (`ecm_mark_nongui_application`) would be acceptable on other platforms too. > > Additionally, `kded5` doesn't have any more reason to appear in the Dock or > app switcher, on OS X, so I have added the code to make it an agent. > > > Diffs > - > > CMakeLists.txt 4b9a5ff > src/CMakeLists.txt 5e95df8 > src/kded.cpp 6929d7d > > Diff: https://git.reviewboard.kde.org/r/126170/diff/ > > > Testing > --- > > On OS X 10.9.5 with Qt 5.5.1 and FWs 5.16.0 . > > > Thanks, > > René J.V. Bertin > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 126039: When configfile is loaded from resource, do not issue file not found error
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126039/#review88923 --- Ok for me, if that allows better error handling. - Christoph Cullmann On Nov. 12, 2015, 11:15 p.m., Andrew McCann wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126039/ > --- > > (Updated Nov. 12, 2015, 11:15 p.m.) > > > Review request for KDE Frameworks, Christoph Cullmann and Jeremy Whiting. > > > Repository: knewstuff > > > Description > --- > > When configfile is loaded from resource, do not issue file not found error. > > Encountered this problem while attempting to make KDevelop work on OSX as an > app bundle. > > Concretely, the logic error here is that the file actually is loaded and is > aborting early. > > If the file were actually not found, the following code block that tests for > validity will error anyway. > > > Diffs > - > > src/core/engine.cpp 56912ddfa8312ea6233aecffda296f041b180237 > > Diff: https://git.reviewboard.kde.org/r/126039/diff/ > > > Testing > --- > > Verify that loading configfile from qt5's resource system ex > ":/kconfig/test.knsrc" now works and didn't before. > > > Thanks, > > Andrew McCann > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125869: Convert all io slave .protocol data to json and embed it.
> On Nov. 3, 2015, 9:47 p.m., Albert Astals Cid wrote: > > How does this work without modifying > > KProtocolInfoPrivate::KProtocolInfoPrivate? > > Christoph Cullmann wrote: > You mean the JSON stuff? That was implemented in > https://git.reviewboard.kde.org/r/125830/ > For the http slave, that already works nicely, but we missed that > "ExtraNames" as used by other slaves need i18n care. > > Albert Astals Cid wrote: > i see, i did not see that there's two almost copied > KProtocolInfoPrivate::KProtocolInfoPrivate implementations > > So the json magic stuff (you can see > ./src/ioslaves/http/kcookiejar/kcookiejar.json in kio) only works for > Description and Name inside KPlugin, someone would need to update > createjsoncontext.py and filljsonfrompo.py so they also take into account > ExtraNames inside childs of "KDE-KIO-Protocols" and then make that new code > from 125830 extract the correct translation from the json. > > Alex Richardson wrote: > Reading the translated string can be done using > `KPluginMetaData::readTranslatedString()` > > Christoph Cullmann wrote: > Hmm, Ok, can take a look at that scripts. Will it be a problem that the > ExtraNames are a stringlist or is that fine? > > Albert Astals Cid wrote: > You'll have to take care of serializing and unserializing the list, > ideally using a well known marker like ; or similar. The scripts are at > https://websvn.kde.org/trunk/l10n-kf5/scripts/ Hi, ok, started to take a look at that again ;=) Is there actually any way to get all entries out of KConfig for all locales in the .ini? Atm I struggle a bit with the fact that the localized keys are hidden from any keys() accessor I can get from the outside. - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125869/#review87966 --- On Nov. 1, 2015, 6:13 p.m., Christoph Cullmann wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125869/ > --- > > (Updated Nov. 1, 2015, 6:13 p.m.) > > > Review request for KDE Frameworks, Albert Astals Cid, Alex Richardson, David > Faure, and Luigi Toscano. > > > Repository: kio > > > Description > --- > > Convert all io slave .protocol data to json and embed it. > Allows easier deployment of the slaves. > > > Diffs > - > > src/ioslaves/http/CMakeLists.txt 76a8e28 > src/ioslaves/help/main_ghelp.cpp 59c8558 > src/ioslaves/help/main.cpp 9939196 > src/ioslaves/help/help.protocol 1deefe5 > src/ioslaves/help/help.json PRE-CREATION > src/ioslaves/help/ghelp.protocol d2a642a > src/ioslaves/help/ghelp.json PRE-CREATION > src/ioslaves/help/CMakeLists.txt 867b59d > src/ioslaves/ftp/ftp.protocol 4c5f80c > src/ioslaves/ftp/ftp.json PRE-CREATION > src/ioslaves/ftp/ftp.cpp 382723a > src/ioslaves/ftp/CMakeLists.txt 04f5600 > src/ioslaves/file/file.protocol 523c0f5 > src/ioslaves/file/file.json PRE-CREATION > src/ioslaves/file/file.cpp 5ef1587 > src/ioslaves/file/CMakeLists.txt cb85cfb > autotests/kprotocolinfotest.cpp fa3ad38 > src/ioslaves/http/http.protocol 49e5dc5 > src/ioslaves/http/https.protocol c15d06f > src/ioslaves/http/webdav.protocol 05c977a > src/ioslaves/http/webdavs.protocol d5e4b2f > src/ioslaves/trash/CMakeLists.txt 05161cd > src/ioslaves/trash/kio_trash.cpp cb23169 > src/ioslaves/trash/trash.json PRE-CREATION > src/ioslaves/trash/trash.protocol 7430575 > > Diff: https://git.reviewboard.kde.org/r/125869/diff/ > > > Testing > --- > > Tests still work (one needed patching, as the exec line contains now the full > path). > > Correction: Somehow the ./autotests/jobtest test is unstable for me here, > sometimes it works, sometimes not :/ but even without this change. > > > Thanks, > > Christoph Cullmann > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
kdebugdialog5 doesn't respect ShowIconsOnPushButtons with the KDE platformthemeplugin
Hi, As stated in the subject, kdebugdialog5 doesn't respect the user's choice re: icons in buttons when using the platform plugin from KF5-frameworkintegration, even after forcing the hints to false in the frameworkintegration source. It does when using the native Cocoa style on OS X. Is this intentional? (I'm also seeing "QCoreApplication::arguments: Please instantiate the QApplication object first" just after starting the application.) R ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QSP patch/activator (Review Request 126125: [OS X] make KDE's trash use the OS X trash)
Alex Merry wrote: > I'm not sure what you mean by "incremental", though. All CMake variables > overwrite their previous values when you set them, so you have to > explicitly include the old value when you set them, and you can't really > do this from the command line. That's what I was getting at. If a feature, it's an annoying one that really doesn't play well with build systems where different components each may have something to add ... Gotta live with it, I guess. R. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KXmlGui Patched for Deployment
On 2015-11-29 08:57, Cristian Oneț wrote:
Hi,
I was just building some KDE apps (using frameworks) on OSX and
encountered the same problem for which we (me and Patrick von Reth)
created the QStandardPaths patch at Randa in 2014 [1]. The solution
you propose in this mail requires all applications that were
installing the rc file in '${KXMLGUI_INSTALL_DIR}/appname' to be
changed to have the rc in a resource file and call setXMLFile on
start. I'm not sure that all application developers will be aware that
this change is necessary. Couldn't this be solved by the ECM module
that provides KXMLGUI_INSTALL_DIR?
The KDEInstallDirs module literally just provides a standard set of
variables for projects to use or not as they see fit. Given how it's
used, it can't have any influence beyond that. ECM can't really help you
with the setXMLFile call anyway (although maybe KXMLGui can be changed
to always look in the resources as well as the QSP locations), but your
options for the resource file are:
* explicitly change to using a resouce-based installation in each
project
* add an ECM command that generates the resource file for you, and add
it to each project (probably no less work than the above)
* something horribly, horribly hacky
Another similar issue is the problem of setting
'NSHighResolutionCapable' to true in all gui applications. I see kate
solves this by using a custom MacOSXBundleInfo.plist.in file but this
approach is bad since again it requires all application developers to
be aware of these platform specific issues. This should have been
solved in ECM. Having all applications duplicate the same
MacOSXBundleInfo.plist.in is the best way to make sure that some of
the apps will fail to do it making them look blurry on highDPI and
giving KDE applications a bad name this way.
The problem is that the opt-in nature of highDPI support is there for a
reason - the application itself will probably need to do some work on
this front to make it play nicely.
That said, ECM can probably help with the plist generation. We already
have some minimal cross-platform setup stuff in
ECMMarkNonGuiExecutable[0], although this doesn't even quite cover every
gui vs non-gui option we want (there are things that need to be a GUI
executable on Windows, but not a bundle on Mac, for example). Having an
ECMCrossPlatformHelpers (or some such) module that deprecated
ECMMarkNonGuiExecutable and did some other setup magic with plists etc
could be useful. If anyone wants to gather requirements for it and put
something together that would allow developers to specify some basic
function information about a CMake executable target, go for it. I
imagine this information would be like:
* is it a user-facing application or a helper executable for something
else? (MACOS_BUNDLE vs not)
* does it have a GUI? (WIN32 vs not)
* does it support highDPI? (generate some MacOSXBundleInfo.plist magic)
[0]: http://api.kde.org/ecm/module/ECMMarkNonGuiExecutable.html
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QSP patch/activator (Review Request 126125: [OS X] make KDE's trash use the OS X trash)
On 2015-11-28 21:53, René J. V. Bertin wrote: BTW, not that it's already being used, but is CMAKE_EXE_LINKER_FLAGS_INIT incremental or does one have to accumulate all elements first and use a single - DCMAKE_EXE_LINKER_FLAGS_INIT=XX argument? CMAKE_EXE_LINKER_FLAGS_INIT is a bit special. You have to specify it on the first CMake run you do for a project (ie: before the CMakeCache.txt file has been created), and whatever you put in it will be added to whatever default value for CMAKE_EXE_LINKER_FLAGS that CMake comes up with (which I believe is just the contents of the LDFLAGS env var when compiling with Clang or GCC). After that, it will be ignored, and you'll want to modify CMAKE_EXE_LINKER_FLAGS directly. Note that what I said above only applies to setting this variable on the command line, not to setting it from within CMake code (when you'll just want to append to CMAKE_EXE_LINKER_FLAGS). I'm not sure what you mean by "incremental", though. All CMake variables overwrite their previous values when you set them, so you have to explicitly include the old value when you set them, and you can't really do this from the command line. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins-kde-ci: kio master stable-kf5-qt5 » Linux,gcc - Build # 165 - Unstable!
GENERAL INFO BUILD UNSTABLE Build URL: https://build.kde.org/job/kio%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/165/ Project: PLATFORM=Linux,compiler=gcc Date of build: Sun, 29 Nov 2015 08:58:48 + Build duration: 14 min CHANGE SET Revision b8c00386a900865eb5c2dea97f33aca5e478c959 by scripty: (SVN_SILENT made messages (.desktop file) - always resolve ours) change: edit src/new_file_templates/linkURL.desktop change: edit src/new_file_templates/Directory.desktop change: edit src/new_file_templates/linkProgram.desktop JUNIT RESULTS Name: (root) Failed: 1 test(s), Passed: 46 test(s), Skipped: 0 test(s), Total: 47 test(s)Failed: TestSuite.kiofilewidgets-knewfilemenutest COBERTURA RESULTS Cobertura Coverage Report PACKAGES 20/20 (100%)FILES 253/331 (76%)CLASSES 253/331 (76%)LINE 24926/50036 (50%)CONDITIONAL 13482/20775 (65%) By packages autotests FILES 61/61 (100%)CLASSES 61/61 (100%)LINE 7047/7264 (97%)CONDITIONAL 3860/7067 (55%) autotests.http FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 475/476 (100%)CONDITIONAL 166/272 (61%) autotests.kcookiejar FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 182/199 (91%)CONDITIONAL 60/90 (67%) src.core FILES 94/116 (81%)CLASSES 94/116 (81%)LINE 7451/14021 (53%)CONDITIONAL 3897/5403 (72%) src.core.kssl FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 3/6 (50%) src.filewidgets FILES 20/36 (56%)CLASSES 20/36 (56%)LINE 2291/7590 (30%)CONDITIONAL 916/1409 (65%) src.ioslaves.file FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 437/843 (52%)CONDITIONAL 320/465 (69%) src.ioslaves.http FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 750/3800 (20%)CONDITIONAL 547/678 (81%) src.ioslaves.http.kcookiejar FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 642/804 (80%)CONDITIONAL 602/758 (79%) src.ioslaves.trash FILES 7/9 (78%)CLASSES 7/9 (78%)LINE 718/1182 (61%)CONDITIONAL 373/515 (72%) src.ioslaves.trash.tests FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 690/768 (90%)CONDITIONAL 434/822 (53%) src.kioslave FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/26 (54%)CONDITIONAL 5/10 (50%) src.kntlm FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 302/388 (78%)CONDITIONAL 86/108 (80%) src.kpasswdserver FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 394/600 (66%)CONDITIONAL 289/416 (69%) src.kpasswdserver.autotests FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 280/285 (98%)CONDITIONAL 144/254 (57%) src.urifilters.fixhost FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 32/35 (91%)CONDITIONAL 42/52 (81%) src.urifilters.ikws FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 248/743 (33%)CONDITIONAL 147/194 (76%) src.urifilters.localdomain FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 20/27 (74%)CONDITIONAL 14/18 (78%) src.urifilters.shorturi FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 226/256 (88%)CONDITIONAL 292/358 (82%) src.widgets FILES 29/62 (47%)CLASSES 29/62 (47%)LINE 2692/10636 (25%)CONDITIONAL 1285/1880 (68%)___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KXmlGui Patched for Deployment
Hi,
I was just building some KDE apps (using frameworks) on OSX and
encountered the same problem for which we (me and Patrick von Reth)
created the QStandardPaths patch at Randa in 2014 [1]. The solution
you propose in this mail requires all applications that were
installing the rc file in '${KXMLGUI_INSTALL_DIR}/appname' to be
changed to have the rc in a resource file and call setXMLFile on
start. I'm not sure that all application developers will be aware that
this change is necessary. Couldn't this be solved by the ECM module
that provides KXMLGUI_INSTALL_DIR?
Another similar issue is the problem of setting
'NSHighResolutionCapable' to true in all gui applications. I see kate
solves this by using a custom MacOSXBundleInfo.plist.in file but this
approach is bad since again it requires all application developers to
be aware of these platform specific issues. This should have been
solved in ECM. Having all applications duplicate the same
MacOSXBundleInfo.plist.in is the best way to make sure that some of
the apps will fail to do it making them look blurry on highDPI and
giving KDE applications a bad name this way.
I'm CC'ing kde-frameworks-devel since this is related to the
discussion "Question about goal of Windows/Mac frameworks", I'm really
glad that discussion was started.
[1]
https://projects.kde.org/projects/kdesupport/emerge/repository/revisions/master/entry/portage/libs/qt5/qtbase/qtbase-20130714.patch
2015-10-12 11:06 GMT+03:00 Christoph Cullmann :
> Hi,
>
> kxmlgui should now be deployable on windows without any Qt patches.
>
> https://git.reviewboard.kde.org/r/125595/
>
> Applications just can put their ui files into :/kxmlgui5/... into resources.
> kxmlgui itself ships all its assets inside a resource compiled in and no
> longer needs any hacked
> standard paths.
>
> KTextEditor framework and Kate/KWrite applications are already patched to
> work that way.
>
> I will now work on making such a thingy possible for shipped KConfig files,
> too.
>
> https://git.reviewboard.kde.org/r/125598/
>
> Greetings
> Christoph
>
> --
> - Dr.-Ing. Christoph Cullmann -
> AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com
> Science Park 1 Tel: +49-681-38360-22
> 66123 Saarbrücken Fax: +49-681-38360-20
> GERMANYWWW: http://www.AbsInt.com
>
> Geschäftsführung: Dr.-Ing. Christian Ferdinand
> Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
> ___
> Kde-windows mailing list
> kde-wind...@kde.org
> https://mail.kde.org/mailman/listinfo/kde-windows
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
