A Dissabte, 3 de setembre de 2011, Alexander Potashev vàreu escriure:
2011/9/2 Albert Astals Cid aa...@kde.org:
Personally i prefer things not to be released from kdereview.
Gilles Caulier (digiKam and KIPI-Plugins maintainer) told me that the
tarball for KIPI-Plugins 2.1.0 will probably be
2011/9/4 Albert Astals Cid aa...@kde.org:
Seems everyone was happy with review so move it to extragear? Anyway i prefer
things not to be released from playground either (yes i know lots of people do
it, that's why it is my personal opinion) so if you can not get it to be moved
or prefer to
2011/9/2 Albert Astals Cid aa...@kde.org:
Personally i prefer things not to be released from kdereview.
Gilles Caulier (digiKam and KIPI-Plugins maintainer) told me that the
tarball for KIPI-Plugins 2.1.0 will probably be created tomorrow.
Therefore I hope to release libkvkontakte also tomorrow.
A Divendres, 2 de setembre de 2011, Alexander Potashev vàreu escriure:
2011/8/29 Alexander Potashev aspotas...@gmail.com:
2011/8/26 Alexander Potashev aspotas...@gmail.com:
This argument wins. Just give me a couple of days to get to changing
all classes to data only in private class
A Divendres, 26 d'agost de 2011, Alexander Potashev vàreu escriure:
2011/8/26 David Faure fa...@kde.org:
A last argument, code is easier to maintain if it follows the same rules
everywhere. So in all public library code (Qt, kdelibs, and all other
public libs) we should do things the same
On Thursday 25 August 2011 19:23:10 Alexander Potashev wrote:
2011/8/25 Albert Astals Cid aa...@kde.org:
The point is that usually you do not know what the library will end up
doing and by using d-pointers everywhere you make it easier for
yourself to maintain binary compatibility in the
On Thursday 25 August 2011 19.23.10 Alexander Potashev wrote:
2011/8/25 Albert Astals Cid aa...@kde.org:
The point is that usually you do not know what the library will end up
doing and by using d-pointers everywhere you make it easier for
yourself to maintain binary compatibility in the
2011/8/9 Alexander Potashev aspotas...@gmail.com:
playground-libs/libkvkontakte moved to kdereview today. The next
target for this project is extragear/libs.
libkvkontakte has been in kdereview for more than two weeks already.
Is it OK to move it into extragear-libs now?
--
Alexander
A Dijous, 25 d'agost de 2011, Alexander Potashev vàreu escriure:
2011/8/9 Alexander Potashev aspotas...@gmail.com:
playground-libs/libkvkontakte moved to kdereview today. The next
target for this project is extragear/libs.
libkvkontakte has been in kdereview for more than two weeks
2011/8/25 Albert Astals Cid aa...@kde.org:
I thought you were going to get rid of the private members and use a d-pointer
instead?
What is the point of this? I think it will be OK to keep all class
members in the main (public) classes and use d-ptr only in case of
real necessity.
--
A Dijous, 25 d'agost de 2011, Alexander Potashev vàreu escriure:
2011/8/25 Albert Astals Cid aa...@kde.org:
I thought you were going to get rid of the private members and use a
d-pointer instead?
What is the point of this? I think it will be OK to keep all class
members in the main
2011/8/25 Albert Astals Cid aa...@kde.org:
The point is that usually you do not know what the library will end up doing
and by using d-pointers everywhere you make it easier for yourself to maintain
binary compatibility in the future.
But in the case that most classes won't grow in the future
2011/8/17 Thomas Zander zan...@kde.org:
Most C++ libraries use this, but I suggest to take a look at kdelibs for
inspiration.
Implementation of p-pointers not always the same in the whole kdelibs.
I preferred not to use neither Q_DECLARE_PRIVATE nor inheritance of
*Private classes (as described
On Wednesday 17 August 2011 09.24.31 Alexander Potashev wrote:
If I'll add just a forward declaration like class NoteInfoPrivate;
and a NoteInfoPrivate *p; into the NoteInfo class, will it be OK?
I guess you mean using a d-pointer, yes, that's the suggested way of
dealing with this kind of
2011/8/15 Albert Astals Cid aa...@kde.org:
A Dilluns, 15 d'agost de 2011, Alexander Potashev vàreu escriure:
How about adding a QMapQString, QVariant m_ext; to *Info classes,
so that I can store additional variables there? Most (but not all)
*Job classes are unlikely to be expanded later,
2011/8/17 Alexander Potashev aspotas...@gmail.com:
So, the NoteInfoPrivate class may not have any declaration (except for
the forward declaration) until it will be necessary, right?
There is Q_DECLARE_PRIVATE macro, interesting... Should I use it instead?
--
Alexander Potashev
2011/8/15 Albert Astals Cid aa...@kde.org:
You do not use d pointers in any of your classes thus maintaining Binary
Compatibility is going to be almost impossible if you need to expand them.
How about adding a QMapQString, QVariant m_ext; to *Info classes,
so that I can store additional
A Dilluns, 15 d'agost de 2011, Alexander Potashev vàreu escriure:
2011/8/15 Albert Astals Cid aa...@kde.org:
You do not use d pointers in any of your classes thus maintaining Binary
Compatibility is going to be almost impossible if you need to expand
them.
How about adding a QMapQString,
On Tuesday 09 August 2011 12:07:49 Alexander Potashev wrote:
Hi,
playground-libs/libkvkontakte moved to kdereview today. The next
target for this project is extragear/libs. This project is a
library for interaction with the most popular social network in
Russia VKontakte.ru (also available
2011/8/9 Christoph Feck christ...@maxiom.de:
It doesn't compile because asserts reference undeclared variables.
Attached patch shows where the errors are.
I've applied your patch to authenticationdialog.cpp and reworked error
reporting in allnoteslistjob.cpp and also in allmessageslistjob.cpp.
20 matches
Mail list logo
