Re: Plugin locator performance ballpark

On Sun, 8 Sep 2013, David Faure wrote: On Thursday 05 September 2013 01:04:52 Sebastian Kügler wrote: Reading just $PLUGINS/kf5, 52 plugins 21893.0 microsec (KServiceTypeTrader) 95835.0 microsec (Metadata) -- Reading metadata is 4-5 slower, ~100ms Reading $PLUGINS recursively, 127 plugins

Re: Plugin locator performance ballpark

On Sun, 8 Sep 2013, Boudewijn Rempt wrote: I like the directoryname idea, and actually, I'd go for a hierarchy: calligra/filter calligra/parts calligra/words calligra/krita/paintop calligra/krita/filter calligra/krita/extensions etcetera. that should limit the number of plugins per directory

Re: Review Request 113685: New KColorSchemeManager to support changing color scheme in app

for Krita. - Boudewijn Rempt On Nov. 6, 2013, 3:22 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113685

Re: Review Request 113685: New KColorSchemeManager to support changing color scheme in app

, Albert Astals Cid, Gilles Caulier, and Boudewijn Rempt. Repository: kdelibs Description --- This class is inspired by functionality offered by e.g. Krita and Digikam to allow the user to select a different color scheme for the application. This manager simplifies this task

Re: Review Request 113685: New KColorSchemeManager to support changing color scheme in app

On Monday 18 November 2013 Nov 09:17:07 Albert Astals Cid wrote: So you're saying Boud's and Christoph comments are wrong? My comment was meant to convey that color palettes have nothing to do with this patch -- they're a red herring here. -- Boudewijn Rempt http://www.valdyas.org, http

Re: Move KDED out of frameworks?

On Fri, 28 Mar 2014, Kevin Krammer wrote: The D-Bus session/user daemon is also something that needs to be treated in a platform specific way as a dependency. E.g. on Windows there could be a D-Bus installer that applications bundle and run if necessary, very much like Games bunlding an DirectX

Re: Kross in Porting Aids

As far as I can tell, having seen kross grow up a decade ago, kross basically has been unmaintained for, like, five years now. It's wonderful technology, though. On Tue, 27 May 2014, Andreas Cord-Landwehr wrote: Hi, I just noticed that Kross is marked as porting aid in KF5. Since I am

Re: KF5 Update Meeting Minutes 2014-w28

On Tue, 8 Jul 2014, John Layt wrote: We already have a link to the donations page buried deep in the About KDE dialog under the Support KDE tab where no-one ever sees it. A Help menu item for Donate to KDE... that pops up a dialog explaining why would be far more visible, but easily disabled

FindQt5.cmake?

Erm... I'm looking into Qt5 and KF5 atm, and I was wondering where I could find a FindQt5.cmake module, feeling rather lost. -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl ___ Kde-frameworks-devel mailing

Re: K_PLUGIN_FACTORY changes explained

On Sat, 31 Aug 2013, David Faure wrote: On Friday 30 August 2013 17:36:20 Boudewijn Rempt wrote: I'm also not sure whether this still works with current e-c-m, but first we set the plugin_install_dir: find_package(KF5 REQUIRED MODULE COMPONENTS CMake Compiler InstallDirs) set

Re: Review Request 122526: Add Debian path to search for qtwaylandscanner

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122526/#review75850 --- Ship it! Works for my testcase in any case! - Boudewijn

Re: Problem using Vc with CMake 3.0 and kf5

On Wed, 27 May 2015, Matthias Kretz wrote: Hi, On Monday 25 May 2015 11:50:35 Alex Merry wrote: The issue here is that Vc's macros implicitly assume that all compilation flags (including include paths) are done at the directory level (with include_directories() and setting CMAKE_CXX_FLAGS

Re: Problem using Vc with CMake 3.0 and kf5

ninja target when running Cmake? On May 23, 2015 5:06 AM, Aleix Pol aleix...@kde.org wrote: On Sat, May 23, 2015 at 11:51 AM, Boudewijn Rempt b...@valdyas.org wrote: Sorry for the extensive cross-posting in advance, please when replying, do a reply-all. Just so

Problem using Vc with CMake 3.0 and kf5

