Opal QML components for app development

[ichthyosaurus]

Opal for Sailfish

Quite some time ago, a few developers (me being one of them) started a new project to provide easy-to-use and pretty QML components to help others create even more great apps. Thus, Opal was born:

Opal is a collection of pretty QML components for SailfishOS, building on top of Sailfish’s Silica components. It provides ready-made components, examples, snippets, recipes, and resources for building more sailfishy Sailfish apps.

This thread is meant to announce the project, gather feedback, and continue the discussions from the old thread.

What’s in it?

Currently, there are two finished QML modules, a set of extra icons, and a handful of scripts, tools, and recipes to help with development. Be sure to check out the gallery app!

For example, with the Opal.About module you can create beautiful and compliant “About” pages in less than 20 lines of code. It takes care of all the tedious work around licenses, contributor lists, donations, attributions, and changelogs, while being flexible and allowing custom content as well. This basic code from the gallery app creates the following pages:

import QtQuick 2.0
import Opal.About 1.0

AboutPageBase {
    appName: qsTr("Opal Gallery")
    appIcon: Qt.resolvedUrl("../images/harbour-opal-gallery.png")
    appVersion: APP_VERSION
    appRelease: APP_RELEASE
    description: qsTr("Opal is a collection of pretty QML components...")
    authors: "2020-2021 Mirian Margiani"
    licenses: License { spdxId: "GPL-3.0-or-later" }
    attributions: OpalAboutAttribution {}
    sourcesUrl: "https://github.com/Pretty-SFOS/opal"
}

About page	Contributors page	Licenses page

(Other, less me-focused examples are welcome .)

See the main repo for a list of all contents:

GitHub - Pretty-SFOS/opal: A collection of pretty QML components for SailfishOS

How can I use it?

Simply download the latest release bundle and follow the steps described here. Everything is thoroughly documented.

Which license?

Most things are currently under GPL v3+ but others are under various different free and/or open source licenses.

Why this name?

Because of the crystal: Opal - Wikipedia. Like Silica it has no strong form in itself. It is a beautiful material to be cut, though, too. It also fits nicely to Jolla’s new Amber components.

Status of the project

Opal is ready for production. That being said, Opal is not yet very mature and the ecosystem still has to grow. Check out the progress section in the main repo.

Contributions and feedback are welcome!

Opal is intended as a community collaboration to collect useful and nice things, and make them into reusable components. There are many beautiful apps out in the wild - let’s build on their work!

Also, all developers who have their own personal libraries of reusable components for their projects are invited to publish them as part of Opal. Let’s over-engineer Sailfish together!

[poetaster]

One generic component I’ve been thinking about is a chart component. Watchlist uses an approach from Systemmonitor, including harbour-systemmonitor/app/qml/pages/GraphData.qml at master · custodian/harbour-systemmonitor · GitHub and that does seem a reasonably generic way to go. I had been looking at this issue since I want to implement graphing in several apps and several others use custodians approach.
EDIT, I’m not sure if the method in meteo is even better??!

[poetaster]

And another one I’m looking at is a generic notifications widget. I think I’m maintaining 8 different approaches

[direc85]

I’ve been reusing my own About page and its components, let’s see if I switch to Opal instead

I also have (somewhere…) a page to display the license text, would that fit in Opal?

[poetaster]

And another one that I keep re-inventing, Docking widget.

[nephros]

I have a question about licensing.

The original Opal stuff has a mix of GPL3+ for code, and GFDL and CC for other stuff.

I added Components now, and more out of habit than anything else, that is currently under Apache-2.0.
I prefer permissive to GPL-style licenses, but that is not a very strong preference, and I’m fine to comply with any guidance wrt. Opal.

So:

• should contributions strive to use the same license for code (which would likely be GPL3+) in Opal?
• otherwise, are we Ok with ending up with a bunch of different licenses under the Opal umbrella? Could be a hassle for users of Opal modules.
• or a mix, dual-license things, i.e. whatever the original code had (assuming it’s brought over from an existing app), plus a common lic for distribution under Opal?

[poetaster]

Although I prefer using the GPLv3, I think that given the aim of the project being to augment silica stuff, it makes more sense if we go permissive or at least GPLv2 ? 2 bits.

[ichthyosaurus]

@poetaster

One generic component I’ve been thinking about is a chart component. Watchlist uses an approach from Systemmonitor, including harbour-systemmonitor/app/qml/pages/GraphData.qml at master · custodian/harbour-systemmonitor · GitHub and that does seem a reasonably generic way to go. I had been looking at this issue since I want to implement graphing in several apps and several others use custodians approach.

