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 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/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/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
14 matches
Mail list logo