Sorry for the extensive cross-posting in advance, please when replying, do a reply-all. Just so everyone is on the same page: Vc is a template library that makes it easy to build vectorized code using a single source file. Krita uses Vc to optimize blending colors, creating masks and much

Re: Problem using Vc with CMake 3.0 and kf5

On Sat, 23 May 2015, Andrius da Costa Ribas wrote: I'm not sure if I understood the issue. If we need to pass the -I parameters to vc_compile_for_all_implementations, then something like https://git.reviewboard.kde.org/r/115110/diff/1/ might work. Well, it's not that, it's also not

Re: Problem using Vc with CMake 3.0 and kf5

On Mon, 25 May 2015, Alex Merry wrote: The issue here is that Vc's macros implicitly assume that all compilation flags (including include paths) are done at the directory level (with include_directories() and setting CMAKE_CXX_FLAGS etc), while CMake is moving towards doing things at the target

Re: Problem using Vc with CMake 3.0 and kf5

On Mon, 25 May 2015, Alex Merry wrote: include_directories($JOIN:${KDE4_INCLUDES}, -I) Well, I've tried that before, I think... It expands to this: /usr/bin/c++ -std=c++0x -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith

Re: Problem using Vc with CMake 3.0 and kf5

On Mon, 25 May 2015, Alex Merry wrote: Ah, yes. You may get somewhere with include_directories($JOIN:${KDE4_INCLUDES}, -I) Basically, this should replace all those semicolons in the generated output with -I, which should produce a correct command line. This is untested, though. Hm... No

Re: Problem using Vc with CMake 3.0 and kf5

On Mon, 25 May 2015, Stephen Kelly wrote: Boudewijn Rempt wrote: Yes, exactly. I've tried to find some documenation about this change, but apart from the rather unhelpful info in e.g. http://www.cmake.org/cmake/help/v3.1/manual/cmake-generator-expressions.7.html I couldn't find anything. I

Re: Problem using Vc with CMake 3.0 and kf5

:13 GMT+02:00 Boudewijn Rempt b...@valdyas.org: Weird, it worked for me: https://paste.kde.org/pmvwwhyqp -- in fact, the header file isn't used or needed in the example at all. I seem to be getting the same result as Alex (I think): https://paste.kde.org/pke2ztbok I'm a little

Re: Problem using Vc with CMake 3.0 and kf5

Weird, it worked for me: https://paste.kde.org/pmvwwhyqp -- in fact, the header file isn't used or needed in the example at all. On Mon, 25 May 2015, Alex Merry wrote: On Monday 25 May 2015 15:31:52 Boudewijn Rempt wrote: http://www.valdyas.org/~boud/vc-cmake-3.tgz is as minimal as I know

Re: Problem using Vc with CMake 3.0 and kf5

On Mon, 25 May 2015, Stephen Kelly wrote: Boudewijn Rempt wrote: Here's an SSCCE that demonstrates the problem with Vc 0.7.4: cmake_minimum_required(VERSION 3.0) project(VcTest) set(CMAKE_INCLUDE_CURRENT_DIR ON) find_package(Qt5Core REQUIRED) find_package(Vc REQUIRED) # Uncomment

Re: Problem using Vc with CMake 3.0 and kf5

Hm, to expand on that: if you're running into compile problems, well, then my problem would be solved. I've tested on kubuntu vivid, with cmake 3.0.2 and the 5.9.0 packages. On Mon, 25 May 2015, Boudewijn Rempt wrote: Weird, it worked for me: https://paste.kde.org/pmvwwhyqp -- in fact

Re: assert in kservicetypefactory.cpp

On Tue, 18 Aug 2015, David Faure wrote: On Tuesday 18 August 2015 08:49:10 Boudewijn Rempt wrote: I've attached the stderr log. Very strange, nothing about sycoca in there apart from the assert. I am going to need your help on this one. 0) do you have a file called ~/.cache/ksycoca5

Re: assert in kservicetypefactory.cpp

On Mon, 17 Aug 2015, David Faure wrote: On Monday 17 August 2015 10:05:05 Boudewijn Rempt wrote: This assert isn't triggered from our own code, but from kio's previewjob Ah OK. and either kdelibs4 didn't have the assert, or kio didn't need the cache. I'm pretty sure that both

