---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121299/#review71540
---
src/netwm_def.h
It looks like there are more failing tests, and in a non-deterministic
manner. An example of a failing one is [1] while I've also seen all of them
succeeding, [2].
Are you guys sure that these tests are really doing the right thing and
that there are no failures when you run them a thousand
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121090/#review71545
---
Looks good. It's too much code for me to review properly; but
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121390/
---
Review request for KDE Frameworks, Qt KDE and Yichao Yu.
Repository:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121390/
---
(Updated Dec. 8, 2014, 2:38 p.m.)
Review request for KDE Frameworks, Qt
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121299/
---
(Updated Dez. 8, 2014, 1:40 nachm.)
Review request for KDE Frameworks,
On Sat, Dec 6, 2014 at 3:59 PM, David Faure fa...@kde.org wrote:
Here's the changelog I wrote for 5.5.0.
Please everyone remember to use CHANGELOG in your commits, with
a standalone description of the issue (i.e. which doesn't use the modified
filenames as implicit context).
I tried to
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121390/#review71553
---
this is wrong - please have a look at various frameworks on
On Dec. 8, 2014, 10:34 a.m., Kai Uwe Broulik wrote:
the autotest for NET::Supported is not extended for the new supported type
I'm still missing the extension of the autotest. In fact I'd expect that at
least one autotest is currently failing.
- Martin
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121090/
---
(Updated Pro. 8, 2014, 2:34 odp.)
Review request for KDE Frameworks,
On Dec. 8, 2014, 3:07 p.m., Martin Gräßlin wrote:
this is wrong - please have a look at various frameworks on how to do it
properly. In the end it should be:
#if HAVE_X11
// x11 specific stuff
#endif
obviously it also needs a runtime check:
if (QX11Info::isPlatformX11())
On Dez. 8, 2014, 9:34 vorm., Kai Uwe Broulik wrote:
the autotest for NET::Supported is not extended for the new supported type
Martin Gräßlin wrote:
I'm still missing the extension of the autotest. In fact I'd expect that
at least one autotest is currently failing.
Could you be more
On Dec. 8, 2014, 10:34 a.m., Kai Uwe Broulik wrote:
the autotest for NET::Supported is not extended for the new supported type
Martin Gräßlin wrote:
I'm still missing the extension of the autotest. In fact I'd expect that
at least one autotest is currently failing.
Kai Uwe Broulik
On Dec. 8, 2014, 3:07 p.m., Martin Gräßlin wrote:
this is wrong - please have a look at various frameworks on how to do it
properly. In the end it should be:
#if HAVE_X11
// x11 specific stuff
#endif
obviously it also needs a runtime check:
if (QX11Info::isPlatformX11())
Hi,
I would like to finally finish this. According to [1] I believe we satisfy all
conditions to become a framework. We also already have own bugzilla component
[2] and repository in reviewboard. There were also no objections except a
comment from David Edmunson regarding propertiesChanged()
On Dec. 8, 2014, 3:07 p.m., Martin Gräßlin wrote:
this is wrong - please have a look at various frameworks on how to do it
properly. In the end it should be:
#if HAVE_X11
// x11 specific stuff
#endif
obviously it also needs a runtime check:
if (QX11Info::isPlatformX11())
On Dez. 8, 2014, 2:07 nachm., Martin Gräßlin wrote:
this is wrong - please have a look at various frameworks on how to do it
properly. In the end it should be:
#if HAVE_X11
// x11 specific stuff
#endif
obviously it also needs a runtime check:
if (QX11Info::isPlatformX11())
On Dec. 8, 2014, 3:07 p.m., Martin Gräßlin wrote:
this is wrong - please have a look at various frameworks on how to do it
properly. In the end it should be:
#if HAVE_X11
// x11 specific stuff
#endif
obviously it also needs a runtime check:
if (QX11Info::isPlatformX11())
On Dec. 8, 2014, 3:07 p.m., Martin Gräßlin wrote:
this is wrong - please have a look at various frameworks on how to do it
properly. In the end it should be:
#if HAVE_X11
// x11 specific stuff
#endif
obviously it also needs a runtime check:
if (QX11Info::isPlatformX11())
On Dec. 8, 2014, 3:07 p.m., Martin Gräßlin wrote:
this is wrong - please have a look at various frameworks on how to do it
properly. In the end it should be:
#if HAVE_X11
// x11 specific stuff
#endif
obviously it also needs a runtime check:
if (QX11Info::isPlatformX11())
On Dec. 8, 2014, 3:07 p.m., Martin Gräßlin wrote:
this is wrong - please have a look at various frameworks on how to do it
properly. In the end it should be:
#if HAVE_X11
// x11 specific stuff
#endif
obviously it also needs a runtime check:
if (QX11Info::isPlatformX11())
On Dec. 8, 2014, 3:07 p.m., Martin Gräßlin wrote:
this is wrong - please have a look at various frameworks on how to do it
properly. In the end it should be:
#if HAVE_X11
// x11 specific stuff
#endif
obviously it also needs a runtime check:
if (QX11Info::isPlatformX11())
On Dez. 8, 2014, 2:07 nachm., Martin Gräßlin wrote:
this is wrong - please have a look at various frameworks on how to do it
properly. In the end it should be:
#if HAVE_X11
// x11 specific stuff
#endif
obviously it also needs a runtime check:
if (QX11Info::isPlatformX11())
On Nov. 27, 2014, 7:29 a.m., Christoph Cullmann wrote:
I actually would prefer no such hack in the public headers.
If that is just to make porting easier, you can use that locally as a patch
until the kdevplatform code is cleaned up.
I still don't get why you think this is a hack, or
2014-12-06 14:59 GMT+00:00 David Faure fa...@kde.org:
Here's the changelog I wrote for 5.5.0.
Please everyone remember to use CHANGELOG in your commits, with
a standalone description of the issue (i.e. which doesn't use the modified
filenames as implicit context).
I tried to grab what I
On Nov. 27, 2014, 7:29 a.m., Christoph Cullmann wrote:
I actually would prefer no such hack in the public headers.
If that is just to make porting easier, you can use that locally as a patch
until the kdevplatform code is cleaned up.
Milian Wolff wrote:
I still don't get why you
Hi,
I am soon about to finalise the first complete rebuild of KF5 on my OSX/CI
system
NOW INCLUDING ALL EXISTING TESTS !
Anyone interested in all those test results for FWs apps with test failures?
Greets,
Marko
___
On Dec. 8, 2014, 8:40 p.m., Albert Astals Cid wrote:
I don't think this makes sense at a framework level. If some application is
so special that really needs a special case, they can call setText over the
kaction themselves, otherwise we're going to end up havin 20 different Add
On des. 8, 2014, 8:40 p.m., Albert Astals Cid wrote:
I don't think this makes sense at a framework level. If some application is
so special that really needs a special case, they can call setText over the
kaction themselves, otherwise we're going to end up havin 20 different Add
On Dec. 8, 2014, 3:07 p.m., Martin Gräßlin wrote:
this is wrong - please have a look at various frameworks on how to do it
properly. In the end it should be:
#if HAVE_X11
// x11 specific stuff
#endif
obviously it also needs a runtime check:
if (QX11Info::isPlatformX11())
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121390/
---
(Updated Dec. 8, 2014, 10:59 p.m.)
Review request for KDE Frameworks, Qt
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121356/
---
(Updated des. 8, 2014, 10:39 p.m.)
Status
--
This change has been
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121397/
---
Review request for KDE Frameworks, David Edmundson and Martin Klapetek.
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121397/
---
(Updated des. 8, 2014, 10:42 p.m.)
Review request for KDE Frameworks,
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121397/#review71596
---
Ship it!
src/knotificationmanager.cpp
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121397/
---
(Updated Dec. 8, 2014, 10:52 p.m.)
Status
--
This change has been
https://git.reviewboard.kde.org/r/121094/
This change fails to compile on Windows, because the unit test has
ktexttohtml.cpp as a source file *and* it's linking to the kcoreaddons
library which obviously defines the same function. In addition,
ktexttohtml.h in this context is declaring the
2014-12-08 23:37 GMT-03:00 Nicolás Alvarez nicolas.alva...@gmail.com:
https://git.reviewboard.kde.org/r/121094/
This change fails to compile on Windows, because the unit test has
ktexttohtml.cpp as a source file *and* it's linking to the kcoreaddons
library which obviously defines the same
On Dec. 8, 2014, 3:40 p.m., Albert Astals Cid wrote:
I don't think this makes sense at a framework level. If some application is
so special that really needs a special case, they can call setText over the
kaction themselves, otherwise we're going to end up havin 20 different Add
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121401/
---
Review request for KDE Frameworks.
Repository: kcoreaddons
Description
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121400/
---
Review request for Build System and KDE Frameworks.
Repository:
41 matches
Mail list logo
