<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 31, 2017 at 10:59 PM, James Daniel Smith <span dir="ltr"><<a href="mailto:smithjd15@gmail.com" target="_blank">smithjd15@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tuesday, January 31, 2017 12:00:07 PM MST <a href="mailto:kde-telepathy-request@kde.org">kde-telepathy-request@kde.org</a><br>
wrote:<br>
<span class="gmail-">> There *will* be bugs (you yourself have updated the RRs so many times<br>
> already)<br>
<br>
</span>The new availability of Q_ENUM and the move away from Q_FOREACH did contribute<br>
to the number of revisions. So did the new-style signals and slots, the lambda<br>
functions allowing some things that were previously impossible. Lambda signals<br>
and slots alone were worth their additional changes. A number of changes were<br>
made that increased functionality after the code went up for review, this was<br>
on top of reviewer's recommended improvements.<br></blockquote><div><br></div><div>That is what I'm saying. After reviews the functionality went up, it just keeps</div><div>going up. Bugs go up linearly with functionality. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>highly complicated architecture<br>
<br>
I don't think the Plugin implementation is that simple. Most of the complexity<br>
is in the PluginQueue class, which has to dispatch many different signals for<br>
the plugins, initiate changes to the plugins as well as provide a new presence<br>
or status message value from the plugin's queue. The queues are mostly similar<br>
but are fairly complex when the required logic is connected; preventing<br>
multiple queue activations and clumped change events is half of the queue<br>
signal logic. That class is also a DBus interface, potentially complicating<br>
the code in classes that interface it. It doesn't change the type of wrapped<br>
export variables.<br></blockquote><div><br></div><div>There should be no plugin queue. I have specifically told you many, many</div><div>times in your RRs that the mpris thing should just die. There should be</div><div>a simple auto-away and lock-screen integration, that's it. No plugins, no</div><div>queues, no extra added complexity. Nothing like that is needed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
>there will be *nobody* to look after those bugs<br>
<br>
</span>The code is working and closes an unusually large number of bugs or wishes,<br>
and effectively finishes the status handling portion of KTp feature-wise. The<br>
plugin-related bugs weren't widely complained about or reported, but still the<br>
existing shortcomings were addressed, the code was augmented in some areas<br>
that led to better and cleaner separation, some (arguably important) missed<br>
functionality was implemented, and more KTp features can now be worked on.<br></blockquote><div><br></div><div>Every code works on developer's machine. There will be bugs and someone</div><div>will have to take care of them. That's simply a history-supported fact, not</div><div>a random statement pulled out of the blue. There is currently noone taking</div><div>care of bugs. That is also a fact.</div><div class="gmail_quote"><br></div>Given all that, my position still stands. KDE Telepathy does not need this</div><div class="gmail_quote">extreme complexity, what it needs is reducing the code and features so</div><div class="gmail_quote">that it becomes manageable for a single maintainer. And then it needs that</div><div class="gmail_quote">single dedicated maintainer that will be able to take care of the whole</div><div class="gmail_quote">project, which is already super huge.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Cheers<br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div dir="ltr"><div><span style="color:rgb(102,102,102)">--</span></div><div><span style="color:rgb(102,102,102)">Martin Klapetek</span> </div></div></div></div></div></div></div></div>