I think I understand that PA.c apps are meant to be launchers for other embedded apps.
However, while writing my first PA.c app, I am also writing the app itself. I have no intention of releasing a non-PA.c version of the app, so there's really no point to me as a developer to have to embed a simple app with a launcher when I could just put the app as the launcher.
If someone really wanted to use the software without PA.c, I might just offer a .zip they could put wherever they like.
Is this allowed? Does it violate some underpinnings of PA.c that I'm not aware of?
I'd like to keep this app as simple as possible without excess and unnecessary layers.
One of these layers would be the removal of all the Launcher stuff that's included with the Application template, since it's not really being used.
Thanks!!
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
A lot of applications are not fully portable by default, which is what the launcher is for.
That will handle handling of file/registry changes which otherwise would be left on the host machine.
It is good practice for the application to do those itself, so feel free.
The launcher is more a tool to add features the application does not have by default rather than a necessary route to go about some of those.
If at first you do not succeed, use more sticky tape.
If you want it released, stick to the format.
There are a few apps here that are already 100% portable, but they are still made to spec with the app in the App\AppName folder.
The overhead of the Launcher is minimal, plus for future potential features of the Launcher, Platform, Backup utility or some yet-to-be-developed part of the PortableApps world you are better off sticking with the spec.
I'm on board writing the folders and such to match the format specification, but do I really need all the Launcher stuff from the application template if I'm not going to use it?
Thanks!!
Michael D. Shook
The only real difference with having your app in place of the launcher is it would allow you to exclude the launcher.ini (which for an already 100% portable application is 3 or so lines and less than 1Kb in disk space) - most of the other stuff is still required to correctly show the app in the Platform's listing and integrate with the Updater & Backup utilities.
If your app can in any way use command line parameters you also prevent users from being able to permanently customize them by copying the AppNamePortable.ini from Other\Source to the app install directory, unless you specifically code your app to process this file if it is found there (which, as a programmer myself, would be more work than just generating the Launcher the normal way).
So it's not that removing the launcher that's the issue, it's more around the abilities of actually using this website for updates and other features. Which I definitely want my potential users to have.
To recap, even though my little app is just a little app and only intended for portable distribution, it is that very quality that requires me to write a little app, then portableize it?
Is this the approach you took with the dotnetinspector you wrote?
Thanks!!
Michael D. Shook
Yeah, don't think about it so much as redundantly making an already portable app portable. It is more about extending the functionality of your app with benefits that the PortableApps Launcher and other tools already provide.
dotNETInspector was originally kind of an accident that came about from me finding some C++ code while researching for a post about the Launcher doing .NET detection. I had not thought about releasing it here while I was working on it - it was more just me dabbling in C++ until I realized I had something that might be useful to somebody here (its acceptance as an official release has surpassed all my original ideas/expectations).
But you may find that your future development is slightly altered by thinking about the PortableApps format during development instead of afterwards. In the next version of IPFinder I've added a command line parameter to set where the text logs will be saved instead of handling it with a [DirectoryMove].
I see what you mean about rethinking the structure that way. It also occurred to me that at some point I'd want to parametrize the location of the data file.
Thanks!!
Michael D. Shook