Re: assert in kservicetypefactory.cpp

On Tue, 18 Aug 2015, David Faure wrote: On Tuesday 18 August 2015 10:45:00 Boudewijn Rempt wrote: if (!bus-isServiceRegistered(KDED_SERVICE_NAME)) { evaluates to false I'm confused by the possible double negation. Do you mean isServiceRegistered returns true? Er, I mean that the execution

assert in kservicetypefactory.cpp

Is it really necessary to assert here: krita(3310)/(default) unknown: ASSERT failure in KServiceTypeFactory::KServiceTypeFactory(): Could not open sycoca database, you must run kbuildsycoca first!, file /home/boud/kf5/src/frameworks/kservice/src/services/kservicetypefactory.cpp, line 38

Re: assert in kservicetypefactory.cpp

On Mon, 17 Aug 2015, David Faure wrote: On Monday 17 August 2015 09:37:52 Boudewijn Rempt wrote: Is it really necessary to assert here: krita(3310)/(default) unknown: ASSERT failure in KServiceTypeFactory::KServiceTypeFactory(): Could not open sycoca database, you must run kbuildsycoca first

Re: Review Request 125760: Allow local embedded themes, like Qt does a default search in :/icons

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125760/#review87338 --- Ship it! Ship It! - Boudewijn Rempt On Oct. 23, 2015, 5

Re: Question about goal of Windows/Mac frameworks

On Wed, 21 Oct 2015, Alexander Neundorf wrote: Maybe Qt could be shared ? No, no, no. Absolutely not. Every application on Windows should bring its own dependencies and all of them. Any attempt at anything else is a misguided deviation from the platform's way of working and will bring

Re: Question about goal of Windows/Mac frameworks

On Thu, 22 Oct 2015, Christoph Cullmann wrote: If such an approach seems reasonable, we could have some helper for this in a framework. Perhaps the "breeze" framework could even just provide such an rcc and a little lib to load it that can be used for people creating bundles/installers.

Review Request 125806: Fix build with -DDEFINE_NO_DEPRECATED=1

of 'appendTab' does not match any declaration in 'KMultiTabBar' int KMultiTabBar::appendTab(const QPixmap , int id, const QString ) ^ Diffs - src/kmultitabbar.cpp 2327748 Diff: https://git.reviewboard.kde.org/r/125806/diff/ Testing --- Thanks, Boudewijn Rempt

Re: Review Request 125806: Fix build with -DDEFINE_NO_DEPRECATED=1

marked as submitted. Review request for KDE Frameworks and Christoph Feck. Changes --- Submitted with commit 7d8b8417cbb6b8439b6689963758e2c20b091fac by Boudewijn Rempt to branch master. Repository: kwidgetsaddons Description --- With no-deprecated set, clang refuses to build

Re: Question about goal of Windows/Mac frameworks

Impressive! And cool to see another project using the cmake externals approach, I can copy a lot of it for Krita 3, I think. How are you handling icons? Bundling the breeze theme, or putting the icons in resource files? -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org On Thu

Re: Question about goal of Windows/Mac frameworks

On Thu, 22 Oct 2015, Christoph Cullmann wrote: Hi, Impressive! And cool to see another project using the cmake externals approach, I can copy a lot of it for Krita 3, I think. How are you handling icons? Bundling the breeze theme, or putting the icons in resource files? as I was lazy, I just

Re: Policy for Dependencies

On Tue, 13 Oct 2015, Albert Astals Cid wrote: I disagree, phonon and dbus are available on OSX and could be made to work so having a ECM_BUILD_FOR_OSX_APPBUNDLE that disables perfectly valid features doesn't make sense to me. But what if those things don't add any feature to a particularly

Re: Policy for Dependencies

On Tue, 13 Oct 2015, Christoph Cullmann wrote: I think we must accept, that on neither Windows nor Mac we will have all dependencies available and that for many applications not all features are needed. There is no "packagers" for that operating systems, you need to provide the stuff you use

Re: Policy for Dependencies

On Wed, 14 Oct 2015, Martin Klapetek wrote: Fwiw, KNotification+Phonon is used for KDialog sounds if frameworkintegration is present (iirc). So in theory, it should play a sound in Krita/Kate if you eg. close the window with unsaved content. If that adds anything to your app, I can't say.

Re: Policy for Dependencies

On Wed, 14 Oct 2015, Martin Klapetek wrote: But then it makes me wonder if you actually need KNotifications altogether. I'm not aware of anyone actually testing KNotificaitons on win/mac and I personally wouldn't guarantee it works at all on !linux. Same for Kate - do you actually need

Re: Policy for Dependencies

On Wed, 14 Oct 2015, Martin Klapetek wrote: I have to agree with Harald here though, I would also expect the frameworks to be bunch of pre-built dlls you just install system-wide and build on top of that, not create your own custom builds of everything, for every app with different features

Re: Policy for Dependencies

On Wed, 14 Oct 2015, Martin Klapetek wrote: On Wed, Oct 14, 2015 at 1:38 PM, Christoph Cullmann wrote: Given that lot opposition was here for a 5 lines change which does break nothing if packagers don't skrew up. Not to be disrespectful, but history has

Re: assert in kservicetypefactory.cpp

I've rebuilt frameworks this afternoon, but I'm struggling with calligra itself atm. I'll try it tomorrow morning. On Tue, 1 Sep 2015, David Faure wrote: On Wednesday 19 August 2015 09:08:35 Boudewijn Rempt wrote: Oh. I think you found a real bug :-) Does this patch help? Hm, doesn't look

Re: assert in kservicetypefactory.cpp

On Tue, 1 Sep 2015, David Faure wrote: On Wednesday 19 August 2015 09:08:35 Boudewijn Rempt wrote: Oh. I think you found a real bug :-) Does this patch help? Hm, doesn't look like it... How about the current kservice code, where I completely got rid of the kded dependency? Does that fix

