Dirk Mueller wrote:
On Tuesday 05 June 2012, Albert Astals Cid wrote:
On May 19, Dawit Alemayehu commited a change that uses
QSslConfiguration::testSslOption that is only available in Qt 4.8
This means that both kdelibs 4.8.4 and kdelibs 4.9 now depend in Qt 4.8
instead Qt 4.7
Hi
Alexander Neundorf wrote:
Ah, right.
Can you put a copy of FindLibLZMA.cmake into tier1/karchive/cmake/ ?
(it will be in cmake 2.8.9)
Then we don't need the CMAKE_MODULE_PATH from kdelibs anymore, and
karchive is more standalone.
Or we can bump the dependency to 2.8.9 when the RC 1 comes
of the cmake generate
export header stuff in frameworks and use the new macro in the copy. The copy
can be removed when we depend on a later version of CMake.
- Stephen Kelly
On July 5, 2012, 1:09 p.m., Patrick Spendrin wrote
David Faure wrote:
If we (=someone) make a frameworks branch for kactivities, it should be
quite simple to port that away from kdecore (I suppose it was mostly using
KPluginLoader, which has now moved to the kservice framework). So this
might just be a matter of updating a few CMakeLists.txt
Alexander Neundorf wrote:
On Monday 01 October 2012, David Faure wrote:
On Monday 01 October 2012 09:53:22 Stephen Kelly wrote:
Instead, I say we should do a 'pain free' update to 2.8.7 now, and an
update to 2.8.11 later.
Yes.
I disagree.
If we upgrade now, I want to have at least
Alexander Neundorf wrote:
On Monday 01 October 2012, David Faure wrote:
On Monday 01 October 2012 09:53:22 Stephen Kelly wrote:
Instead, I say we should do a 'pain free' update to 2.8.7 now, and an
update to 2.8.11 later.
Yes.
I disagree.
If we upgrade now, I want to have at least
Christoph Feck wrote:
Hi,
my git foo is limited, but if I interpret http://ompldr.org/vZzZxaw
correctly, then somehow master got merged into KDE/4.9 branch,
meaning, for example, that Alex's commits to depend on cmake 2.8.8 are
now in KDE/4.9 branch.
I suggest to not to commit to
Christoph Feck wrote:
On Sunday 11 November 2012 12:00:05 Pino Toscano wrote:
Hi,
somehow the master branch of kde-workspace has been merged in the
KDE/4.9 branch, with obvious consequences.
Can anyone please fix this mess?
Thanks,
Uh oh, I think I did git reset origin/HEAD --hard in
Kevin Ottens wrote:
We should push to use the class name only includes I think.
I agree.
We have a buildsystem that is good enough that we can specify the
directories to look for the 'class name' headers in, and it is in the
buildsystem that that stuff belongs.
See the kinds of practical
Thiago Macieira wrote:
On sábado, 29 de dezembro de 2012 22.58.49, Kevin Ottens wrote:
On Saturday 29 December 2012 11:06:30 David Faure wrote:
Well, for frameworks that intend to be as close to Qt as possible
they should do the same (for the convenience of developers who don't
use
Sebastian Kügler wrote:
On Sunday, February 10, 2013 14:33:49 Thiago Macieira wrote:
On domingo, 10 de fevereiro de 2013 21.22.05, Sebastian Kügler wrote:
Apparently not. I've looked at where the example imports from the Qt
codebase install these things, and that is indeed $PREFIX/qml, not
Sebastian Kügler wrote:
What do you need it for, exactly?
To find out where Qt will look for QtQuick2 imports (that's
$ARCHDATADIR/qml, defaulting to $PREFIX/qml, which leads to /usr/qml).
I'd like to be able to install Plasma QtQuick2 imports into a path where
they'll actually be found,
On March 11, 2013, 5:19 a.m., Andrea Scarpino wrote:
I was quite clear: qmake must point by default to Qt 4 if Qt 4 present.
While qtchooser sounds like a great solution to handle this, it only adds
more confusion from a packager view: we cannot have N differents
configurations for qt
think that
binaries with specific version takes precedence, don't they?
Stephen Kelly wrote:
No, you also need to account for self-built Qt, which will also result in
a binary called 'qmake'.
http://thread.gmane.org/gmane.comp.kde.devel.general/65619/focus=65623
Andrea
Alexander Neundorf wrote:
On Thursday 16 May 2013, Stephen Kelly wrote:
Kevin Ottens wrote:
Beside that, I would like if we could do a release of
extra-cmake-modules as soon as possible, so other projects, KDE and
non-KDE can start to make use of it and people can start to
contribute
Ben Cooksley wrote:
Hi Alex,
Can someone more familiar with the CMake community please inform them
of this regression?
http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/46742/focus=46776
David Faure wrote:
On Monday 20 May 2013 11:53:18 Alexander Neundorf wrote:
there was a review request for a find-module for libusb1 here a few days
ago, which we have already in e-c-m, but he can't use it because it is
not released
Could we maybe release a first version of ECM with only
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/58/#review34939
---
Ship it!
Ship It!
- Stephen Kelly
On June 21, 2013, 10:45
Kevin Ottens wrote:
Once the splitting will be done I'm not so sure it's better than using
directly the namespaced target names. The reason being that variables are
really a pain with cmake... I mean if you mistakenly use a variable name
which doesn't exist it's just expanded to nothing.
Kevin Ottens wrote:
So, if this target/variable task is deferred until CMake 2.8.13 can be
used, the variables don't have to be used even in an intermediate state.
I see, but when is 2.8.13 supposed to be released? I'd rather have us move
forward.
2.8.12 will be released in a few weeks.
of them use this
class.
kdeui/itemviews/klinkitemselectionmodel.cpp
http://git.reviewboard.kde.org/r/111953/#comment27688
Excess whitespace.
- Stephen Kelly
On Aug. 8, 2013, 8:15 p.m., Aurélien Gâteau wrote
:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/111953/
---
(Updated Aug. 14, 2013, 7:30 a.m.)
Review request for kdelibs, Michael Bohlender and Stephen Kelly.
Description
Alexander Neundorf wrote:
It looks like it is related to using imported targets in try_compile():
-- Enabling c++0x support for unordered map
CMake Error at cmTryCompileExec236800853Targets.cmake:96 (add_library):
add_library cannot create imported target Qt4::QtGui because another
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112756/#review40705
---
Ship it!
Ship It!
- Stephen Kelly
On Sept. 16, 2013, 1:56
Sebastian Kügler wrote:
We're planning to merge the frameworks-scratch branch of kde-workspace
into master next Monday.
I tried building the branch. It requires qimageblitz, which I didn't see a
Qt 5 version for, and soprano which has a non-building qt5_port branch.
Do you have local working
/plasma/CMakeLists.txt
http://git.reviewboard.kde.org/r/113139/#comment30269
The if-else shouldn't be needed. INSTALL_INTERFACE should already check if
${INCLUDE_INSTALL_DIR} is absolute.
- Stephen Kelly
On Oct. 7, 2013, 8:13 a.m., Ben Cooksley wrote
as it seems camelcase headers are
installed by KF5::plasma into include/KDE/Plasma/
Odd. I tried to add this dir, but seem to have hit a bug I'll look into. Patch
looks good for now I think, thanks!
- Stephen Kelly
On Oct. 7, 2013, 8:13 a.m., Ben Cooksley wrote
On Oct. 7, 2013, 9:35 a.m., Stephen Kelly wrote:
src/plasma/CMakeLists.txt, line 173
http://git.reviewboard.kde.org/r/113139/diff/1/?file=199605#file199605line173
The if-else shouldn't be needed. INSTALL_INTERFACE should already check
if ${INCLUDE_INSTALL_DIR} is absolute.
Ben
://git.reviewboard.kde.org/r/113503/#comment30904
Indent.
- Stephen Kelly
On Oct. 30, 2013, 10:08 a.m., Sune Vuorela wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113503
Alexander Neundorf wrote:
Hi,
for very happy personal reasons (since Tuesday, named David :-) )
Awesome, congratulations!
Steve.
Harald Sitter wrote:
xnox was nice enough to look into this in detail and identified the
problem as having a much smaller scope than I had originally thought.
1) What is the problem?
2) Why does the package creation result in broken cmake files generated from
the Qt tarball?
Thanks,
On 12/19/2013 07:45 PM, Dimitri John Ledkov wrote:
2) Why does the package creation result in broken cmake files generated
from the Qt tarball?
The package creation does not result in broken cmake files generated
from the Qt tarball.
Great.
It's just there is no clean way to override
On 12/19/2013 07:45 PM, Dimitri John Ledkov wrote:
I am also not sure yet, if
a cross-moc is required or whether a native moc binary can be re-used.
It's one of the open questions that I still have, and need to
investigate the actual code generator / code generated.
Even if the code generated
On 03/16/2015 05:28 PM, Ivan Čukić wrote:
From www.gitorious.org
System notice: Gitorious is being acquired by GitLab and
gitorious.org will shut down end of May. Please import your
repositories to
We still have a few projects on there. One notable being Grantlee (at
least, my kdesrc-build
On 03/16/2015 05:28 PM, Ivan Čukić wrote:
From www.gitorious.org
System notice: Gitorious is being acquired by GitLab and
gitorious.org will shut down end of May. Please import your
repositories to
We still have a few projects on there. One notable being Grantlee (at
least, my kdesrc-build
wrote:
On 28/03/15 03:48, Alex Merry wrote:
On Wednesday 25 March 2015 22:35:24 Stephen Kelly wrote:
Hello,
ECM release numbers are in sync with KF5 release numbers, except for the
major component.
This means that if you want to build the 5.x.y release you have to download
the 1.x.y
Lisandro Damián Nicanor Pérez Meyer wrote:
Fair enough. One of them starts in [0], but there was another thread in
which even Lars participated. So far I haven't been able to find it, I'll
keep trying.
Found the other one!
FYI, if you provide a gmane link, you provide the whole thread:
On Aug. 19, 2015, 6:03 p.m., Jeremy Whiting wrote:
Ship It!
Don't ship it :).
- Stephen
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124824/#review84061
to build? Add cmake_minimum_required(VERSION 2.8.9)
there.
- Stephen Kelly
On Aug. 19, 2015, 5:41 p.m., René J.V. Bertin wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124824
On Aug. 19, 2015, 6:06 p.m., Stephen Kelly wrote:
This patch is not correct.
What repo were you trying to build? Add cmake_minimum_required(VERSION
2.8.9) there.
Stephen Kelly wrote:
Why did this review go quiet? Did you pull and realize that line was
already
Albert Astals Cid wrote:
> So my suggestion would be renaming pykde5.git to pykf5.git, and that means
> *only* KDE Frameworks 5 bindings would go in there, any other repo that
> wants to provide python bindings (say okular, marble or krita) should do
> somewhere else, ideally their own repo so
Albert Astals Cid wrote:
> El divendres, 8 d’abril de 2016, a les 0:29:57 CEST, Stephen Kelly va
> escriure:
>> Albert Astals Cid wrote:
>> > So my suggestion would be renaming pykde5.git to pykf5.git, and that
>> > means *only* KDE Frameworks 5 bindings would go
Dominik Haumann wrote:
> I still see QStringLiteral fixes from time to time on the commit
> mailing list. Given MSVC 2015 Community Edition is available
> just like v2013, and it seems to work I believe that committing
> such fixes does not make sense, in fact, it often makes code
> worse.
If
Hello,
I have been developing Grantlee for over 10 years with contributions
from a community of others mostly connected with KDE.
https://github.com/steveire/grantlee
I have not been able to maintain a reasonable release cadence of
Grantlee in the last few years (last release 3 years
On 08/12/2019 10:12, laurent Montel wrote:
Le dimanche 8 décembre 2019, 10:52:19 CET Volker Krause a écrit :
Hi,
very happy to see Grantlee "coming home" :)
Technically I think it's largely in line with Frameworks requirements
already, and it has been reliably powering e.g. KMail's message
On 21/12/2019 21:33, Volker Krause wrote:
* Attracting external components and having them opt to move under the
Frameworks umbrella is a sign that we are doing things right IMHO. So let's
make this easy for people and avoid scaring off their users by forcing a
larger migration on them when
On 21/12/2019 19:12, Friedrich W. H. Kossebau wrote:
Am Samstag, 21. Dezember 2019, 13:03:17 CET schrieb Stephen Kelly:
Great, Grantlee is now available at g...@git.kde.org:grantlee.git.
I've pushed a few commits to make it depend on ECM etc.
Once the review period is finished it can
On 21/12/2019 23:55, Friedrich W. H. Kossebau wrote:
Perhaps joining the "Release Service" (formerly known as "KDE Applications")
is a better place then, it also contains a set of libraries already.
That would serve the purpose of having releases happening regularly.
The goals of making
On 28/12/2019 23:30, Friedrich W. H. Kossebau wrote:
Why are you proposing to do a step back instead to the old state, which
everyone including you considered not that satisfying?
Because it's a temporary situation. We still have a way forward in KF6
(which will open in a few months).
On 30/12/2019 10:55, Christoph Cullmann wrote:
Hi,
With my KTextEditor hat on: KF6:TextDocument implies somehow a link
to QTextDocument or KF6:TextEditor, which both is incorrect, right?
QTextDocument is exactly what it's about, which makes the name
KF6::TextDocument fully appropriate and
On 30/12/2019 08:55, Dominik Haumann wrote:
Hi,
Stephen Kelly mailto:steve...@gmail.com>> schrieb
am So., 29. Dez. 2019, 15:03:
On 28/12/2019 23:30, Friedrich W. H. Kossebau wrote:
> Why are you proposing to do a step back instead to the old
state, which
&
On 22/12/2019 16:08, Stephen Kelly wrote:
On 21/12/2019 23:55, Friedrich W. H. Kossebau wrote:
Perhaps joining the "Release Service" (formerly known as "KDE
Applications")
is a better place then, it also contains a set of libraries already.
That would serve the purpos
On 26/02/2022 10:38, Volker Krause wrote:
On Sonntag, 20. Februar 2022 16:02:59 CET Stephen Kelly wrote:
Hello,
The Qt 5 based Grantlee libraries were depended on by some KDE applications.
For Qt 6, I've created a separate repo for KTextTemplate for one of the
Grantlee libraries. The other
Hello,
The Qt 5 based Grantlee libraries were depended on by some KDE applications.
For Qt 6, I've created a separate repo for KTextTemplate for one of the
Grantlee libraries. The other library is separate and can be dealt with
separately.
Currently the code lives here:
On 05/03/2022 18:16, Ben Cooksley wrote:
On Sun, Mar 6, 2022 at 6:00 AM Stephen Kelly wrote:
On 26/02/2022 10:38, Volker Krause wrote:
> On Sonntag, 20. Februar 2022 16:02:59 CET Stephen Kelly wrote:
>> Hello,
>>
>> The Qt 5 based Grantlee li
101 - 155 of 155 matches
Mail list logo