Oh, that would be really nice! Qt’s QML Charts would be worth looking into, I guess. We probably don’t have that on SFOS but maybe it could be ported / backported?

@poetaster

EDIT, I’m not sure if the method in meteo is even better??!

Noo, no, no, I don’t recall exactly how I did it but it’s a horrible hack and I’m afraid of looking at it ever again. Rain graphs are not working correctly for quite some time and I just hope that I don’t have to fix anything in the graphs itself…

@poetaster

generic notifications widget

Isn’t Nemo.Notifications doing that? Or do you mean in-app notifications? I think Jolla introduced something some time ago, the method that’s used in the clock app when setting an alarm. I didn’t see it in the docs though, last time I checked.

@direc85

I’ve been reusing my own About page and its components, let’s see if I switch to Opal instead

I also have (somewhere…) a page to display the license text, would that fit in Opal?

Yesss, please switch, I need actual users . License texts are already supported by Opal.About: if your app has Internet access, you can allow users to download them directly. You can also add your own short versions for specific licenses (the GPL “NO WARRANTIES” text is already included).

I think the only thing that is currently used on some “About” pages in the wild and that is not supported by Opal.About is email addresses for individual contributors. I tried many approaches but there’s no way to support links in a DetailItem.

@poetaster

And another one that I keep re-inventing, Docking widget.

Do you mean custom DockedPanels? I love your enthusiasm, and I really look forward to new modules!

[ichthyosaurus]

@poetaster

Although I prefer using the GPLv3, I think that given the aim of the project being to augment silica stuff, it makes more sense if we go permissive or at least GPLv2 ? 2 bits.

I decided against going permissive because I really don’t want my stuff ending up in some closed source walled garden (with the current Silica situation we’re already caught in one anyway…). It’s not only meant to augment Silica, rather it’s meant to support a growing copyleft ecosystem, and maybe someday Jolla feels compelled to open Silica.

That’s my rationale but I don’t set rules for other developers, as long as they use licenses that are free and compatible with the GPL. GPL has a tendency to make other things become GPL (here) but I’m mostly thinking of the green part in this list.

@nephros

or a mix, dual-license things, i.e. whatever the original code had (assuming it’s brought over from an existing app), plus a common lic for distribution under Opal?

If it’s code that was ported over from another app, then that might be a good way to go. In other cases, I don’t really care as long as licenses are upwards compatible with GPLv3 because the apps I write are GPLv3.

@flypig asked me about that too, but this part didn’t make into the article:

9. Why are there multiple licences? What does this mean in practice for developers?

Opal is built in the spirit of Free Software but there’s no policy as to what this means exactly for contributions: if you want to contribute a QML module under any free license (be it permissive or copyleft), you are invited to do so! The only requirement is strict reuse compliance, so that the licensing of all parts is clear.

In practice, this is mostly invisible to developers and users: if you are developing Free Software, then proper attribution is probably the only thing you have to be concerned about. This is where Opal.About comes in: you provide some details and a SPDX license ID, and the “About” page module generates the rest for you.

That being said, all things currently in Opal are mostly licensed under GPL, CC-BY-SA, or CC-0 (public domain).

So, to answer your questions:

@nephros

• should contributions strive to use the same license for code (which would likely be GPL3+) in Opal?
• otherwise, are we Ok with ending up with a bunch of different licenses under the Opal umbrella? Could be a hassle for users of Opal modules.

I prefer GPLv3+ and I encourage everyone to do that too but I think it’s not too much of a hassle if a module uses a different free license. Modules come with their own Attribution components that can be included in the “About” page, and I think in most cases that’s all you have to think about.

But I’m absolutely no expert on licensing, so… please tell me what you think! (@poetaster I assume you know a thing or two about licensing?)

[poetaster]

@ichthyosaurus

I prefer GPLv3+ and I encourage everyone to do that too but I think it’s not too much of a hassle if a module uses a different free license.

I’m kosher with GPLv3. It aligns with my goals. However, my goals do not, really, align with Jollas. Nevertherless I use Silica. Because I like the outcome. I haven’t gone into the details, but much of what I’m going DEPENDS on silica so I’m in a bit of a quandary. Should Opal components AVOID silica dependencies?

I’m also considering investing some time in getting all the apps I work on onto other platforms, but that’s another kettle of fish.

[poetaster]

I should qualify the aligns statement. I do a LOT of work to try to enhance the ecosystem FOR jolla. So, obviously, I have aims that explicitly include the welfare of Jolla. But I really detest the NDAs and the GPL fear. Embrace the dark side, I say. The doors to the dark side are ALWAYS open

