* massive changes inside includes, drop unused definitions
* rewrite some initialization methods to avoid additional
freeing/allocation
* drop some explicit destructors calls
The previous versions stored values as string, so any (even if they are
not used) values being converted into string, and then (if required)
being converted back to float/int/etc. I've changed the mechanism, so
they are stored as QVariant (native value).
Please note that it is possible that this rewrite may cause crash in
some cases (if I've missed smth).
I've added 'optimize' option (by default true). If it options is set
then sources will be checked if they are required (with dependencies if
any). And if they are not required they will be dropped by using common
mechanism.
Please note that if this option enabled the following features (at the
moment) will be unavailable:
* key request from context menu (from configuration interface it still works)
* notifications event if sources on which notification is not connected
I suppose this commit will increase performance in about 4-5 times.
No significant changes applied.
* function syntax has been changed to another one, any function may be called
by using the following construction:
$aw_function_name<some args here if any>{{function body if any}}
* rewrite travis.yml
* Initial syntax is the following:
* $template{{ some JS code here }} - simple template based on JS
code inside. It works the same as lambda functions, but calculates
only once.
* aw_count(regex) - keys count found for given regex
* aw_keys(regex, [separator]) - keys found for given regex and
joined by using given separator
* aw_names(regex, [separator]) - key names found for given regex and
joined by using given separator (the same as previous but w\o $)
The template and function syntax may be changed before release.
* replace `foreach` to `for (auto foo : bar)` and update CONTRIBUTING.md
accordingly
This fact caused by the qt signal-slot implementation. Even if slots
code is going into parallel they will be called in the main app thread.
And also it is used inside KF5 dataengine implementation, so I'm affraid
that it could not be optimized w\o backend rewriting