kiconloader/qbuffer device not open puzzle?

I'm wondering if others see this as well and if there's something simple that I've missed that fixes it... For me, right now, with an up-to-date home-grown Qt 5.5 and kdesrc-build-built frameworks, icons don't get loaded once the cache exists. In bool

Re: kiconloader/qbuffer device not open puzzle?

On Thu, 17 Sep 2015, Boudewijn Rempt wrote: On Thu, 17 Sep 2015, David Faure wrote: Sounds like the pixmap loading reaches the end of the stream, maybe. Did you try moving out the cache, so it gets recreated? In order to find out if this is cache corruption or something else. Yes

Re: kiconloader/qbuffer device not open puzzle?

On Thu, 17 Sep 2015, David Faure wrote: Sounds like the pixmap loading reaches the end of the stream, maybe. Did you try moving out the cache, so it gets recreated? In order to find out if this is cache corruption or something else. Yes, removing the cache 'fixes' the issue -- the icon isn't

Re: kcrash when started from terminal

Do people porting to KF5 follow a guide for the cmakelists.txt part of it? That guide should mention this too ;) The only guide I know of is https://community.kde.org/Frameworks/Porting_Notes, which I've been sort of updating while porting calligra and krita. The build system part is pretty

Re: [OS X] adding a link module to all KF5 targets

On Wed, 23 Sep 2015, Nicolás Alvarez wrote: 2015-09-22 19:28 GMT-03:00 Albert Astals Cid : El Dimarts, 22 de setembre de 2015, a les 23:04:22, René J.V. Bertin va escriure: On Tuesday September 22 2015 22:35:40 Albert Astals Cid wrote: > Shouldn't KF5 work with those

Re: kiconloader/qbuffer device not open puzzle?

Aw, no... It doesn't seem to have helped me. On Sun, 20 Sep 2015, Boudewijn Rempt wrote: Okay! I'll update tomorrow morning :-) On Sun, 20 Sep 2015, David Faure wrote: On Thursday 17 September 2015 16:40:48 Boudewijn Rempt wrote: On Thu, 17 Sep 2015, David Faure wrote: Sounds like

Re: Review Request 126230: Make python, gettext and Qt5::QML optional for ki18n

