Falkon: Add qt quickcontrols{, 2} as optional dependencies for QML extensions

[Juraj Oravec]

Hello again,

> I was actually just (as in 3 minutes ago) discussing a very very
> similar topic with TQtC folks. The problem with QML is that there is
> no way to know beforehand that you depend on a certain qml module,
> except maybe looking at the source code of the application itself.

You are exactly right on this.
We have no way of knowing in advance what is needed, that is why I 
thought of adding optional dependencies, at least as an example.

> Yes, we could make Falkon depend on more QML packages, but what would
> happen if at some point the whole set of Falkon extensions covers 80%
> of the QML world? Should a user install that amount of QML modules
> "just in case" it is needed at some point?
> 
> If Falkon can use QML in it's extensions *ideally* it should be making 
> explicit which qml modules it needs.

There are 2 categories for this.
1. It could be a QML extension directly included in Falkon source code.
2. A "random" extension provided on the Falkon store.

In case "1." the dependency should be listed, but we do not have 
extensions like that. The integrated extensions are mostly C++ based 
(some in Python, but I found that many distributions do not ship it for 
multiple reasons).

In case "2." it is questionable how it should be handled by 
distributions. My opinion on this is that some basics should be provided 
At least on AppImages, Snaps, Flapaks and portable builds. In case of 
distribution package I would go with optional dependencies.

> So the question is: what is exactly/how do you define a QML module? The 
> approach at Debian (which I'm not saying it's correct or "the law",
> just our approach) is:
> 
> https://qt-kde-team.pages.debian.net/qmlmodulesnaming.html

I don`t know this QML very much, and that is also why I asked here and 
provided my thoughts on this issue. From my experience with using Debian 
based distribution I remember that Debian packages are often cut to very 
small pieces which may be a disadvantage in this case.

> If we could somehow tell the user "in order to install this extension
> you need foo and var QML modules" then it would be just great.

This is a bit tricky but it can at least partially be done (I think). In 
Falkon the extension loader now prints to the console the error message 
provided by QML component when it failed to load the extension. This 
contains at least a module name which is missing and maybe more 
information can be extracted (we can get a list of QQmlError) and 
presented to user in more visible/sensible way. Here it will fall on 
distribution to provide packages with similar names, which I know from 
experience can be tricky.


Conclusion (for now):
I will work on showing user the information when the QML extension fails 
to load to let him know the reason.


Thank you for your opinion.

Best regards,
Juraj



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/distributions/attachments/20230216/5c622f5d/attachment.sig>