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 ours
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
https://phabricator
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
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, muhl
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&id=36935
REVISION DETAIL
https://phabricato
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 with
And the VFX Refernece Platform 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
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 t
nce
in KoStore.
But that's a hack, and I'm 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
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 in
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 :]
Yo
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
ages(QStringList() << "en);
KLocalizedString::setLanguages(QStringList() << locale.bcp47Name());
And that also didn't work.
See also
https://quickgit.kde.org/?p=krita.git&a=commit&h=5015920f2b24d63b04c82cbf69c674de06ab8abc
Is there any way to make this work?
--
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, but
E-CREATION
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,
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,
useful (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
rk 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@kd
pt/AppImages/master/recipes/krita/Recipe
--
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
Krita.
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
personally, from a continuous-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.kri
Yes, but that's 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.or
useful (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
rmats/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
__
t I guess that's my
"library developer" point of view, 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
beginni
useful (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
useful (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
useful (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
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
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
> 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 sa
rc/CMakeLists.txt (58f0c7a)
* src/config-xmlgui.h.cmake (07c882f)
* src/kactioncollection.cpp (9c45725)
* src/kkeysequencewidget.cpp (b2e2b6a)
* src/kshortcuteditwidget.cpp (670d031)
* src/kshortcutseditor.cpp (99dfb3d)
* src/kshortcutseditoritem.cpp (461a90c)
* src/kxmlguifactory.cp
, visit:
https://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. T
or Krita. Maybe some way to use
AppConfigLocation? 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 pa
rt adapting all 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
___
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
RLE code I 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.review
rmats/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
__
https://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
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
useful. 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 in
On Mon, 30 Nov 2015, David Edmundson wrote:
On Mon, Nov 30, 2015 at 1:17 PM, Boudewijn Rempt 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 dev env
to see
what
useful. 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 in
>
> 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
-
Thanks,
Boudewijn Rempt
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
e Qt5::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-
On Mon, 30 Nov 2015, David Edmundson wrote:
On Mon, Nov 30, 2015 at 1:17 PM, Boudewijn Rempt 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 dev env
to see
what
on framework.
maybe we need a dedicated kstyle framework?
- platformtheme: Plasma integration. There I agree.
yep, that's what I actually was thinking about. All the defaults for in Plasma
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks
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
wboard.kde.org/r/125806/diff/
Testing
---
Thanks,
Boudewijn Rempt
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
---
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
On Fri, 23 Oct 2015, Jaroslaw Staniek wrote:
Actually let's look as a popular ported standalone app: GTK/GNOME's
help-browser that GIMP uses on Windows is the same as on Linux but I
don't see it using dbus (but still webkitgtk is used). Moreover if
someone caring for UX reads this: KDE's app hel
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.
Yes,
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
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
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
nothin
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
comb
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 proven that the assumptio
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 KNotifi
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.
^Th
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 ap
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 y
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 bare
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 sandboxing? I'd expect tha
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:
Sound
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 the pixmap loading reaches the end of the stream, maybe.
Did you try moving out the cache,
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
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
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 KIconLoaderPrivate::findCachedPixmapWithPath(
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 tha
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?
H
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
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 ?
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 prett
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
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
A
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 etc
ik wrote:
2015-05-25 16:13 GMT+02:00 Boudewijn Rempt :
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
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)
# Unco
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
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
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 a
On Mon, 25 May 2015, Alex Merry wrote:
include_directories("$")
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 -Wundef
-Wnon-virtual-dtor -
On Mon, 25 May 2015, Alex Merry wrote:
Ah, yes. You may get somewhere with
include_directories($)
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 luck here. This outputs an
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
o generate ninja target when running Cmake?
On May 23, 2015 5:06 AM, "Aleix Pol" wrote:
On Sat, May 23, 2015 at 11:51 AM, Boudewijn Rempt
wrote:
> Sorry for the extensive cross-posting in advance, please when replying,
do a
> reply-all.
>
>
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 more
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 windows
On Wed, 15 Apr 2015, Scarlett Clark wrote:
calligra - All - compile fail.
One way to make it build would be to remove the Vc dependency. We've still
not figured out a way to make Vc's handling of INCLUDE_DIRECTORIES work
with the new kf5 way of creating include directories -- see my mail to
---
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
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 disab
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
pon
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
On Fri, 28 Mar 2014, Kevin Krammer wrote:
D-Bus does run on most platforms, at least on desktop.
There was a thread on the Qt development list a short while ago which
discussed enabling QtDBus by default in Windows and Mac builds.
It might 'run' -- but I still wouldn't want to distribute any a
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
/r/113685/#review43557
---
On Nov. 12, 2013, 8:48 a.m., Martin Gräßlin wrote:
>
> -------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113685/
> --
d 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
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 dire
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
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
1 - 100 of 103 matches
Mail list logo
