SFLPhone-KDE is now Ring-KDE and is moving to kdereview

[Albert Astals Cid]

El Dilluns, 12 de gener de 2015, a les 17:07:54, Emmanuel Lepage va escriure:
> Hello world,

Hi

> The SFLPhone team is proud to announce the project is now called Ring ahead
> of our 2.0 release. We are expanding the scope of the project from being a
> SIP telephony client to being a full SIP client and a P2P secure
> communication application based on open standards.
> 
> The KDE client used to be one client among other (GTK, KDE, Ubuntu mobile*,
> Plasma* and Android*), but, as our feature set grew, this created a lot of
> duplicated efforts. Features such contact handling and information sources
> gathering had to be done in each client. From now on, all client will be
> rewritten on top of the old SFLPhone-KDE client library (now called
> libringclient). This library is a pure Qt4/Qt5 library that turn the low
> level Ring daemon communication API into an high level client API. It
> depend on QtCore and optionally QtDbus. Information sources, such as
> contact are handled by extensions injected into the library at runtime
> (this is how we currently bind to Akonadi). The new native GTK and OSX
> client already use it as a backend. Using Qt model and QObject along with
> GTK Model and GObject work surprisingly well with Qt5! My college Stepan
> only took a couple of days to write an abstract glue layer between GTK and
> Qt and now it just work (models, variants, event loop and
> connect()/signals)!

Nice :)

> 
> The first step toward our 2.0 release is to split the libringclient project
> from the sflphone-kde one. This has just been done and the project can be
> downloaded at:
> 
> https://projects.kde.org/projects/kdereview/libringclient/repository
> 
> For now, it is in kdereview. I would like to move this to extragear as soon
> as possible. I cleaned the code to fix most EBN warnings and I am currently
> updating the Doxygen / API doc. The API is not frozen yet, but we are
> getting there. The documentation is still quite weak, but is getting better
> fast.
> 
> So here I am:
> 
> * In the last run Krazy ran mostly without issue, I will see how it goes now
> that it is a separate repository. (it still has to run in the new
> repository as I am writing this)
> * The documentation coverage is about 70% and getting up fast
> * I profiled the library extensively over the years, while there is always
> room for improvements, I am satisfied. It can handle tens of thousand of
> contacts and calls on a <2Ghz computer and work fine on ARM.
> * Translations are working
> * The code is C++11, but still support Qt4, so it doesn't use all features
> * There is some external documentation in this wiki page in the Ring
> project common wiki:
> 
> https://projects.savoirfairelinux.com/projects/sflphone/wiki/KDE_coding_guid
> elines
> https://projects.savoirfairelinux.com/projects/sflphone/wiki/Libringclient
> 
> The immediate future:
> 
> * Get feedback to be moved into extragear/network, fix what has to be fixed
> * Do the same with the other half of the project, the Ring-KDE client

Some comments:
 * src/abstractitembackend.h is twice in libringclient_LIB_HDRS

 * You have some d-pointers in some of your classes but not on others, why is 
that?

 * 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?

Cheers,
  Albert


> 
> Thanks for taking a look!
> 
> Best regards,
> Emmanuel Lepage
> 
> * Never officially part of stable releases