2011/9/4 Albert Astals Cid :
> 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 stay in kdere
2011/9/4 Albert Astals Cid :
> 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 stay in kdere
A Dissabte, 3 de setembre de 2011, Alexander Potashev vàreu escriure:
> 2011/9/2 Albert Astals Cid :
> > 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
2011/9/2 Albert Astals Cid :
> 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. Should now
t
A Divendres, 2 de setembre de 2011, Alexander Potashev vàreu escriure:
> 2011/8/29 Alexander Potashev :
> > 2011/8/26 Alexander Potashev :
> >> This argument wins. Just give me a couple of days to get to changing
> >> all classes to "data only in private class" strategy.
> >
> > Done.
>
> Is ever
2011/8/29 Alexander Potashev :
> 2011/8/26 Alexander Potashev :
>> This argument wins. Just give me a couple of days to get to changing
>> all classes to "data only in private class" strategy.
>
> Done.
Is everything OK now to move into extragear/libs? Or I can release
libkvkontakte from kdereview
2011/8/26 Alexander Potashev :
> This argument wins. Just give me a couple of days to get to changing
> all classes to "data only in private class" strategy.
Done.
--
Alexander Potashev
2011/8/29 Albert Astals Cid :
> What's special in those classes?
Well, nothing, nevermind ;)
They are just much simpler than the *Job classes.
--
Alexander Potashev
A Divendres, 26 d'agost de 2011, Alexander Potashev vàreu escriure:
> 2011/8/26 David Faure :
> > 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 way, t
2011/8/26 David Faure :
> 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 way, to ease maintainance.
This argument wins. Just give me a couple of days to g
On Thursday 25 August 2011 19.23.10 Alexander Potashev wrote:
> 2011/8/25 Albert Astals Cid :
> > 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.
>
On Thursday 25 August 2011 19:23:10 Alexander Potashev wrote:
> 2011/8/25 Albert Astals Cid :
> > 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.
>
2011/8/25 Albert Astals Cid :
> 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 by using my
A Dijous, 25 d'agost de 2011, Alexander Potashev vàreu escriure:
> 2011/8/25 Albert Astals Cid :
> > 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") c
2011/8/25 Albert Astals Cid :
> 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.
--
Alexander Potashev
A Dijous, 25 d'agost de 2011, Alexander Potashev vàreu escriure:
> 2011/8/9 Alexander Potashev :
> > 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
2011/8/9 Alexander Potashev :
> 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 Potashev
2011/8/17 Thomas Zander :
> 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 at
http://te
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
2011/8/17 Alexander Potashev :
> 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 :
> A Dilluns, 15 d'agost de 2011, Alexander Potashev vàreu escriure:
>> How about adding a "QMap 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, because they perform
>> ve
A Dilluns, 15 d'agost de 2011, Alexander Potashev vàreu escriure:
> 2011/8/15 Albert Astals Cid :
> > 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 "QMap m_ext;" to *In
2011/8/15 Albert Astals Cid :
> 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 "QMap m_ext;" to *Info classes,
so that I can store additional variables there? Most (but not all
A Dimarts, 9 d'agost de 2011, Alexander Potashev vàreu escriure:
> 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 a
2011/8/9 Christoph Feck :
> 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.
Thanks!
--
Alex
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 avail
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 at vk.com) using its public API
documented at http://vkontakte.ru/pa
27 matches
Mail list logo
