<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 19, 2015 at 8:20 PM, Elv1313 . <span dir="ltr"><<a href="mailto:elv1313@gmail.com" target="_blank">elv1313@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ok,<br>
<br>
I pushed some changes to:<br>
<br>
* clean the BookmarkModel d-pointer issues<br>
* rename Contact "d" to d_ptr<br>
* Remove the legacyhistorybackend as import from 2 years old version<br>
isn't important anymore<br>
* Fix the cmakelist duplicated line<br>
<br>
Missing d-pointers:<br>
* The ringtone model, a new version is in a github branch, I have yet<br>
to review and merge it<br>
* SecurityEvaluationModel is currently being rewriten, fixing it now<br>
is pointless, the new version wont be ready before this review expire<br>
<br>
All other classes without d-pointer are interfaces or proxy models,<br>
they don't need d-pointers.<br>
<br>
Regards,<br>
Emmanuel Lepage<br>
<div class="HOEnZb"><div class="h5"><br>
On 14 January 2015 at 18:22, Elv1313 . <<a href="mailto:elv1313@gmail.com">elv1313@gmail.com</a>> wrote:<br>
> Hello Albert,<br>
><br>
> Thanks for your comments.<br>
><br>
>> * src/abstractitembackend.h is twice in libringclient_LIB_HDRS<br>
><br>
> I will fix that, thanks, maybe we should add a Krazy2 check for that.<br>
> I know Laurent Model has posted one on <a href="http://planetkde.org" target="_blank">planetkde.org</a> for the code<br>
> a while back, I haven’t used it yet.<br>
><br>
>> * You have some d-pointers in some of your classes but not on others, why is<br>
> that?<br>
><br>
> Umm, I was under the impression I had fixed that in the commit before posting<br>
> this email. Krazy2 doesn't seem to analyze LibRingClient yet, even if I<br>
> checked it on <a href="http://projects.kde.org" target="_blank">projects.kde.org</a>. Maybe it does really take more than 5 days?<br>
> Anyhow, I will fix more of them. Some classes are really just templates aliases<br>
> + QObject inheritance, so those obviously don't need d-pointers. Other simply<br>
> have no private members, I am not sure if I should add d-pointer to those just<br>
> in case, maybe I should.<br>
><br>
>> * There's a catch regarding translations. You are using<br>
>> $XGETTEXT_QT in your Messages.sh. That creates a .po file that only works for<br>
>> clients that access those translations via kdelibs4 i18n() (or maybe other<br>
>> gettext wrappers) but not (i think) via kf5 ki18n() or plain Qt tr(). For Qt5<br>
>> we have $EXTRACT_TR_STRINGS that creates a proper .tr file to use with Qt5 (no<br>
>> idea if it works with Qt4, maybe it does). This is a bit weird too because<br>
>> your branch has both Qt4 and Qt5 support in the same branch but our<br>
>> translation system is build around the expectation that there will be separate<br>
>> branches and thus they will have different Messages.sh catering for each qt4<br>
>> and qt5. At this stage I'm not sure what's the best thing for you guys to do<br>
>> :/ Are you mainly targetting qt4 or qt5 for clients to use?<br>
><br>
> The problem is that we are doing a very major release right now and the kf5 port<br>
> is not ready yet, so it wont make the cut for our deadlines. There is 2 or 3<br>
> other projects trying to release a fully decentralized and secure communication<br>
> playform right now. We think we still are the closest to that, so we hurry up.<br>
> I prefer to spend my time on security details than KF5 port for the next month,<br>
> so we will miss the spring distribution cycle for KF5. After the 2.0 release,<br>
> getting rid of the Qt4 support will be something I will do. I don't care about<br>
> Qt4 at this point, but the KDE ui is still using KDE4 and I also wait for KDEPim<br>
> kf5 support to mature before doing the switch. The others clients, such as GTK<br>
> and OS X, use Qt5 and some patches are starting to be Qt5 only, but I don't<br>
> want to drop Qt4 until about mid-March. I guess translation support that works<br>
> on KDE4 is better than nothing for now. The new OSX and Gnome client don't have<br>
> any translations yet anyway, so the fact that the few tr() in libringclient are<br>
> not translated don't have an impact on them yet.<br></div></div></blockquote><div><br></div><div>May I ask why to create a Gtk and OSX native clients if Qt can work pretty well on an Gnome enviroment and also on OSX?<br></div><div>not arguing, just a silly doubt. :)<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
><br>
> As you saw, it also cause the CMakeLists.txt to be ugly and bloated and I also<br>
> have to keep the deprecated/qt4support flag on. I also can't use the abstract<br>
> proxy model and other classes that made their way into QtCore, nor switch to<br>
> the much easier to lint connect() syntax. There is quite a few //TODO qt5 in<br>
> the code. This is a (temporary) very bad situation...<br>
><br>
> Regards,<br>
> Emmanuel<br>
</div></div></blockquote></div><br></div></div>