Hi,
There is an API/ABI break in kdelibs because a patch was committed to
4.5 but not 4.6.
The patch applies cleanly and is easily cherry-pickable. It is a break
of API freeze on 4.6 branch so I thought I'd mention that it's going to
happen.
However, this shouldn't have happened. What do
Aaron J. Seigo wrote:
On Tuesday, February 1, 2011, Harri Porten wrote:
On Tue, 1 Feb 2011, Aaron J. Seigo wrote:
we could end up with a new kdelibs module that contains just the core
stuff such as kdecore, kdeui, kio .. there could be requirements in
there about allowable dependencies
On Wednesday, 9 de February de 2011 20:08:31 Stephen Kelly wrote:
Hi,
K_GLOBAL_STATIC predates Q_GLOBAL_STATIC as far as I know, but with
Wrong. K_GLOBAL_STATIC is newer.
Q_GLOBAL_STATIC in Qt, should we port to that wherever K_GLOBAL_STATIC
features are not needed?
This is part of
Thiago Macieira wrote:
Q_GLOBAL_STATIC is not public API. Don't use it.
Would it be an option to make it public API by documenting it or is that out
of the question?
Christoph Feck wrote:
On Wednesday 09 February 2011 21:01:09 Stephen Kelly wrote:
KJob would be a Qt only library
? KJob is not a library, but a class in kdecore.
I should have been more clear I guess. When I wrote kjob there I meant a
library for asynchronous job execution containing
Alexander Neundorf wrote:
On Wednesday 09 February 2011, Stephen Kelly wrote:
Aaron J. Seigo wrote:
On Tuesday, February 1, 2011, Harri Porten wrote:
On Tue, 1 Feb 2011, Aaron J. Seigo wrote:
we could end up with a new kdelibs module that contains just the
core stuff such as kdecore,
On Wednesday 09 February 2011, Stephen Kelly wrote:
Alexander Neundorf wrote:
On Wednesday 09 February 2011, Stephen Kelly wrote:
Aaron J. Seigo wrote:
On Tuesday, February 1, 2011, Harri Porten wrote:
On Tue, 1 Feb 2011, Aaron J. Seigo wrote:
we could end up with a new kdelibs
(Creating a new thread)
Albert Astals Cid wrote:
A Dimecres, 9 de febrer de 2011, Stephen Kelly va escriure:
You seem to be
challenging the idea that less internal dependencies in kdelibs is a good
thing, but I think that's for a separate thread anyway.
Not sure if Christoph does, but i
Dawit A wrote:
On Wed, Feb 9, 2011 at 3:29 PM, Stephen Kelly steve...@gmail.com wrote:
Christoph Feck wrote:
On Wednesday 09 February 2011 21:01:09 Stephen Kelly wrote:
KJob would be a Qt only library
? KJob is not a library, but a class in kdecore.
I should have been more clear I guess.
A Dimecres, 9 de febrer de 2011, Stephen Kelly va escriure:
Albert Astals Cid wrote:
A Dimecres, 9 de febrer de 2011, Stephen Kelly va escriure:
(Creating a new thread)
Albert Astals Cid wrote:
A Dimecres, 9 de febrer de 2011, Stephen Kelly va escriure:
You seem to be
Am Mittwoch 09 Februar 2011, 19:59:34 schrieb Kevin Ottens:
On Wednesday 9 February 2011 19:21:26 Matthias Fuchs wrote:
Am Mittwoch 09 Februar 2011, 19:06:41 schrieb Kevin Ottens:
On Wednesday 9 February 2011 18:52:57 Matthias Fuchs wrote:
I wonder wether setting capabilties for KJobs
A Dimecres, 9 de febrer de 2011, todd rme va escriure:
On Wed, Feb 9, 2011 at 5:25 PM, Albert Astals Cid aa...@kde.org wrote:
Of course in an ideal world, QLineEdit would get all the KLineEdit
features, but that's not going to happen and we know it.
Albert
Why wouldn't it happen?
Albert Astals Cid wrote:
KLineEdit is integrated with KDE, QLineEdit is not, we can discuss this
all you want, but not using KLineEdit gives your users a poorer user
experience.
Ok. I'm not sure what that integration is and why it's not possible to have
a KLineEdit that doesn't depend on
Le Wednesday 09 February 2011, Stephen Kelly a écrit :
Thiago Macieira wrote:
Q_GLOBAL_STATIC is not public API. Don't use it.
Would it be an option to make it public API by documenting it or is that
out of the question?
I'm in favor of making it public API.
Make a merge request that
14 matches
Mail list logo