[ichthyosaurus]

@poetaster

I’m kosher with GPLv3. It aligns with my goals. However, my goals do not, really, align with Jollas. Nevertherless I use Silica. Because I like the outcome. I haven’t gone into the details, but much of what I’m going DEPENDS on silica so I’m in a bit of a quandary.

@poetaster

I do a LOT of work to try to enhance the ecosystem FOR jolla. So, obviously, I have aims that explicitly include the welfare of Jolla. But I really detest the NDAs and the GPL fear.

Yeah, I think we’re in the same boat… I think we desparately need something like the KDE Free Qt Foundation but with Sailfish/Silica/etc.

@poetaster

I’m also considering investing some time in getting all the apps I work on onto other platforms, but that’s another kettle of fish.

And it’s sooo much work, and it will make them ugly on all platforms while they would be beautiful on Sailfish. SFOS has such an individual “design language” that I don’t think it’s really possible to create apps that look good cross-platform…

@poetaster

Should Opal components AVOID silica dependencies?

Not sure if this was rhetorical, but no: Opal build on top of Silica and should aim to look good and provide high quality code for Sailfish. Unless it’s possible to avoid such a dependency without sacrificing anything, then let’s avoid it of course.

[poetaster]

@ichthyosaurus

Yeah, I think we’re in the same boat… I think we desparately need something like the KDE Free Qt Foundation but with Sailfish/Silica/etc.

Maybe some work for the sailmates association? @jojo @vlagged Maybe some Opal project sponsoring?

@ichthyosaurus

And it’s sooo much work, and it will make them ugly on all platforms while they would be beautiful on Sailfish. SFOS has such an individual “design language” that I don’t think it’s really possible to create apps that look good cross-platform…

I’m not sure because I haven’t looked at it hard enough, but it is possible to stay closer to Silica like guidelines for design outside Silica. The main problem is that compositing with ambiences get’s us unified appearance, which no one else does. I would miss that. The way it’s done in the cases I deal with (Fahrplan for instance) is completely separate QML for the different platforms. That means more work, but with careful design, not necessarily so much more. And I’m working bit by bit at refactoring to make that more likely. If I was able to get a number of apps running on IOs, for instance, I might actually be able to finance the work

@ichthyosaurus

Not sure if this was rhetorical, but no: Opal build on top of Silica and should aim to look good and provide high quality code for Sailfish.

Ok, that’s what I thought. But it means that the licenses could be a hindrance for use on Jolla’s side and that would be a bit sad if the work proves of wider utility. That was what I was getting at.

[nephros]

@poetaster

@ichthyosaurus

And it’s sooo much work, and it will make them ugly on all platforms while they would be beautiful on Sailfish. SFOS has such an individual “design language” that I don’t think it’s really possible to create apps that look good cross-platform…

I’m not sure because I haven’t looked at it hard enough, but it is possible to stay closer to Silica like guidelines for design outside Silica. The main problem is that compositing with ambiences get’s us unified appearance, which no one else does. I would miss that. The way it’s done in the cases I deal with (Fahrplan for instance) is completely separate QML for the different platforms. That means more work, but with careful design, not necessarily so much more. And I’m working bit by bit at refactoring to make that more likely. If I was able to get a number of apps running on IOs, for instance, I might actually be able to finance the work

Well I guess the idea of making a Theme for Kirigami, and a QT_QPA_PLATFORMTHEME for Qt5.15 to make apps using those more Sailfish-like could help there.

So you develop against Kirigami, and use the “native” theme for depending on target platform.

Qt 5.15: what's next?

With Qt5.15/KF5 project, we are progressing fast in terms of packaging new libraries. Based on the progress so far, we can conclude that, what started as a proof-of-concept, works and it is possible to have Qt 5.15 on our devices. Thus, it is natural to ask what to do next with this. From SFOS point of view, we are kept behind by proprietary packages. So, one way of approaching this is to replace all proprietary code with the open source alternatives. This includes Silica, SFOS compositor compo…

I at one point made a promise to look into that, and did a) choose a name for the theme, SiO2, and b) write about seven lines of code and then stopped. I do not yet understand enough of what’s to be done here. (Commits · nephros/qtquickcontrols2 · GitHub, Commits · nephros/qtquickcontrols2-packaging · GitHub)

[poetaster]

@nephros

