I am building a HTML/JS/CSS application that I would like to distribute packaged either as a NW.js or Electron app. I am new to both, and have read that the packaged executables can be quite large. Since the application would be free, I find that the cost of distributing it from a CDN to be too high.
I was wondering if there was any installer that allowed the "standard" parts of the executable (the Chrome components, etc.) to be downloaded as a shared library from a free CDN, as part of the app's installation / first execution?
With either one, you could host the packages on Github using the "releases" feature, which is free. This is a common approach for a lot of open source Electron applications.
Here are some examples of this being done:
yoda
Caprine
Here is the official documentation on Github releases.
There is a module for Electron designed to make this easy called electron-gh-releases.
Related
electron-builder and its electron-updater dictate that program must have semver
https://github.com/electron-userland/electron-builder/blob/v23.0.3/packages/electron-updater/src/AppUpdater.ts#L331
electron's default autoUpdates does not support linux
electron-updater will only work on macOS if code is signed
yet golang's .mod and clojure's deps.edn - clearly show that using source directly without intermidiary pa like npm or maven is a growing trend
question
how to release electron program as files - what electron-builder calls dir and zip targets?
how to auto-update by simply looking at github tags and downloading the new version of files and replacing them?
does such file-based no-singing any-url solution already exist?
change heavy electron for light entirely jvm clojure .jar dekstop programs with swing ui
one .jar for all operating systems by design
lack of powerful web ui is not an issue - as programs do not need the most powerful ui - swing is plenty to connect user to data and to render on canvas
I was working through some autoUpdating changes on an app of mine, and I ran across the following
Electron Native - https://www.electronjs.org/docs/latest/api/auto-updater
Userland Electron Updater - https://www.electron.build/auto-update
It seems that these two APIs are very similar, but not identical. I can't seem to find any information on what differences there are between the two and which one is the "preferred" way to do seem less Electron updates?
https://www.electron.build/auto-update
Differences between electron-updater and built-in autoUpdater¶
Dedicated release server is not required.
Code signature validation not only on macOS, but also on Windows.
All required metadata files and artifacts are produced and published automatically.
Download progress and staged rollouts supported on all platforms.
Different providers supported out of the box (GitHub Releases, Amazon S3, DigitalOcean Spaces, Keygen and generic HTTP(s) server).
You need only 2 lines of code to make it work.
I have been searching the internet but I couldn't find an answer. I just want to find out if I could use the built HTML.
To make things clear. I created a vue-CLI project. I created a built HTML by running an npm run build.
Running the npm run build will create a dist folder with an index HTML, and its needed resources.
Now I would like to add this in electron. Is this possible?
If your project is client-side html only, then it is ready to go: just use one of the minimal Electron examples, and set your index.html as the start page.
If it is connecting to a back-end server (e.g. to access a database), it can still do that, but it means the application won't be able to run offline.
It is worth considering why you want an Electron app, instead of just having a web app. E.g. Are you hitting any security restrictions or other limitations of a web app, that a desktop app does not have? If not, packaging as an Electron app might just be effort spent on something that no-one wants or needs.
As you've built with vue-cli, it might be worth looking at Quasar Framework which is a wrapper for Vue that comes with Electron and Mobile targets ready to go. You don't actually have to use any of their UI components to get this.
There is any way to submit to the App Store an Qt Quick Controls application
under LGPLv3 license without violating App Store rules?
What i want to do is to deploy my app on iOS store using a dynamically linked version of the Qt libraries.
I tried to find an answer in every forum but seems very difficult.
Any suggestion is very appreciated.
Thanks in advance.
App Store does not care which license you use. It is the users of your application and the Library authors who care. The main point of the LGPLv3 license is that the end users must have the possibility to replace the library with their own modified version. This is very important to understand, dynamic / static / everything else is just distracting.
Let's move to Qt. It is available with LGPLv3 license on major Desktop (Windows, OSX, Linux) and mobile (iOS, Android) operating systems. Suppose you develop an application and want to keep your source code closed. On the Desktop you can link dynamically to Qt libraries. When the end users install your application, they can replace Qt libraries in the following way:
Compile their own version of Qt libraries
Navigate the the location where the application is installed
Replace original Qt libraies that were shipped with your applicatoin with their own modified versions
Looks easy, right? The main goal of LGPLv3 is achieved. The user can replace libraries.
Moving to the mobile platforms, starting with Android. Even though you link dynamically to the Qt libraries, we now have a small problem. The user can not navigate to C:/Program Files/YourApp and replace Qt libraries, because it's Android. Rooting is not an option, since it doesn't work on every device (and might not be legal). Remember, the main goal of LGPLv3 is to give the users ability to replace the library and run the modified version of your application on their device.
Solution? Provide .apk file to every user who installed your application with detailed instructions on how to:
Unpack your .apk file
Replace Qt libraries
Zipalign / pack / signtool to a new .apk
Install .apk with modified Qt libraries
Let's talk about iOS. Many say it is not possible to use LGPLv3 with iOS because of static linking. Wrong. Again, you just need to give the end user the possibility to replace Qt libraries. How? Provide your object files for the end user to relink. Or even better, put all your application code and resources in a separate Qt Quick plugin which will compile in a static library archive (technically just all object files concatenated together) for iOS. Then for every user who installed your application you have to provide instructions on how to replace Qt libraries:
Download project files and object files from your website
Download XCode and developer tools from Apple website
Replace Qt libraries
Deploy application to your device
Before this was not possible because in order to deploy on the device the user had to enroll Apple Developer Program. But this is not the case any more. You can launch your app on a device using a free Apple ID account
The end user rights are protected. They can replace Qt libraries. Just make sure you do required steps:
Mention in your application that you use Qt libraries and also mention you use them under LGPLv3 license. Provide a link to LGPLv3 lincese.
Make sure your setup of replacing Qt libraries work. Set up a clean virtual machine and do everything step by step. Document it for the end users.
When the users who downloaded your application want to replace Qt libraries, provide them everything so they can do it.
Actually I don't think anyone would care. But you have to be ready just in case. Do not scream you use Qt LGPLv3 on Qt forums, but make sure you have it visible somewhere down in your application's "About" screen. Qt company does not have resources to scan every application from the App Store if it uses Qt or not. Neither they will touch you if you are a small-near-zero-profit. They have more important things to do.
It is very dissapointing however to see absolutely no help from people who work in Qt on the LGPL subject. Most likely all developers were instructed to answer "IANAL, please contact our legal department". The legal department will tell you - buy our commercial license, it's the only option. On the Qt website you can find Obligations of the LGPL. I am not surprised, there is no word about static linking and providing object files for re-link on this page. Qt company simply prefers not to tell anyone it is possible.
From my point of view LGPL was a huge step which enabled a lot of application to use Qt without disclosing their source code bringing huge popularity to Qt. Not to mention Nokia was the one who sponsored Qt on Mobile first (Symbian and then MeeGo).
Also thinking about MeeGo and Blackberry, there was no problem with developing closed source mobile apps that use Qt and publishing them in respective app stores. No commercial license needed.
Update:
This has been done before. LGPL is possible with static linking and App Store. https://news.ycombinator.com/item?id=4302517
In case the question gets closed as off-topic, I copied the answer here
https://opensource.stackexchange.com/questions/6463/in-2018-if-i-use-c-qt-5-10-0-to-build-a-closed-source-application-requires-ope/6495#6495
Yes, it's possible.
You can use this Qt app template:
https://marketplace.qt.io/products/qt-lgpl-app-template
On IOS it's impossible to relink the App, so it's LGPL V3.0 incompatible (user can't replace Qt libraries)
But this template generates a redistributable .zip Qt project on every rebuild.
Their entire private project is distributed in a compiled .a library, so a user can open project in Qt Creator, rebuild their application and load it on their ipad / iphone, and your source code stays protected
Note: If you are using the qtquick compiler, you must relink it to the same version of Qt.
This .zip file can be uploaded to your own URL or you can add it to your software resources.
You can use the same template in an Android app, a static Windows app, etc.
It's the same as #psyched says, but 100% automatically.
Apache Maven is a very popular build and dependency management tool in the Java open source ecosphere. I did some tests to find out if it can handle compiled Free Pascal / Delphi units and found it easy to implement. So it would be possible to
release open source libraries precompiled for Free Pascal (or Delphi) in a public Maven repository
include metadata in this repository which contains dependency information
use Maven on the command line to download the open source library from the public repository, and automatically resolve all dependencies
local repositories, working as proxies, could be used to cache frequently used binaries
automatic checksum generation and verification (provided by Maven) would reduce the risk of downloading corrupted binaries
source code and even documentation files could be provided with the binaries
binaries can be provided with or without debug information
continuous integration servers like Hudson, TeamCity or CruiseControl can be used to build projects whenever changes have been submitted to the source control system and notify developers about build errors
This way of dependency management could be very beneficial for open source projects which use many third party libraries with complex dependencies. It would avoid typical conflicts caused by using wrong versions.
For the developer, the workflow for editing and building a project would be reduced to a minimum:
checkout the project source from internal version control system
edit source file(s)
run mvn package to automatically download all required third party libraries (precompiled units) if they are not yet in the workstation's local repository
compile and run
The only additional file for Apache Maven which is required in the project folder is the POM.XML file containing the project information.
Edit: while Maven is usable for some of the required tasks, implementing a solution like Maven in native Free Pascal would have some advantages: no Java SDK required, support for all development platforms where Free Pascal is available, maintenance and plugin development in Pascal.
Usage of a Maven-like tool would not be helpful for open source projects only - commercial projects could access and use the artifacts in public Maven repositories in the same way as well.
Maven features are listed at http://maven.apache.org/maven-features.html
Update:
one use case could be the build of Lazarus, where Maven would download all required libraries and invoke the compiler with the necessary build path arguments. Changes in the dependencies on lower levels would be propagated automatically up to the parent build.
Possible benefits:
less time needed to set up a new work
station, no manual installation of
third party libraries required
less errors caused by wrong library
versions, detection of version
conflicts (for example if two
libraries depend on different
versions of a third library)
artifacts which are created inhouse
can be added to the local maven
repository and shared between
developers and project, central
storage of all artifacts with
metadata
builds are reproducible, just by
using the same source and project
metadata file (pom.xml)
can reduce development time and
increase project stability
Update #2: FPMake
the FPMake build system for Free Pascal seems to be a tool with much potential, in many details it is quite similar to Maven:
FPMake is a pascal based build system developed for and distributed with FPC
FPMake standardizes the building by defining some limits like standard directories
the command fppkg <packagename> will look in a database for the package, extract it, and then compile fpmake.pp and run it
it has standard build targets (clean, build, install, ...)
it can create a 'manifest' file suitable for import into a repository (like mvn deploy or mvn install), the manifest is an XML file which looks very similar to a pom.xml in Maven:
FPMake manifest file:
<packages>
<package name="my-package">
<version major="0" minor="7" micro="6" build="1"/>
<filename>my-package-0.7.6-1.zip</filename>
<author>my name</author>
<license>GPL</license>
<homepageurl>http://www.freepascal.org/</homepageurl>
<email>myname#freepascal.org</email>
<description>this is the package description</description>
<dependencies>
<dependency>
<package packagename="rtl"/>
</dependency>
</dependencies>
</package>
</packages>
Freepascal has been working on a package system of its own in a cross between apt-get and freebsd ports style. (download source/build/install automatically), called fppkg.
However work has stalled. People investing time are the bottleneck, not people wanting to choose tools.
As far as Maven goes, I don't like auxilary tools that need installation of huge external runtimes. It might be fine for a big major app (like Open Office), but not for an util.
I also prefer a tool that is designed to the FPC reality and workflow.
Documentation tools, build tools, download systems, testsuite systems are already all there, it just need a person that dedicates a lot of time into it to make it happen.
Some typical problems when introducing a new technology in a project as FPC, and why it has a tendency to make its own tools:
need to train 20+ committers in parttime.
The only COMMON programming language you can assume is Free Pascal. Even Delphi inner workings can't be taken for granted to be known (many committers came directly to FPC or even still via TP or a Mac Pascal)
Obviously that makes something with plugins in a different language annoying.
Bash script is a close second. (g)make third, but already a magnitude less.
All servers are *nix-like (FreeBSD, OS X, Linux), but not all run Apache. (e.g. my FreeBSD mirror runs XSHTTPD)
somebody most knowledgable must be dedicated maintainer for a long time. Fix problems, update/ do migrations etc. Perferably more than one for obvious reasons.
a major pain are Linux distributions (and FreeBSD to a lesser degree), most maintainers of *nix packages are not capable of more than "./configure;make;make install", and must be spoonfed with a near buildable repository and auxilary files.
In-distribution packaging of FPC/Lazarus has always been important, and is still increasing
All distributions have their own special rules about metadata, depedancies, and how sources must be published. Particularly Debian/Ubuntu is very bureaucratic and slow.
Most don't like third party auto-installers on top of their systems (since that bypasses their dependancy control)
This all leads to the effective practice that own tools in Pascal with minimal scripting work best. Some tools used:
Gmake is mainly used to parameterise the build process on a per directory level, a successor, fpcmake (not really a make derivative despite the name) has begun, but the migration hasn't completed.
Latex and a latex to html conversion (tex4ht, but debian uses hevea) are used in the documentation building (the non library documentation)
The community site (netscape community server which uses TCL scripting, a heavy complex application server) has been a trouble ever since it started, but specially lately since the maintainer became less active.
Mantis has been a problem (specially the email module would crash or lame the server due to the volume), but it has been whipped into shape during successive updates and hard work of several lazarus devels. Currently it is a decent workhorse.
lazarus.freepascal.org PHPBB forum OTOH is relatively painless since a lot of younger people know how to deal with it.
The same goes for subversions (though the more advanced scale needs some adjusting, not everybody is deep into the ins and outs of mergetracking)
If somebody was really serious about Maven, I usually would ask him:
to CRITICIALLY investigate the use for the project. In a very concrete way, with schedule and time estimates. Birds-eye level "everything's possible" overviews are essentialy worthless.
Give some thought on future change of used technologies. Every technology is eventually replaced, even the in-house ones, in 18 year+ projects. A new technology must not make migrations of other infrastructural components hard or involved. The new technology to end all new technologies doesn't exist.
Make a migration plan. Migration is often underrated and underestimated.
And in the end, there is always the 1000000 Euro question, who will do the daily maintenance?
Keep in mind that in a company you just kick the person responsible for the application server. But in an informal environment this is way harder, specially long term, since people's lives, occupations and time spent on the project vary.
Sounds like an interesting plan, but the Delphi community (and FPC even more so, I'd imagine!) values libraries as source far more than precompiled libraries. The general consensus is that anyone who uses a binary-only library is a fool, for two reasons: You can't fix any bugs you find in it, and compiler changes will break compatibility.