Due to the fact that some developers are not satisfied with the PA.c Launcher (I won't name any names, but I don't think it's much of a secret), I propose two (or more if I have missed anything) alternate formats. PortableApps.com Format will of course begin to use the PA.c Launcher when it is released (I'm assuming that was the plan). The two other formats would be:
Custom NSIS Format - Used for packages that use custom NSIS launchers and (optional) installers (the PA.c installer would be allowed*, but so would a custom installer).
Custom AutoHotkey Format - Used for packages that use custom AutoHotkey launchers and (optional) installers (the PA.c installer would be allowed*, but so would a custom installer).
I have not written up the guidelines for these formats (overall I don't think they'd be much different other than the lack of the PA.c Launcher), but they would certainly be developed in such a way that they would both still work 100% with the menu and would also assure quality portable applications (albeit more testing may be required). This would satisfy developers who wish to continue developing their own launchers for whatever reasons they have to do so, but leave intact PortableApps.com's strive for quality. I am willing to work with anyone on the guidelines for these formats, if anyone feels that this is a good idea.
* Depending on how the guidelines are set, the PA.c installer might not be an option.
(Personally, I like the PA.c Launcher and I intend to use it for all my apps. It's easy, and I'm a big fan of easy.)
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
I think that necessity is an important thing. For most applications, the PortableApps.com Launcher will be good. Sometimes though more will be needed - that's why I put in support for a custom segment. As far as I can think, that should satisfy any situation when NSIS can be used for the launcher. As for when a tray icon is needed, yes, AutoHotkey will often be the best way of doing that. The PortableApps.com Launcher should then be optional. There are also times when a launcher of any sort is not necessary - Toucan is the current case in point there. For those people that persist in using fully-coded launchers I think they're likely to find that PAL-based apps will be considered higher priority with testing and releasing, as they're more likely to be stable (I think so anyhow; there may be issues with new users, but all up I think they're less likely to make a mess with INI files than NSIS/AutoHotkey/whatever code), any fixing needing doing will be easier, and they're just easier to test.
Unless it is necessary to use something other than the PortableApps.com Launcher for a given project, we'll be using it for everything shortly.
Concerning the PortableApps.com Installer though I see no reason why it should not be absolutely standard. It's all part of the public image. What reasons were you thinking of?
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
The goal of the PA.c Launcher is maintainability. If a custom NSIS launcher is doing the exact same thing that a PA.c Launcher will do, then there is no need for it and it will be scrapped. We will be doing this across all apps including all the custom NSIS launchers I have written and spent many an hour on.
That way, when a new version of the app is released, we just drop in the latest PA.c Launcher and it gets all the bug fixes and enhancements of the PA.c Launcher's latest version. That way, I (or someone else), doesn't have to check through an app that hasn't been updated in 6 month's code to ensure it's using our new registry handling or properly handling optional ReadINI strings, properly closing the registry, etc etc. Developers of individual apps will sometimes come and go. For others to have to maintain 50, 100, 200 iterations of code that do the *exact same thing* is completely nonsensical.
For tray launchers, it's a bit of a unique situation. Nearly all apps that need a tray, have one built in. For any that do not, one can be added, but it should be thought more as being a part of the app, rather than the portablization. The portabilization code will still be done in NSIS rather than AutoHotKey. The AHK bits will just be for the tray piece and be added into the App itself. The PA.c Launcher can handle launching one EXE and waiting for it or waiting for multiple ones. Chances are we will be doing some custom bits for this at some point.
As for installers, PortableApps.com Format apps use the PortableApps.com Installer. It's consistent, it automatically works with our platform and it automatically works with our updater. It's no-code and very easy to package. It presents a consistent end-user experience that is as easy and simple to use as possible. No other zip formats or proprietary installers will be accepted.
Sometimes, the impossible can become possible, if you're awesome!
Personally, I agree with both of you. However, from what I gather some developers wish to keep their own launchers (the ability to practice their programming skills, to keep intact what they've worked hard on, etc.). I only offered this as a possible compromise. (I hope some of the developers against using the PA.c Launcher will post here to elaborate on their stance.)
What is the tray launching that you speak of? Simply being able to minimize an app to the system tray? If that's the case then I know this isn't probably an ideal solution but DM2 allows you to minimize any app to the system tray.