Opal QML components for app development

[poetaster]

@vlagged

(btw, Did you know you can just ping @sailmates for these kinds of ideas?)

Errr, as a member, I suppose I should have known

[ichthyosaurus]

@vlagged

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…

Exactly, and even though the Qt company regularly tries to get out of the deal (so they can make Qt fully commercial), they can’t - which is a great win for software freedom.

@vlagged

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.

right you are… Maybe sailmates could do something about that?

@vlagged

Maybe this also fits a potential funding application Sailmates can apply to.

NLnet just funded Whisperfish, maybe they are interested in other Sailfish things as well…

[poetaster]

@ichthyosaurus

NLnet just funded Whisperfish , maybe they are interested in other Sailfish things as well…

Now, that’s why I didn’t get any funding !

[pawel.spoon]

i have included Opal delegates and drag drop in Tidal Player

[ichthyosaurus]

Nice to see Opal being used in apps That’s always a nice motivation to finally do some maintenance chores. I have quite a backlog of changes and contributions from others piled up. I hope I’ll get to clean that up sometime around the holidays.

[nephros]

Thanks for reminding me that I really should be using Opal more.
It’s a wonderful effort, thank you so much for it!

One thing I would love though is if I could depend on a system installation of Opal instead of copying it to every app project.
Is is feasible to make Opal Components installable as qml module/plugin?

I realize that is not going to fly with Harbour, but for non-harbour apps it would be very nice.

(…and who knows, maybe it could get accepted as a special exception dependency in Harbour as well - times seem to ve changing - a bit!)

[poetaster]

Looks like tidings will soon have Opal components @ichthyosaurus needs to review one PR but it’s looking like a done deal. Now I have to fix the performance issues. Sigh.

[poetaster]

There is a concern I have:

```
ERROR [qml(Opal.About)] 'Provides: qml(Opal.About)' not allowed in RPM
ERROR [qml(Opal.About.private)] 'Provides: qml(Opal.About.private)' not allowed in RPM
ERROR [qml(Opal.LinkHandler)] 'Provides: qml(Opal.LinkHandler)' not allowed in RPM
ERROR [qml(Opal.LinkHandler.private)] 'Provides: qml(Opal.LinkHandler.private)' not allowed in RPM
ERROR [qml(Opal.SmartScrollbar)] 'Provides: qml(Opal.SmartScrollbar)' not allowed in RPM
FAILED
```

Does using opal mean I can't update the app in harbour?

EDIT. This has sort of ruined my Friday night.

[nephros]

You can hide the provides with some RPM macro right? Should be in the Harbour FAQ.

%define __provides_exclude_from ^%{_datadir}/%{name}/qml/lib/.*$'

or so.

[ichthyosaurus]

Sorry, I was at a Christmas concert so I saw your cry for help only now. The fix is simple, adding this to the spec file is enough:

%define __provides_exclude_from ^%{_datadir}/.*$

I created a pull request here: Fix Harbour compliance by ichthyosaurus · Pull Request #113 · poetaster/tidings · GitHub

@poetaster

EDIT. This has sort of ruined my Friday night.

I’m so sorry! It’s totally my bad, I lost the commit when I created multiple branches for multiple pull requests, but I had the change locally so I didn’t notice it during testing.

@nephros

You can hide the provides with some RPM macro right? Should be in the Harbour FAQ.

Exactly. It’s also documented for Opal here: GitHub - Pretty-SFOS/opal: A collection of pretty QML components for SailfishOS

4. Configure your spec file to be Harbour-compatible (cf. Harbour FAQ #2.6.0).

Using YAML: add the following section to rpm/harbour-my-app.yaml (from which the spec file is generated):

 Macros:
 - __provides_exclude_from;^%{_datadir}/.*$

Using SPEC: you can also add this directly at the top of the rpm/harbour-my-app.spec file:

 # >> macros
 %define __provides_exclude_from ^%{_datadir}/.*$
 # << macros

[poetaster]

@ichthyosaurus

I’m so sorry! It’s totally my bad, I lost the commit when I created multiple branches for multiple pull requests, but I had the change locally so I didn’t notice it during testing.

Ah, it’s ok. I was just trying to push things before the xmas madness takes complete control. Working on too many things at the same time. I’m doing the release now.

Thanks! and happy holidays!

[ichthyosaurus]

@nephros

Thanks for reminding me that I really should be using Opal more. It’s a wonderful effort, thank you so much for it!

This reminds me to remind you that you made the Delegates module ;). Thank you! I changed it a bit, maybe it’s worth checking out again for your apps :).

