On Tuesday, January 31, 2017 12:00:07 PM MST [email protected] 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