I at one point made a promise to look into that, and did a) choose a name for the theme, SiO2 , and b) write about seven lines of code and then stopped. I do not yet understand enough of what’s to be done here. (Commits · nephros/qtquickcontrols2 · GitHub, Commits · nephros/qtquickcontrols2-packaging · GitHub)

Erggg. Although I did get a couple of kde packages into chum, kaidan killed me. I will never do this kind of packaging again. BUT, that’s just because I’m not using docker as @rinigus is. If I were, I would probably have an easier time of it.

So were you stuck on a packaging issue?

[nephros]

@poetaster

So were you stuck on a packaging issue?

No, just lack of direction (and interest ;), or “time to spend on hacking”). Hacking other apps seemed more rewarding.

qtquickcontrols2 where the theming lives was already packaged from the qt5.15 chum project. Haven’t looked at Kirigami at all yet. Also my main phone is still on 4.4 and getting Qt5.15 on there is a bit of a hassle, and it has graphics problems there.

[poetaster]

Ok, got it. Stick to 4.4. The browser still works. sort of From an initial view (ktrip, I think) I didn’t come away thinking I would spend much time on kirigami.

[ichthyosaurus]

@poetaster

@ichthyosaurus

Yeah, I think we’re in the same boat… I think we desparately need something like the KDE Free Qt Foundation but with Sailfish/Silica/etc.

Maybe some work for the sailmates association? @jojo @vlagged Maybe some Opal project sponsoring?

I actually wanted to suggest that back when you guys were still planning the new organisation but then “real life” happened… I also think Sailmates should use gold doubloons if they sponsor things, would be fitting the theme (And of course I’d be open for something like that, I think it would make sense if the project gains traction.)

@poetaster

completely separate QML for the different platforms. That means more work, but with careful design, not necessarily so much more.

Well, my apps aren’t that carefully designed, I’m afraid . Building two different GUIs would be painful…

@poetaster

If I was able to get a number of apps running on IOs, for instance, I might actually be able to finance the work

That is a really good idea! On the other hand, iOS has a very different approach to GUIs and you would definitely have to write everything twice. I don’t think theming like @nephros tried would be enough…

@poetaster

@ichthyosaurus

Opal builds on top of Silica and should aim to look good and provide high quality code for Sailfish.

Ok, that’s what I thought. But it means that the licenses could be a hindrance for use on Jolla’s side and that would be a bit sad if the work proves of wider utility. That was what I was getting at.

That hindrance is kinda the point, though. I’m working for a community, not for Jolla - if they want to use my code they can either employ/pay me, or they open up their code so that everyone benefits. That sounds a bit radical but to be honest I think it’s fair.

Of course that only applies to my code. I don’t want to pressure anyone to be that strict with their licensing when they’re working on Opal.

[poetaster]

@ichthyosaurus

GUIs and you would definitely have to write everything twice.

No, not really. Mostly just container classes/views. Obviously, using Theme and icon resources are something one has to avoid, but that can be done and still ‘fit’. But it takes some planning. At the moment I’m working backwards on that front. :_)

@ichthyosaurus

That hindrance is kinda the point, though. I’m working for a community, not for Jolla - if they want to use my code they can either employ/pay me, or they open up their code so that everyone benefits. That sounds a bit radical but to be honest I think it’s fair.

My take is that if opal produces enough value (lots of widgets. lots), then the value of the closed parts changes it’s value in proportion. But, if Jolla is keeping the licenses as is because of the mercedes benz entertainment system (a guess), then we are doomed

[vlagged]

Great job on starting this effort to consolidate useful components around our apps!.

@ichthyosaurus

I think we desparately need something like the KDE Free Qt Foundation but with Sailfish/Silica/etc

I was not aware of this and I think it is fascinating (including the fact that they have two Trolltech advising members). For those who haven’t the time to read the whole page, sounds to me like it’s a legal agreement between the foundation and every Qt owner since 1998 Trolltech, to make sure that the Qt remains available and properly licensed…

I was going to say that maybe the first step to be in a similar situation would be to… well, have Silica “available and properly licenced”, and of course I found the Dec 2020 community meeting question and the answer… Maybe it needs a recurring community meeting question.

Regarding the ping:

@poetaster

Maybe some work for the sailmates association? @jojo @vlagged Maybe some Opal project sponsoring?

We haven’t yet started acting with actual expenses from the membership fees and donations, but this should be on our radar and I’ll raise the point internally too. Maybe this also fits a potential funding application Sailmates can apply to.
(Personally I also had a couple of month of hiatus (“real life happens” +/- other SFOS related work) but I plan to get back on track shortly.)
(btw, Did you know you can just ping @sailmates for these kinds of ideas?)