User-contributed APIs/Components/Utilities

Applications
#1

Related to the recent and very welcome discussion about most-needed and missing APIs in Harbour…
Wouldn’t it be nice if we had somewhere to pool the efforts that already exist with making reusable components as part of normal app development? (For things that on their own does not warrant their completely own project)

Example: i made this little hack to check check for WiFi connectivity, and what SSID the phone is on.
(kudos to Slava for the concept)

It certainly needs another pass of refactoring to be clean enough to be properly reusable, but still, i could see others wanting to use the same functionality. (and it’s just an example)

I’m thinking something along the lines of a “staging” repo which can include things that seem reasonably stable and that several people agree are useful… And in time there could be a “stable” repo, where apart from having stabilized, the components are deemed good for inclusion in the default SFOS installation, blessed for inclusion in Harbour, etc.

Stuff from the “staging” repo would have to be shipped with each app, and this could be community-curated as to not put too much extra work on Jolla. I’m even thinking whatever community forms around this effort could take a few things of the API-wishlist (where it is more to do than just packaging) and contribute… I’d be up for that at least.

Opinions? Am I being naive?

7 Likes
Opal QML components for app development
#2

Great Idea!
Even if it will only be a place of finding sourcecode solving common problems. So anyone can fork this snippets into his projects. But a common place for that “reuse components” would be a super sweet spot.

#3

There is. @Mister_Magister and @ichthyosaurus created a repo for exactly this purpose. Maybe contributions will gain momentum now…

3 Likes
#4

Yeah, if anyone wants to join our repo, feel free to contact either of us cause work kinda stopped

3 Likes
#5

Good start though! The name might need changing again if it grows, but that’s not a big problem. :slight_smile:
I have some time the next few days, so let’s get started talking about this.
I’m thinking we need to decide on structure (i was thinking all qml components go in the same repo etc) and maybe something on licensing (i was thinking this is for small stuff where permissive licenses makes sense). Governance can come organically i hope…

2 Likes
#6

Sounds great. I think, to make it useful, the most important point is to maintain a good structured readme.md, so that people can see easily and fast if there is a fitting solution in the Repo or where to contribute. Probably this is the most crucial point to have a good structure all over the Repo.

1 Like
#7

Pretty-sfos doesn’t matter much, the main name is opal.

License is GPL-v3/wtfpl/beerpl but mainly GPL

Qml components in same repo, no. There are 2 projects, opal-about which is component and template for other components so if you wanna add anything you create the same project as opal-about, it’s made to be a plug and play in project.

Opal project is like silica gallery app, that will present all the components in one app

#8

Hmm? That is not what is linked above, or? So where can i find that?

#10

Both projects are still private because I wanted to fix a few quirks before making it public. Development has not stopped but I’m stuck with two issues that have to be solved before releasing it. Maybe one of you has an idea how to solve them…

The idea is to have

  1. stand-alone components (QML modules, plugins, and resources) that can be either installed as separate shared packages (not Harbour-compatible) or directly included in a project (allowed in Harbour)
  2. short code snippets that can be used/adapted for projects, as a extension to the official docs
  3. “recipes” that explain how to solve more complicated problems

For 2. and 3. we can use a Wiki. 1. will be one code repo per component.

(@Mister_Magister correct me if you don’t agree ;).)

1 Like
#11
  1. i don’t think we would compile it into one big lib cause everyone is going to include them in project anyway cause most of people target jolla store

but yeah, i dropped icons for anyone to use so thats like snippet lol

Also @ichthyosaurus should we add @attah to our repo?

1 Like
#12

The two problems are how to properly and easily include components and translations in a new project. I want to find a way so the user only has to include one line in their pro file and would then be able to write import Opal.MyModule 1.0 in QML. This is possible when we’re installing modules to the system location (/usr/lib/qt5/blabla or something like that). For Harbour compatibility we have to include all files in the project’s data directory, though (/usr/share/harbour-foobar)…

Then there’s translations: we have to find a way to provide ready-made translations with our modules so users won’t have to re-translate everything after including a module.

#13

@attah I can add you, if you want. But the code is not quite ready yet. If we want to provide examples (and documentation) then we have to provide the best quality we can :).

3 Likes
#14

I agree, it has to be extremely pita-less. We could later on put those components in QPM so that with one command people would have them installed

#15

good idea, yes [20 chars]

#16

Nice, I’d love to take a look!
The reason i suggested one repo (at least for all the small stuff) was indeed for ease-of use. It doesn’t mean it would have to be packaged or included as one big blob - that should still be on an as-needed basis, just distributed. (And afaik there is no PR process for adding whole repos)

But before i have seen how it is currently, i should really not push that as a strategy… there may be better ways to do it.