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