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