@nephros

One thing I would love though is if I could depend on a system installation of Opal instead of copying it to every app project. Is is feasible to make Opal Components installable as qml module/plugin?

Technically, that should be possible and of course it would be much better than duplicating everything. I haven’t really looked into it yet, though, because it wouldn’t be allowed in Harbour. That’s a project I’d need a lot of help with, just as with switching to cmake, etc. I’m not good with packaging…

@nephros

(…and who knows, maybe it could get accepted as a special exception dependency in Harbour as well - times seem to ve changing - a bit!)

That would be awesome of course :). But then we’d need a team for maintenance, I already don’t have enough time and energy to properly maintain Opal, apps, patches… Chores are getting out of hand. I spend more time with that than with actual development :/.

[ichthyosaurus]

@poetaster

Ah, it’s ok. I was just trying to push things before the xmas madness takes complete control. Working on too many things at the same time. I’m doing the release now.

Thanks! and happy holidays!

I’m glad it worked out, these things always happen at the worst moment. Happy holidays too!

[nephros]

@ichthyosaurus

That’s a project I’d need a lot of help with, just as with switching to cmake, etc. I’m not good with packaging…

@nephros

(…and who knows, maybe it could get accepted as a special exception dependency in Harbour as well - times seem to ve changing - a bit!)

That would be awesome of course :). But then we’d need a team for maintenance, I already don’t have enough time and energy to properly maintain Opal, apps, patches… Chores are getting out of hand. I spend more time with that than with actual development :/.

I hear you!

Collaborating more between devs is something we should focus on in the future IMO. Currently it seems there’s a lot of soloing in our rather small dev community.

[ichthyosaurus]

@nephros

Collaborating more between devs is something we should focus on in the future IMO. Currently it seems there’s a lot of soloing in our rather small dev community.

Absolutely! But getting collaboration rolling, coordinating, etc. is yet another task and who has time for all this

[ichthyosaurus]

Question to everyone using Opal in their apps:

Currently, all Opal modules are minified for release, which makes the code very hard to read and audit. Since the hostile fork of Whisperfish I was wondering how to improve the trustworthiness and auditability of our apps.

I added Opal modules to some apps in very large, very unreadable, and practically unreviewable PRs. Some got merged, some didn’t, which I totally understand - no one can review hundreds of lines of minified code. At least one developer was annoyed about the missing whitespace, which I also totally get.

The reason for minification is that it makes Opal smaller and thus increases performance slightly but arguably measurably. (I don’t have the numbers anymore because I tested it years ago when I started with Opal. I know this doesn’t improve the point of keeping minification ;).) Less code also means smaller packages which means less resource use for storage, transfer, and on devices.

All original, non-minified sources are of course available: GitHub - Pretty-SFOS/opal: A collection of pretty QML components for SailfishOS · GitHub Only the release bundles are affected, e.g. opal-about [I plan to move everything to Codeberg soon™]

Do you think it makes sense to keep minification or should I switch all releases to ship the original non-minified sources?

• keep minifiying
• ship non-minified code

[ric9k]

I’m not dev at all.
So, no idea if this simple remark has any interrest, but just in case:

As XA2 user, minification seems interresting, as it is an old and slightly weak device.

As a future J2 user, that wishes to (be able to) verify sources, I’d feel more comfortable with more readable code, betting that modern devices have enough power to compensate the light overweight due to non-minification.
Hope this is not too off the mark

[ichthyosaurus]

Both are good points.

When I started Opal, I was working still with an Xperia X. The first module was Opal.About and I compared the code size to a simple handwritten “about” page including the full GPL license text. My goal was to keep the size of the new module equal. Maybe that comparison just doesn’t make sense anymore today.

[ric9k]

Is it complex/long to switch from minified to non-minified or reverse?

[ichthyosaurus]

I don’t think so. I already added a switch to Opal’s release/build script to disable minification a few years ago, but I would have to verify that it still works properly because I haven’t used this option since…