::QML dependency). Diffs - CMakeLists.txt 59917fa cmake/KF5I18NMacros.cmake 53ba812 Diff: https://git.reviewboard.kde.org/r/126230/diff/ Testing --- Thanks, Boudewijn Rempt ___ Kde-frameworks-devel mailing list Kde-frameworks-devel

Re: Review Request 126230: Make python, gettext and Qt5::QML optional for ki18n

CMakeLists.txt 59917fa > cmake/KF5I18NMacros.cmake 53ba812 > > Diff: https://git.reviewboard.kde.org/r/126230/diff/ > > > Testing > --- > > > Thanks, > > Boudewijn Rempt > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Scope of framework integration plugin?

On Mon, 30 Nov 2015, David Edmundson wrote: On Mon, Nov 30, 2015 at 1:17 PM, Boudewijn Rempt <b...@valdyas.org> wrote: Sort of related question... Is this also the module that picks up the font hinting settings and applies it to KDE applications? I setup a gnome-only d

Re: Review Request 126230: Make python, gettext and Qt5::QML optional for ki18n

seful. When one wants to > > omit translations? > > Boudewijn Rempt wrote: > I _never_ install translations. Where would I install them from? Running > "make install" in ki18n doesn't install translations, as far as I can see? I > thought translations get installe

Re: Review Request 126230: Make python, gettext and Qt5::QML optional for ki18n

, Boudewijn Rempt ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 126675: Add .kra and .ora qimagio plugins

/ora.cpp PRE-CREATION src/imageformats/ora.desktop PRE-CREATION src/imageformats/ora.h PRE-CREATION src/imageformats/ora.json PRE-CREATION Diff: https://git.reviewboard.kde.org/r/126675/diff/ Testing --- Thanks, Boudewijn Rempt ___ Kde

Review Request 126674: Add a thumbnailer for kra/ora images

://git.reviewboard.kde.org/r/126674/diff/ Testing --- Thanks, Boudewijn Rempt ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126684: fix loading of RLE compressed PSD files

can confirm the fix is correct. - Boudewijn Rempt On Jan. 9, 2016, 9:58 a.m., Wolfgang Bauer wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.

Re: Review Request 126230: Make python, gettext and Qt5::QML optional for ki18n

the library to build an application we shouldn't waste electicity building the tests (and the Qt5::QML dependency). Diffs - CMakeLists.txt 59917fa cmake/KF5I18NMacros.cmake 53ba812 Diff: https://git.reviewboard.kde.org/r/126230/diff/ Testing --- Thanks, Boudewijn Rempt

Re: Scope of framework integration plugin?

On Mon, 30 Nov 2015, David Edmundson wrote: On Mon, Nov 30, 2015 at 1:17 PM, Boudewijn Rempt <b...@valdyas.org> wrote: Sort of related question... Is this also the module that picks up the font hinting settings and applies it to KDE applications? I setup a gnome-only d

Re: Scope of framework integration plugin?

-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126674: Add a thumbnailer for kra/ora images

marked as submitted. Review request for KDE Frameworks and David Faure. Changes --- Submitted with commit af884a8decd75b1f92ea8b9322c103e2dba60329 by Boudewijn Rempt to branch master. Repository: kio-extras Description --- KRA and ORA files are mostly the same internally, a zip

Re: kconfig question

Location? We'd have to be careful with that though, since it's >=5.5. I'm fine with 5.5 as a minimum for my own purposes :-). I just don't want to have to change a couple of hundred locations to explicitly pass AppConfigLocation. -- Boudewijn Rempt | http://www.krita.org,

kconfig question

those by adding two extra parameter (or writing a wrapper around kconfig, or something else...) I'd like to know why GenericConfigLocation is the default :-) -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org ___ Kde-frameworks-devel

Re: Review Request 126675: Add .kra and .ora qimagio plugins

ttps://git.reviewboard.kde.org/r/126675/#review91179 --- On Jan. 16, 2016, 9:55 a.m., Boudewijn Rempt wrote: > > --- > This is an automatically generated e-mail. To reply, v

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

ul (or just dumb) > > on Windows? > > Boudewijn Rempt wrote: > I would say: most applications do not need global accelerators, so making > kglobalaccel functional on windows is not really relevant, you wouldn't want > that dependency anyway because it doesn't add functionality

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

