Re: QML: a packagers nightmare. Assistance please.
On Wed, Nov 8, 2023 at 9:41 AM Nicolas Fella wrote:
>
> On 11/8/23 17:11, Scarlett Moore wrote:
> > While I have everyone's attention. The part that is getting me ( and
> > our linters ) is qml installation paths seem all over the place
> > For example plasma-framework we have
> >
> > org.kde.plasma.plasmoids
> >
> > which I read in the docs is "identified" qml which states it must be
> > installed into the QML import path which is normally ( and our linter
> > is set to ) /usr/lib/{arch_triplet}/qt{version}/qml
> > https://doc.qt.io/qt-6/qtqml-modules-identifiedmodules.html
> >
> > However, these are getting installed to /usr/share/plasma/plasmoids
> >
> > This doesn't follow the folder path ( eg. org/kde/plasma/plasmoids )
> > nor the normal qml import path. Or am I missing something?
> > If it is our mistake to not have this in our import path and our
> > linter is confused somehow, how would I add it? /usr/share or
> > /usr/share/plasma but then wouldn't it still be looking for the
> > org/kde/plasma/plasmoids?
> > Thanks for any help, I am really trying to figure this stuff out, but
> > I am lost in a sea of docs.
> > Scarlett
>
> You are talking about two very different things here.
>
> QML modules (i.e. QML "libraries") are installed to
> /usr/lib/{arch_triplet}/qt{version}/qml. They contain a qmldir file,
> (optionally) a .so file, (optionally) some .qml files, (optionally) a
> .qmltypes file etc.
>
> The content of /usr/share/plasma/plasmoids are not QML modules. They are
> plasmoid packages (in the KPackage format). They contain a metadata.json
> file and a number of qml/js/xml files in contents/. For all intents and
> purposes those are data files like any other in /usr/share and should be
> treated as such.
>
> As such what you are seeing is entirely expected.
>
> Cheers
>
> Nico
>
Thanks for the explanation! So our linter is confused I guess. For another day.
Thanks again,
Scarlett
Re: QML: a packagers nightmare. Assistance please.
On 11/8/23 17:11, Scarlett Moore wrote:
While I have everyone's attention. The part that is getting me ( and
our linters ) is qml installation paths seem all over the place
For example plasma-framework we have
org.kde.plasma.plasmoids
which I read in the docs is "identified" qml which states it must be
installed into the QML import path which is normally ( and our linter
is set to ) /usr/lib/{arch_triplet}/qt{version}/qml
https://doc.qt.io/qt-6/qtqml-modules-identifiedmodules.html
However, these are getting installed to /usr/share/plasma/plasmoids
This doesn't follow the folder path ( eg. org/kde/plasma/plasmoids )
nor the normal qml import path. Or am I missing something?
If it is our mistake to not have this in our import path and our
linter is confused somehow, how would I add it? /usr/share or
/usr/share/plasma but then wouldn't it still be looking for the
org/kde/plasma/plasmoids?
Thanks for any help, I am really trying to figure this stuff out, but
I am lost in a sea of docs.
Scarlett
You are talking about two very different things here.
QML modules (i.e. QML "libraries") are installed to
/usr/lib/{arch_triplet}/qt{version}/qml. They contain a qmldir file,
(optionally) a .so file, (optionally) some .qml files, (optionally) a
.qmltypes file etc.
The content of /usr/share/plasma/plasmoids are not QML modules. They are
plasmoid packages (in the KPackage format). They contain a metadata.json
file and a number of qml/js/xml files in contents/. For all intents and
purposes those are data files like any other in /usr/share and should be
treated as such.
As such what you are seeing is entirely expected.
Cheers
Nico
Re: QML: a packagers nightmare. Assistance please.
While I have everyone's attention. The part that is getting me ( and
our linters ) is qml installation paths seem all over the place
For example plasma-framework we have
org.kde.plasma.plasmoids
which I read in the docs is "identified" qml which states it must be
installed into the QML import path which is normally ( and our linter
is set to ) /usr/lib/{arch_triplet}/qt{version}/qml
https://doc.qt.io/qt-6/qtqml-modules-identifiedmodules.html
However, these are getting installed to /usr/share/plasma/plasmoids
This doesn't follow the folder path ( eg. org/kde/plasma/plasmoids )
nor the normal qml import path. Or am I missing something?
If it is our mistake to not have this in our import path and our
linter is confused somehow, how would I add it? /usr/share or
/usr/share/plasma but then wouldn't it still be looking for the
org/kde/plasma/plasmoids?
Thanks for any help, I am really trying to figure this stuff out, but
I am lost in a sea of docs.
Scarlett
On Wed, Nov 8, 2023 at 4:48 AM David Redondo wrote:
>
> Am Mittwoch, 8. November 2023, 12:22:33 CET schrieb Scarlett Moore:
> > Hi everyone,
> > As we progress through the Qt6 transition I have been trying to keep
> > up on our QML dependencies and I keep tripping over circular
> > dependency nightmare. We switched to a mega package format which
> > includes qml modules. So we have big issues when frameworks like kwin
> > depends on plasma-workspace. Introduced here:
> >
> > https://invent.kde.org/plasma/kwin/-/commit/028dd552cfb9d826b40b9620d869c98d
> > 2aa3dca3?page=2
> >
> > Is it intended that qml modules in plasma-workspace are allowed to be
> > used by frameworks? Are we wrong to bundle QML inside a mega package
> > or is the framework wrong for depending on QML further up the stack?
> > Any help or insight would be much appreciated.
>
>
> CC'ing plasma-devel and distributions so stakeholders can chime in.
>
> From what I am seeing this patch causes KWin to import a qml module that lives
> in plasma-workspace
>
> import org.kde.plasma.workspace.components 2.0 as WorkspaceComponents
>
> At the same time plasma-workspace build depends on KWin due to the need of the
> DBus xml files.
>
> So the situation right now is that plasma-workspace build depends on KWin and
> KWin has a runtime dependency on plasma-workspace.
> I think it's not a full cycle since installing plasma-workspace does not need
> anything from KWin but maybe it can cause problems for distributions?
>
> David
>
>
Re: QML: a packagers nightmare. Assistance please.
On Wednesday, 8 November 2023 12:48:32 CET, David Redondo wrote: So the situation right now is that plasma-workspace build depends on KWin and KWin has a runtime dependency on plasma-workspace. I think it's not a full cycle since installing plasma-workspace does not need anything from KWin but maybe it can cause problems for distributions? At least no problem here, our package can deal with a build-runtime cycle.
Re: QML: a packagers nightmare. Assistance please.
On 2023-11-08, Kai Uwe Broulik wrote: > Hi, > > that WorkspaceComponents is used for a ShadowedLabel which is literally > one QML file with a Label and a DropShadow. KWin could just not use that > (and build its own) and we’d resolve the issue. It sounds like either moving that component one level "up" in the hierachy or this suggestion or something else would resolve the issue. And in a nice way. /Sune
Re: QML: a packagers nightmare. Assistance please.
(forgot to cross-post kde-devel/distributions) Hi, that WorkspaceComponents is used for a ShadowedLabel which is literally one QML file with a Label and a DropShadow. KWin could just not use that (and build its own) and we’d resolve the issue. Cheers Kai Uwe > From what I am seeing this patch causes KWin to import a qml module that lives > in plasma-workspace > > import org.kde.plasma.workspace.components 2.0 as WorkspaceComponents > > At the same time plasma-workspace build depends on KWin due to the need of the > DBus xml files. > > So the situation right now is that plasma-workspace build depends on KWin and > KWin has a runtime dependency on plasma-workspace. > I think it's not a full cycle since installing plasma-workspace does not need > anything from KWin but maybe it can cause problems for distributions? > > David > >
Re: QML: a packagers nightmare. Assistance please.
I apologize for the header. I have been struggling with QML and a bit frustrated from a packager point of view. It very well may be a bug in our build system. I appreciate all the input thus far. Scarlett On Wed, Nov 8, 2023 at 4:48 AM David Redondo wrote: > > Am Mittwoch, 8. November 2023, 12:22:33 CET schrieb Scarlett Moore: > > Hi everyone, > > As we progress through the Qt6 transition I have been trying to keep > > up on our QML dependencies and I keep tripping over circular > > dependency nightmare. We switched to a mega package format which > > includes qml modules. So we have big issues when frameworks like kwin > > depends on plasma-workspace. Introduced here: > > > > https://invent.kde.org/plasma/kwin/-/commit/028dd552cfb9d826b40b9620d869c98d > > 2aa3dca3?page=2 > > > > Is it intended that qml modules in plasma-workspace are allowed to be > > used by frameworks? Are we wrong to bundle QML inside a mega package > > or is the framework wrong for depending on QML further up the stack? > > Any help or insight would be much appreciated. > > > CC'ing plasma-devel and distributions so stakeholders can chime in. > > From what I am seeing this patch causes KWin to import a qml module that lives > in plasma-workspace > > import org.kde.plasma.workspace.components 2.0 as WorkspaceComponents > > At the same time plasma-workspace build depends on KWin due to the need of the > DBus xml files. > > So the situation right now is that plasma-workspace build depends on KWin and > KWin has a runtime dependency on plasma-workspace. > I think it's not a full cycle since installing plasma-workspace does not need > anything from KWin but maybe it can cause problems for distributions? > > David > >
Re: QML: a packagers nightmare. Assistance please.
Am Mittwoch, 8. November 2023, 12:22:33 CET schrieb Scarlett Moore: > Hi everyone, > As we progress through the Qt6 transition I have been trying to keep > up on our QML dependencies and I keep tripping over circular > dependency nightmare. We switched to a mega package format which > includes qml modules. So we have big issues when frameworks like kwin > depends on plasma-workspace. Introduced here: > > https://invent.kde.org/plasma/kwin/-/commit/028dd552cfb9d826b40b9620d869c98d > 2aa3dca3?page=2 > > Is it intended that qml modules in plasma-workspace are allowed to be > used by frameworks? Are we wrong to bundle QML inside a mega package > or is the framework wrong for depending on QML further up the stack? > Any help or insight would be much appreciated. CC'ing plasma-devel and distributions so stakeholders can chime in. >From what I am seeing this patch causes KWin to import a qml module that lives in plasma-workspace import org.kde.plasma.workspace.components 2.0 as WorkspaceComponents At the same time plasma-workspace build depends on KWin due to the need of the DBus xml files. So the situation right now is that plasma-workspace build depends on KWin and KWin has a runtime dependency on plasma-workspace. I think it's not a full cycle since installing plasma-workspace does not need anything from KWin but maybe it can cause problems for distributions? David
Re: QML: a packagers nightmare. Assistance please.
On 2023-11-08, Nicolas Fella wrote: > Furthermore, kwin is not a framework, it's part of Plasma, and > dependencies between Plasma components are generally fine. That there is > a circular dependency between plasma-workspace and kwin is not good and > should probably be addressed somehow, but the severity is somewhat lower > given the cycle doesn't exist at built time. Though given packagers are being heavily suggested, and several has already, to write tools to help atuomatically track QML dependencies to ensure no depends: is left behind, cycles like these makes it impossible to actually do so. Either we should retract that suggestion and live with more broken QML dependencies in distributions until users randomly fix it, or we should try harder to not have such cycles, and when we see them be quick to fix them. /Sune
Re: QML: a packagers nightmare. Assistance please.
On 11/8/23 12:22, Scarlett Moore wrote: Hi everyone, As we progress through the Qt6 transition I have been trying to keep up on our QML dependencies and I keep tripping over circular dependency nightmare. We switched to a mega package format which includes qml modules. So we have big issues when frameworks like kwin depends on plasma-workspace. Introduced here: https://invent.kde.org/plasma/kwin/-/commit/028dd552cfb9d826b40b9620d869c98d2aa3dca3?page=2 Is it intended that qml modules in plasma-workspace are allowed to be used by frameworks? Are we wrong to bundle QML inside a mega package or is the framework wrong for depending on QML further up the stack? Any help or insight would be much appreciated. Hi, first of all, I don't think starting off an email with "QML: a packagers nightmare" is a good-faith way to start a discussion about something, especially given the issue presented has little to do with QML as a technology and is rather specific to the projects involved. Furthermore, kwin is not a framework, it's part of Plasma, and dependencies between Plasma components are generally fine. That there is a circular dependency between plasma-workspace and kwin is not good and should probably be addressed somehow, but the severity is somewhat lower given the cycle doesn't exist at built time. Cheers Nico
QML: a packagers nightmare. Assistance please.
Hi everyone, As we progress through the Qt6 transition I have been trying to keep up on our QML dependencies and I keep tripping over circular dependency nightmare. We switched to a mega package format which includes qml modules. So we have big issues when frameworks like kwin depends on plasma-workspace. Introduced here: https://invent.kde.org/plasma/kwin/-/commit/028dd552cfb9d826b40b9620d869c98d2aa3dca3?page=2 Is it intended that qml modules in plasma-workspace are allowed to be used by frameworks? Are we wrong to bundle QML inside a mega package or is the framework wrong for depending on QML further up the stack? Any help or insight would be much appreciated. Scarlett
