Some small nitpicks... Other than that, I think this change is pretty good.

Also, some reasons for keeping * and & when using auto:
(a) it improves readability
(b) as I said previously, in some cases, * matters, e.g.

int x = 42;

const auto foo = &x;
*foo = 43; // totally fine, foo of type int* const

const auto *bar = &x;
*bar = 43; // compilation error, bar is of type const int*

In most cases, we want to have the latter, not the former. If one wants to have a const pointer to something, then he/she needs to say it explicitly, e.g.

auto *const foo = &x;

We need to start a thread on frameworks-devel defining KDE's coding standard use of auto. I've made the changes for now but it's rather frustrating to try and follow non-defined policies.

Personally, I fully support being explicit with type hints when there's overloads or when you want const references, but being explicit for the common T* case doesn't help anything.
Also I don't really buy that being explicit is needed for readability given we allow foo()->bar() without interim variables.

but I'm happy to follow whatever

In D14482#300950, @davidedmundson wrote:

We need to start a thread on frameworks-devel defining KDE's coding standard use of auto. I've made the changes for now but it's rather frustrating to try and follow non-defined policies.

Personally, I fully support being explicit with type hints when there's overloads or when you want const references, but being explicit for the common T* case doesn't help anything.
Also I don't really buy that being explicit is needed for readability given we allow foo()->bar() without interim variables.

but I'm happy to follow whatever

I agree with David. I'm only explicit with const, * or & if it is needed. So in most cases it is just auto.

In D14482#300950, @davidedmundson wrote:

We need to start a thread on frameworks-devel defining KDE's coding standard use of auto. I've made the changes for now but it's rather frustrating to try and follow non-defined policies.

+1. Also, maybe, there should be some rules for using auto, because currently it's overused.

Personally, I fully support being explicit with type hints when there's overloads or when you want const references, but being explicit for the common T* case doesn't help anything.
Also I don't really buy that being explicit is needed for readability given we allow foo()->bar() without interim variables.

I think that would be the case only for types that are used very often. E.g. if we're inside of QWidget, I think that's fine to have the following piece of code

void Widget::painEvent(QPaintEvent *e)
{
    ...
    const QPoint center = rect().center();
    ...
}

If auto wasn't overused, I would agree with you too (about readability), because in most cases it would be overkill:

auto *bar = static_cast<int *>(foo.data());

But even if it wasn't overused, I still would prefer to keep * because of consistency:

int x = 42;

const auto *foo = &x;

auto bar = &x; // ???

and because it constrains variables to raw pointers.

Anyway, we got our discussion a little bit off-topic.

but I'm happy to follow whatever

Also, if you feel that omitting * would be better, omit them. As you said, we don't have any policies on auto. Should we use it with new? Should we use it with reinterpret_cast? Should we use it with static_cast? Should we use auto in the following scenario auto foo = bar();?

Using auto with static_cast and new is very common so I think it should go.

I hope that I have enough rights to accept this patch after doing some work on effects.

Sure

So, with the "new" API, scripted effects will be able to do full screen effects, right?

Not as a direct result of the QJSEngine port, but we should have something for 5.14 to handle that.