ul (or just dumb) > > on Windows? > > Boudewijn Rempt wrote: > I would say: most applications do not need global accelerators, so making > kglobalaccel functional on windows is not really relevant, you wouldn't want > that dependency anyway because it doesn't add functionality

Re: kconfig question

exactly what I need. I need Krita to behave differently on Windows than on Linux. On Windows, everything goes into Roaming\krita, on Linux it goes wherever it goes by default, even though that's harder to to explain to users. -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optiona

-integration point of view where I am trying to build nightly packages of Krita on Linux, Windows and OSX, every extra dependency makes the process longer, complicates my build environments and is a maintenance burden. -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: KCoreAddons qml plugins

-- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KCoreAddons qml plugins

is available. Huh, I might be missing something, but why are there conditionals if all the frameworks are marked as required? -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

ul (or just dumb) > > on Windows? > > Boudewijn Rempt wrote: > I would say: most applications do not need global accelerators, so making > kglobalaccel functional on windows is not really relevant, you wouldn't want > that dependency anyway because it doesn't add functionality

Re: kconfig question

. Sounds like it would be a good solution indeed! -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126675: Add .kra and .ora qimagio plugins

marked as submitted. Review request for KDE Frameworks and Alex Merry. Changes --- Submitted with commit 6934d5441778a09d157836a590236e3dc8d5a492 by Boudewijn Rempt to branch master. Repository: kimageformats Description --- These qimageio plugins originally come from krita

Re: Review Request 126675: Add .kra and .ora qimagio plugins

is found)? Fine with me. - Boudewijn --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126675/#review91821 --- On Jan. 27,

Re: Review Request 126675: Add .kra and .ora qimagio plugins

src/imageformats/kra.json PRE-CREATION src/imageformats/ora.cpp PRE-CREATION src/imageformats/ora.desktop PRE-CREATION src/imageformats/ora.h PRE-CREATION src/imageformats/ora.json PRE-CREATION Diff: https://git.reviewboard.kde.org/r/126675/diff/ Testing --- Thanks, Boudewijn

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

ke (07c882f) * src/kactioncollection.cpp (9c45725) * src/kkeysequencewidget.cpp (b2e2b6a) * src/kshortcuteditwidget.cpp (670d031) * src/kshortcutseditor.cpp (99dfb3d) * src/kshortcutseditoritem.cpp (461a90c) * src/kxmlguifactory.cpp (2767e69) View Diff -- Boudewijn Rempt | http:/

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

> On Jan. 26, 2016, 6:40 p.m., Aleix Pol Gonzalez wrote: > > Hi, > > I'm a bit afraid of all these ifndef. Do you think it would make sense to > > abstract out the KGlobalAccel usage? > > > > Otherwise, would it be possible to make KGlobalAccel useful (or just dumb) > > on Windows? I would

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

On Tue, 26 Jan 2016, Andre Heinecke wrote: Hi, On Tuesday 26 January 2016 19:50:13 Boudewijn Rempt wrote: Reminds me a bit of https://git.reviewboard.kde.org/r/125530/ :-) Uh, damn, I missed this :-( I guess the intention is the same. KXmlGui is pretty important to have a "KDE Applic

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

On Tue, 26 Jan 2016, Andre Heinecke wrote: Hi, On Tuesday 26 January 2016 20:47:34 Boudewijn Rempt wrote: On Tue, 26 Jan 2016, Andre Heinecke wrote: On Tuesday 26 January 2016 19:50:13 Boudewijn Rempt wrote: Reminds me a bit of https://git.reviewboard.kde.org/r/125530/ :-) In the end, I

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

ul (or just dumb) > > on Windows? > > Boudewijn Rempt wrote: > I would say: most applications do not need global accelerators, so making > kglobalaccel functional on windows is not really relevant, you wouldn't want > that dependency anyway because it doesn't add functionality

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

ul (or just dumb) > > on Windows? > > Boudewijn Rempt wrote: > I would say: most applications do not need global accelerators, so making > kglobalaccel functional on windows is not really relevant, you wouldn't want > that dependency anyway because it doesn't add functionality

Re: Review Request 126675: Add .kra and .ora qimagio plugins

