Re: QML: a packagers nightmare. Assistance please.
On 11/8/23 10:14, Nate Graham wrote: On 11/8/23 09:37, David Edmundson wrote: If folks agree, I can do that. Do it, but given it's an cross-repo change lets do it after alpha rather than rushing. Ack, will do. Nate The alpha has been tarred, so I've gone ahead and done this. ShadowedLabel now lives in the PlasmaExtras QML module, and all usages of it have been ported to find it there. Nate
Re: Applet config dialog changes
I recall that we decided in yesterday's Plasma meeting to do it. Now that the Alpha is tarred, we can get started and will have three weeks to port everything before the first Beta/ Nate On 11/4/23 05:57, Nicolas Fella wrote: Hi, I have an open MR that changes how applet's config UI integrates with the container UI: https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1675 See https://invent.kde.org/plasma/plasma-desktop/-/issues/99 for some context. The benefits would not only be somewhat cleaner internals but also more flexibility for the applet itself. Currently the container provides a scrollview around the config, which is problematic for content that wants to provide its own scrollview, like the system tray entries page. See https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3204 The downside is that we need to touch all applet configs. Most of this is pretty straight-forward though, replacing the root item with a SimpleKCM (or other appropriate *KCM type). With release/freeze coming up we're in a now-or-never situation here. Should we do a concerted push towards getting this done? Cheers Nico
Re: QML: a packagers nightmare. Assistance please.
On 11/8/23 09:37, David Edmundson wrote: If folks agree, I can do that. Do it, but given it's an cross-repo change lets do it after alpha rather than rushing. Ack, will do. Nate
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.
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.
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 > >
Plasma Beta in 3 weeks
Plasma 6 alpha is now released to packagers for testing. Soft feature freeze is in 2 weeks, Wed 22 November Hard feature freeze and beta 1 is in 3 weeks Wed 29 November Happy coding Jonathan
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.
> If folks agree, I can do that. Do it, but given it's an cross-repo change lets do it after alpha rather than rushing. David
Re: QML: a packagers nightmare. Assistance please.
On 11/8/23 05:08, Kai Uwe Broulik wrote: Hi, that ShadowedLabel 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's a small component, but it exists to ensure visual consistency between all the different Plasma UIs that used shadowed white text; before this, their appearance and implementations were inconsistent. So I would not want to port away from the component entirely. That said, if having it in plasma-workspace is problematic, I think putting it in plasma-framework (or whatever that repo ends up being renamed to) seems like an easy solution. If folks agree, I can do that. Nate
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.
Hi, that ShadowedLabel 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.
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
