New release

[Pedro de Carvalho Gomes]

Hi Heiko and others,

I started a branch to port from QTScript to QJS*. It's gonna be quite
some work, and I don't even have a compiling version yet. I tell this
so we avoid duplicated work. I may push the branch to Gitlab whenever
someone wants to join the effort.

So far I have identified few points about the port:
- there's no equivalent to QScriptDebugger at QJS* I have already
written a skeleton to replace it. I see two possible ways to go here:
a) try to reuse KDevelop's widgets (for local variables, code, stack
analysis, etc), and logic from its QML plugin (for controlling
debugging), or b) check which widgets QScriptDebugger has, and use
them, and copy the logic from QTcreator
- there's no way to the "this" reference from a JSValue function. I
mean, one can invoke a JSValue function and set the "this" with
JSValue.callWithInstance(). But one cannot retrieve the JS "this" from
an exported method that is called within the engine. I still don't
know a good way to solve this
- there are few minor incompatibilites more, which are not so bad. For
example, QJSEngine has no correspondance to QScriptEngine's ownership
(ValueOwnership). However QmlEngine has a similar notion
(ObjectOwnership). So using QmlEngine, which inherites from QJSEngine,
is an alternative. Another missing feature is a way to set a default
prototype for a given class (before there was setDefaultPrototype)

I keep you posted of any meaningful progress.

Cheers,

Pedro

On Tue, Apr 14, 2020 at 4:04 AM Heiko Becker <mail at heiko-becker.de> wrote:
>
> Hey Pedro and all,
>
> On Sonntag, 12. April 2020 09:51:33 CEST, Pedro de Carvalho Gomes wrote:
> > I think the main reason for the delay of a new version is now
> > concluded (or at least in a decent state), which was the port to KF5.
> > There's also one major issue, which is the deprecation of mysql
> > embedded.
>
> Myriam asked for a release as well. It's not much work to create and
> release a tarball and I'm happy to do it, but I'm bit concerned about
> expectations. IMHO it should "only" be an alpha release. There are still
> rough edges and one problem (besides the mentioned mysqle issue) is
> scripting. QtScript is deprecated and will go away and there are currently
> no Qt5 bindings for it anyway. Possible solutions are
>
> - Get rid of it alltogether
> - There's a patch on phab to add bindings extracted from Qcad which still
> uses QtScript, https://phabricator.kde.org/D24817 and needs at least some
> license headers and some glue
> - Port to the QJS* classes from QtQml (one simple example for a Plasma
> runner [1])
>
> Any opinions on that?
> Personally I'd prefer the last option because it isn't likely to cause an
> outcry and should be somewhat future-proof (i.e. possibly meaning less work
> to port to Qt6). I don't know how feasible that would be in Amarok's case
> though, but I hope to find some time for that in the next week.
>
> > I went after Mariadb's plans for the embedded library. I couldn't find
> > any mention to it. Only references to 10.5 series mirroring Mysql 8,
> > which is the version that dropped Mysql embedded. However Mariadb 10.4
> > contains the embedded library, and is supported until June 2024 (see
> > https://mariadb.com/kb/en/new-and-old-releases/)
>
> I just checked out the 10.5 branch of Mariadb and it looks like the
> embedded server is still present there.
>
> > I wonder if Amarok could release a version with dependency to Mariadb
> > <= 10.4. Then we prioritize the port to the alternative to
> > mariadb/mysql. This would bridge the 2-year gap from the previous
> > release. Also it would bring Amarok back to distros that are not
> > shipping it because it doesn't have an official KF5 versions (namely
> > Ubuntu).
>
> I think there's no need to declare such a dep on our side at the moment. It
> sufficient to check if it's present or not in our cmake code, which we
> already do.
>
> Regards,
> Heiko
>
> [1]
> https://cgit.kde.org/plasma-workspace.git/commit/?id=605fb9acd867e22e171184a08d9dfd2d1d4e893e