I'm trying to release a package for my appjs app but there doesn't seem to be any easy way for end users to "just run" the application without a terminal.
Is there anyway to do this that is fool proof?
So I've found an easy way to do this, not necessarily the easiest way but it works.
OSx
I use this bash script to convert my folder to a .app folder (which is all OSx needs apparently)
Windows
and on Windows I use IsTools to create my in/un-staller and shortcuts.
Linux
I've not found an easy peasy way to do this on Linux yet but we don't have a customer base on Linux so it doesn't matter. I have however found this but it seems awefully convoluted. Shan't bother for now.
If you download the distributable for your platform from: http://appjs.org/#download. Then it includes a launch script -- app.exe for windows and app.sh for linux / mac os which launches everything without a console.
There is also an addition to appjs that installs appjs as a platform feature (rather than having the whole runtime in each application you distribute). Using this you can compile your application into a single file which you can then distribute to end users. This functionality is being actively developed and improved. http://appjs.delightfulsoftware.com/. see also screenshot tour for windows: http://appjs.delightfulsoftware.com/win.htm and for ubuntu linux: http://appjs.delightfulsoftware.com/ubuntu.htm.
/Simon
Related
I'm using the brilliant Mac OS X "Packages" to generate an install a .pkg, and wondered how one constructs a shell script to make sure the application file being updated over isn't presently running (which would seem like a Very Bad Idea).
Normally this would be handled by using a pre-install script, or installer plug-in. It's unclear what you plan on doing though if the application is running.
How can I create a single installer package for an OS X binary as well as a few configuration and script files?
Final folders should look like this:
Any help would be appreciated. Thanks.
Installers are great if you want various things to be placed in different spots – app here, documentation there, support files over here, etc. They're also great for providing configurability of the installation experience (optional extras), or hand-holding for an unusual type of installation that the user might not otherwise understand, or extra work (configuration scripts, permissions modifications, authentication, compatibility checking, etc.) that need to run during the installation process. There is nothing wrong with installers, contrary to the answer from #d00dle, although there is also nothing wrong with distributing your app through the App Store, or as a dmg.
For setting up your own installers, I highly recommend a program called Packages (http://s.sudre.free.fr/Software/Packages/about.html). I am in no way connected to it, but I use it to build the installer for an app that I work on. It greatly smoothes the process of making a complex installer, and has an excellent GUI interface.
There's also macOS Installer Builder, which is a CLI you can use to create an installer wizard for your .pkg: https://github.com/KosalaHerath/macos-installer-builder
macOS does not normally use installers. Applications are packaged in app containers with the extension .app. This container is "executable" but you're also able to dig in and see what is inside. This is also the format distributed through App Store.
You can create .pkg or .dmg "installers" if necessary, however this is clearly not something apple aims to be standard. I would advise to use the .app pattern and any scripts needed should be self contained and executed on first run.
You can use .dmg to distribute your application outside of App Store (this is still fairly normal).
macOS also includes a terminal program called productbuild that builds a product archive for the macOS Installer or the Mac App Store. Enter man productbuild into the Terminal on a Mac for the manual page.
I'm trying to use "wine" on MAC osX Sierra version 10.12, wine is version 1.9.19
In the terminal I can launch Windows applications, however its a pain to have to keep typing in:
/Applications/Wine\ Staging.app/Contents/MacOS/wine ~/.wine/drive_c/Program\ Files/HeidiSQL/heidisql.exe
I've searched around for a post on how to create shortcuts/applications to add to the launchpad, but so far none of the information has led me to a working end result. Either the locations of wine is different or it just doesn't work.
I've tried creating an application script:
do shell script "/Applications/Wine Staging.app/Contents/MacOS/wine ~/.wine/drive_c/Program Files/HeidiSQL/heidisql.exe"
But this won't run either.
For anyone having the same problem, in the end I created scripts which reside in my home folder:
Launch vi, create a file called HeidiSQL, insert:
wine ~/.wine/drive_c/Program\ Files/HeidiSQL/heidisql.exe
Save and exit file, grant file execute permissions:
chmod +x HeidiSQL
Launch wine terminal and type in ./HeidiSQL to launch, I then did the same for PSPad.exe:
wine ~/.wine/drive_c/Program\ Files\ \(x86\)/PSPad\ editor/PSPad.exe
I know this thread is a little old but I was just looking for something like this to launch HeidiSQL and I came up with these three solutions which I have tried and all of them work. I am putting my findings down here for it may help someone:
Wineskin (http://wineskin.urgesoftware.com), Playonmac (https://www.playonmac.com/en) and Winebottler
(http://winebottler.kronenberg.org)
Wineskin is a mac app that download and install (and manages, updates, etc) "wine" for you. It then creates a HeidiSQL.app (any name you want with any icon you want - but you need to configure it) around the windows.exe that includes the wine version selected and is completely self contained (does not need wine installed separately). Personally this is the neatest solution and my preferred even though there its a little more technical than Playonmac and similar to Winebottler. You need to read the instructions (which are very good) and you have choices to make as to the wine version to use and to configure the app. Noteworthy is that you need to change the windows version to XP rather than 7 or some buttons won't work.
Playonmac on the other hand is very user friendly. It has HeidiSQL listed on its website as compatible and its almost a single click install. You just select HeidiSQL from the list of programs and it will download everything you need for you. The only reason I prefer Wineskin is that it does not create a true self contained HeidiSQL.app. You can create a shortcut for it in your Applications folder but this will launch Playonmac and the app needs to be installed inside Playonmac. On the plus side, Playonmac will chose all the right settings for you to run the app correctly, the correct windows and wine version etc which is something you need to fiddle with with with Wineskin.
Winebottler again makes an app like Wineskin. The only real difference I could see is that with Wineskin the configuration app is actually part of the package whereas in Winebottler you have to recreate the package each time you make a change. I stuck with Wineskin. YMMV.
I've created software using Filemaker and I have to create an installer.
I already done it for Windows but I have to create one for Mac too. The installer will be able to install the software, install a font and ask the serial number.
Can someone help me?
I think Apple used to (still does?) offer a program with Xcode that was called PackageMaker, but I don't think they still do. It might be available from a previous version of Xcode. I found surprisingly little information about it online.
However, the command line tools that it was based on, pkgbuild, productbuild, and pkgutil , seem to be installed on my laptop running Yosemite with an Xcode utilities installation.
I would check out the accepted answer to a similar question here on Stack Overflow. It looks quite detailed, but I think it's going to be very advanced work to get a successful package created.
The above is what you probably want if you want your installer to use Apple's own Installer app. If all you want is to create an installer that gets the job done, I would probably use FileMaker itself.
Create a FileMaker file that stores your solution within a container field, lock it down with security and scripting, use Export Field Contents to get the solution file and your fonts to the right places, perhaps with some supporting AppleScript that makes use of the command line. Use FileMaker Advanced to package this up as a runtime solution and all the user has to do is double-click the runtime app and you can guide them from there. Once the installation is complete you could even open the installed solution for them and prompt them at that point to enter a serial number.
I have a program that I have developed for mac osx. When the program is run from within Qt creator, a log file and a config.cfg file are created in the myapp.app/Contents/MacOS folder, alongside the executable. This is the correct behaviour, the program needs these files.
When I deploy the app to run standalone (by linking the required libraries using macdeploymentqt tool) the app launches and runs correctly however the log and config.cfg file do not get written to the myapp.app/Contents/MacOS folder and so settings can't be read in.
Is there anyway to get around this? Has anyone encountered this before?
Mitch
osx will likely not allow you writing to your bundle location on installed apps, for security reasons and because it may conflict when multiple users are using your app.
To be cross platform, you could write instead to:
QStandardPaths::writableLocation(QStandardPaths::AppLocalDataLocation)
which resolves to
~/Library/Application Support/<APPNAME>
and
C:/Users/<USER>/AppData/Local/<APPNAME>
or equivalent on windows.
You're never supposed to write to the application bundle, whether on Mac or on Windows. Even on Windows, it will not work if your user isn't an administrator. This idea last made sense on Windows 95 - not even on Windows NT. Don't do it.