Telepathy KDE maintainership

James Daniel Smith smithjd15 at gmail.com
Wed Feb 1 03:59:39 UTC 2017


On Tuesday, January 31, 2017 12:00:07 PM MST kde-telepathy-request at kde.org 
wrote:
> There *will* be bugs (you yourself have updated the RRs so many times
> already)

The new availability of Q_ENUM and the move away from Q_FOREACH did contribute 
to the number of revisions. So did the new-style signals and slots, the lambda 
functions allowing some things that were previously impossible. Lambda signals 
and slots alone were worth their additional changes. A number of changes were 
made that increased functionality after the code went up for review, this was 
on top of reviewer's recommended improvements.

>highly complicated architecture

I don't think the Plugin implementation is that simple. Most of the complexity 
is in the PluginQueue class, which has to dispatch many different signals for 
the plugins, initiate changes to the plugins as well as provide a new presence 
or status message value from the plugin's queue. The queues are mostly similar 
but are fairly complex when the required logic is connected; preventing 
multiple queue activations and clumped change events is half of the queue 
signal logic. That class is also a DBus interface, potentially complicating 
the code in classes that interface it. It doesn't change the type of wrapped 
export variables.

>there will be *nobody* to look after those bugs

The code is working and closes an unusually large number of bugs or wishes, 
and effectively finishes the status handling portion of KTp feature-wise. The 
plugin-related bugs weren't widely complained about or reported, but still the 
existing shortcomings were addressed, the code was augmented in some areas 
that led to better and cleaner separation, some (arguably important) missed 
functionality was implemented, and more KTp features can now be worked on.

James


More information about the KDE-Telepathy mailing list