Hi Martin, On 02/06/18 02:05, Martin Kolman wrote: > Fri, 1 Jun 2018 09:53:10 +0100 David Llewellyn-jones: >> On 01/06/18 09:07, rinigus wrote:
[snip - discussion about multiple executables in a Harbour package] >>> >>> I understand, its a sport in the beginning. There is a simpler solution >>> - you can always release a fart app for getting into the store :) >> Yes, unfortunately "not releasing a fart app" is also one of my life >> goals :) >> >> I make light of it, but it's actually more than a sport. I submitted my >> first app back in 2014 and I'm still trying. Developers are held back by >> Harbour's restrictive policies and lack of support for payment, while >> user adoption is held back by lack of apps in the store (or so people >> say). Anything that increases the quantity of quality docked apps in the >> harbour has to be a good thing. >> >> At the same time, the Harbour rules should represent a checklist of >> good-practice for developers, >> > While in some cases the rules are clearly understandable, > such as mandating that developers use only external libraries > with known stable API so that applications remain working > in the future. > > In other cases I think the rules are detrimental to the overall application > and packaging quality, such as: > > - you have to cram everything, including any external dependencies, > into a single package, which is the direct opposite of good Linux > distro packaging practices I suppose this is tied up with the fact developers can only use a restricted set of external APIs, all of which are part of the default install. So, while I agree this is restrictive, doesn't it make package curation much easier, avoiding situations where one person updates a package and causes some other app to break? > - no RPM scriptlets are allowed, so code that would run once to handle > any local data migration and similar tasks will have to run at every > application start rather than once at package update as on normal > Linux distros This is presumably for security reasons, since the RPM scriplets will run as root, which no app is allowed to do. Can the RPM scripts be set to run as the user? If so, I can't see any reason why this shouldn't be allowed. > - Harbour applications still (AFAIK) can't use such basic functionality > such as assigning custom actions to volume buttons, keeping the > device screen on or temporarily inhibiting device suspend to keep > important background tasks running without interruption Perhaps this is a consequence of the lack of permission-based access control on Sailfish? So, maybe Sailfish 3 will provide some respite if it's due to have a a proper permissions system. I would dearly love to have background tasks, and the aggressive halting of background processing restricts a whole class of apps. I can understand why Jolla enforce it though. iOS has a similar problem (although Apple provides various esoteric APIs to try to get around it without impacting battery life). > - socket activation is no longer allowed, which effectively removed > OSM Scout Server, the best provider of offline mapping services > on any mobile platform currently in existence from the Jolla Store > and thus from many potential users What's the reason for this? Is this related to the restriction on background services? It sounds particularly unfortunate. > - applications can be submitted as binary only, there is no option > to submit application source to be built on trusted build infrastructure, > so users and store QA have to believe developer the application actually > is built from the given source (if any) and actually does what the > developer claims it does Yeah, this is really strange. I can understand some developers being unhappy about supplying their source for commercial reasons, but why wouldn't Jolla accept it as part of the review process if a developer is happy to? > In the end I ended up with two versions of the modRana package, > one that's full featured and goes to OpenRepos and another one > cut down & hacked to hell to pass all the Harbour hoops. I see modRana on both stores. What were the changes you had to make? > And that's just rule/process induced badness, if we compare Jolla Store > with OpenRepos or some Linux distro repositories on features: > > - Jolla Store lacks any web interface, people without a Sailfish OS device > can't check what apps are available & you can't send people links pointing > to apps in the Jolla Store Right, I fully agree. Even if Jolla just made available a cut-down read-only version of the "Your apps" page on Jolla Harbour, it'd be a great start. > - developers get no notification about new comments from users (yes > really), Yes, again, you'd have thought this would be straightforward to implement. > you basically have to keep checking manually in the app, the app is > also the only way to > write and reply to app comments > - it's impossible to install an older version of a package from Jolla > Store (OpenRepos & Linux > distro repos can generally hold multiple package versions) I'd add to this the ability to pay for apps. I know Flattr was added and removed, but I didn't follow the story at the time. It seems many developers really just want a simple option for payment before install. Maybe the blockchain support in Sailfish 3 will provide the solution ;) >> so I like to follow the guidelines if I >> can, even if my app will never be accepted. I assume there's a good >> reason for all of the rules :/ I'm not sure what the reason for >> restricting multiple binaries is, though. > > Yeah, that sounds pretty arbitrary. Restrictions like this should all > have good reasons > specified in the documentation, or should not be there at all. Yeah, I totally agree. I'm sure most of these points have been discussed to death here or on Together, but having the details in the documentation would at least provide somewhere that someone like me could be pointed at. I notice the Harbour backend isn't in the Sailfish Github repo. Has anyone asked for this to be opened up, so that people can help address some of the deficiencies? Cheers, David -- Website: http://www.flypig.co.uk _______________________________________________ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
