/my opinion Mostly politics,
Some users do really refuse to use Qt apps, don't ask me why, I never understood. As for nativeness, Qt on OSX never felt that native, it is even worst with Yosemite new style. VLC and Transmission did the same, they have a default Qt client for Windows and Linux, then a native client for OSX and an alternate GTK client for Linux. These days, SFLPhone have about a 50/50 split between the KDE and GTK clients, but historically there is a lot of GTK users. I know you managed to overcome that on Subsurface, as did Wireshark, GCompris and LXDE, but Savoir-faire Linux (my employer and sponsor of the project) have been friendly with the Gnome project over the years, helping them setup their meeting in Montreal a few years back. By not taking position, they also preserve a kind of neutrality for the image of the company. Yes, the return on investment for the overhead is disputable, but politics always is. In the end a GTK client was an hard requirement, and I am fine with that ( as long as I don't have to code it :P ). Then after all, the client logic is in this library. It almost exclusively expose models and proxy models, so other clients will be thin clients with a bunch of custom widgets, it wont get very complicated. On 20 January 2015 at 07:11, Tomaz Canabrava <tcanabr...@kde.org> wrote: > > > 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 > >