/ora.cpp PRE-CREATION src/imageformats/ora.desktop PRE-CREATION src/imageformats/ora.h PRE-CREATION src/imageformats/ora.json PRE-CREATION Diff: https://git.reviewboard.kde.org/r/126675/diff/ Testing --- Thanks, Boudewijn Rempt ___ Kde

Re: kconfig question

, I can understand that application developers don't want to hardcode "krita/kritarc" everywhere... Yes... But given that I need to build kconfig on windows myself anyway, I guess I can just patch that. In the beginning I was just wondering wether this was the right behaviour. -- Boudewijn Rempt

Re: Finding local translations?

On Sat, 9 Apr 2016, Chusslove Illich wrote: [: Boudewijn Rempt :] However, KCatalog::catalogLocaleDir is run before the main runs, and uses QStandardPaths to find the location of the translations. That's before the XDG_DATA_DIRS environment variable is set. [: Alexander Potashev :] You can

Re: Finding local translations?

in KCatalog::catalogLocaleDir to find out more. Hm, yes, that shouldn't happen! I'll check that first! -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https

Re: Finding local translations?

On Sun, 10 Apr 2016, Boudewijn Rempt wrote: On Sun, 10 Apr 2016, David Faure wrote: On Saturday 09 April 2016 22:21:59 Chusslove Illich wrote: KCatalog::catalogLocaleDir should first execute when the first translation call happens Maybe krita has some global static with an i18n() call

Finding local translations?

); KLocalizedString::setLanguages(QStringList() << locale.bcp47Name()); And that also didn't work. See also https://quickgit.kde.org/?p=krita.git=commit=5015920f2b24d63b04c82cbf69c674de06ab8abc Is there any way to make this work? -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org ___

karchive and QSaveFile (fwd)

now wondering whether to hack QSaveFile's close() to just not abort, or add inherits("QSaveFile") checks all over KArchive -- or whether there's a third, better option that I've missed... -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: karchive and QSaveFile (fwd)

On Sat, 1 Apr 2017, David Faure wrote: > > Oh. > > Yes I think a qobject_cast(device) might be necessary in > KArchive, in order to call commit() rather than close(). > That would work, right? > > Feel like adding a unittest for this? Sure, I'll take a look tomorr

Re: Python bindings using cppyy (was: An update on Python bindings)

rm is basically Autodesk telling the rest of the industry what to use, including their weird patchset for Qt... > So no, Python 2 is not dead. Not by a long shot. For VFX, it will be dead in 2019. See http://www.vfxplatform.com/ -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

D13792: Remove unused include

This revision was automatically updated to reflect the committed changes. Closed by commit R237:fa20aaadecf9: Remove unused include (authored by rempt). REPOSITORY R237 KConfig CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D13792?vs=36873=36935 REVISION DETAIL

D13792: Remove unused include

rempt created this revision. rempt added a reviewer: Frameworks. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: kde-frameworks-devel. rempt requested review of this revision. REVISION SUMMARY While trying to figure out how to make kconfig work

D17040: Make FindExiv2.cmake work with exiv 0.27.

rempt added a comment. Hm... I guess this would be good to have in Krita, too, which also has a findExiv2.cmake REPOSITORY R260 Gwenview REVISION DETAIL https://phabricator.kde.org/D17040 To: cgiboudeaux, kde-buildsystem, kde-frameworks-devel Cc: rempt, clintmoyer, tdarboux, huoni,

D17044: Add FindExiv2.cmake to ECM

rempt added a comment. Wow... REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D17044 To: cgiboudeaux, apol, dfaure Cc: rempt, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D22577: Remove unused pnm.desktop file

rempt created this revision. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. rempt requested review of this revision. REVISION SUMMARY Looks like this file isn't used, so let's remove it. REPOSITORY R287 KImageFormats REVISION DETAIL

D25119: KF5::BreezeIcons shared library to have all breeze/breeze-dark icons and default to breeze icons set

rempt added a comment. It sounds like it would be something very useful and easy to use. Right now, we package all icons Krita uses in rc files that are compiled in as well. Also, our icon loading has kind of evolved and we've got a bit of code for switching between dark and light icons