Maybe nobody said it (or nobody wants to attract flames) but the PortableApps folder structure is unnecessary complicated. I see absolutely no reason for so many subfolders, some of which enter the App space itself. It can all be made much simpler.
- Why would I need a separate launcher app? Most of apps can be launched without a separate launcher program. If necessary, a simple symbolic link (shortcut) would suffice. And if it doesn't suffice, then a launcher can be specified in the special ini file.
- Why would I have obligatory subfolders inside my application folder? The app is a separate unit. If the Launcher or PAF Menu require extra data, let this data be in their own folder.
- "DefaultData"? Is this folder obligatory? What if the app doesn't have DefaultData?
- "Other" folder? Does it really have to exist? Why would the app keep its help files in some external folder, when most apps have their own Help subfolder in the App folder? For what reason does everything have to be rearranged?
Here's my suggestion of a simplified directory structure:
+ PortableAppName (the outer folder)
---- AppBin (all binaries and other stuff except settings)
---- AppData (app settings)
---- PAF (all files and folders required by PAF Menu)
This is what developers expect. It would simplify design, and require minimum changes to switch apps from ZIP to PAF. No unnecessary complications. I'm telling you this with best intentions in mind.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
Unnecessarily complicated as you think it may be, there are (for the most part) reasons for it.
The Launcher.exe is there for a very large number of reasons. It provides portability of files, folders and/or registry entries on the host computer. It provides automatic language switching when combined with the PortableApps Platform where an app is multilingual. It is also used to determine whether the app can run from a UNC path, can accept spaces in its path, can run on a particular version of Windows, can support multiple instances of being run, can handle having its path (not just its drive letter) changed, whether it needs to be run as admin, whether the app requires Java (and soon whether it requires .NET), and in the case where it can't do one of the previously mentioned things, will warn the user - and that still isn't the entire extent of what the Launcher.exe does. So even for those apps that require absolutely no portability, knowing why it didn't run from a UNC path or a path containing spaces instead of just having it fail silently or provide an error message above most non-technical users is a much more preferable user experience.
The DefaultData folder is not necessary as part of the spec, it only exists where an app requires data on first run or where the first run user experience is improved by its existence.
The Other folder isn't for the app's help files - it is for additional files for the portable version's help file (Other\Help) and for additional source code where custom NSIS is needed and some additional standard files that by default are not used, but are provided (Other\Source).
There are a few cases where I agree that some simplification could have been made, but it is the way it is. Personally I don't really see the point to having App\AppInfo\Launcher when it could have just been placed in App\AppInfo, but I can see why it did happen that way as the PortableApps Launcher was a later addition to the spec, before that it was all custom coded launcher executables.
To "simplify" it now would actually be a more demanding task, both from the perspective of existing developers adjusting to the new structure, and from the perspective of the PortableApps tools like the Launcher and Installer because, at least for a time, they would have to support two different structures. Even if we did do a complete cutoff date for the existing spec, the tools would still need to be rewritten which is a task we don't have the resources to do on a whim.
Personally I think "simplifying" it to your three folder model would complicate things for new developers, because you would have a folder for PortableApps specific stuff that would include a number of files they never even need to look at.
I know it's hard to change/improve things once they get accepted by many users. But one has to ask anyway.
When you go to:
portableapps.com/development/portableapps.com_format
It doesn't even mention the Launcher subfolder and its contents. If you didn't mention it above I wouldn't know about it. Is there someone responsible for maintaining documentation?
https://portableapps.com/development/portableapps.com_format
Let me get this correct:
- You don't use PAF
- You have never used it
Yet.. you wanna complain about it? LOL
GTFO .. noob
I use PortableApps on my PC..
andn and dont assume things you dont know.
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
he stated below he's never used it...
what else do you need to know about this guy?
I use PortableApps on my PC..
Well, that's exactly why I can say it's unintuitive. You can't say something is intuitive after using it for 5 years, simply because you get used to it.
It's like trying to make the first impression 10 times in a row.
If I'm making wrong assumptions that's because I'm assuming logical things. But things here aren't very logical.
I asked in another thread how to specify the default installation folder for the app. I assumed I have to add a line to the INSTALL.INI file. It was a logical assumption, but obviously wrong.
Because the answer is: NO CAN DO.
Is it logical that you can't specify the default folder? The only way to make it happen is to create and physically copy all the files to that folder. And then create the installation. Because "it's simpler that way".
Really? It's simpler to copy megabytes of data from the development folder every time, instead of just changing one line in the INSTALL.INI file?
I remember seeing PAF apps that were trying to install themselves in a wrong folder and failed. I couldn't install the app (in standalone mode). Because it was on a partition that my computer didn't have. I was curious why they used such a weird path. Now I know. It was their development path. And they also didn't find an option to specify the default path. Because that option doesn't exist.
I have to assume the app in question that tried to install somewhere weird either didn't come from here, or else it was a very old installer back when custom launchers were used.
Otherwise the PortableApps Installer we use now allows changing the install location like most other Windows software.
Could be it was an old package.
No PA.c Installer has ever had a default path other than %PortableApps%\AppNamePortable. Every drive on the system is searched for a PortableApps directory as well as the USERPROFILE directory. If none are found, it uses the current path plus AppNamePortable as a standard self extractor would. That feature was added a few years ago. Installers before then would require manual selection if a PortableApps directory was not found. There is no reason for a developer to manually specify a default directory. If they did it would not be portable.
As an example, a developer may want to specify %APPDATA%\AppName as the default. That is a user installed app but not a portable one. And the developer should not be using the PA.c Installer. All portable apps are user installable but not all user installable apps are portable. We focus exclusively on portable.
Sometimes, the impossible can become possible, if you're awesome!
No need to copy things around, at least for me that is. I have the apps I maintain in a development folder too (X:/Development/Diffpdf). I make a copy of the old version for backup reasons, then copy in the new version of the software (to /App/diffpdf) and then run the installer which creates the installer file (DiffpdfPortable.paf.exe) in the root folder (X:/Development/) I then can copy this around, send it to John for release or run it myself to try if it works.
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
he App/AppInfo/Launcher folder is not mandatory and therefore no part of the format/layout we use. Some (mostly older) apps dont have nor need one as they use a custom-fitted compiled launcher.
Later, this process was automated by the development of the PortableApps.com Launcher. But for apps where there is little to no change to how the program works, there is no need to abandon the old launcher and do a tramsition to the new launcher. But most newer apps use it as it really is easier.
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
I know it's not mandatory, but the directory structure on that page shows other folders that also aren't mandatory (like Other/Source).
@ Atilla
1. How long have you been using PAF format?
I use PortableApps on my PC..
I guess the answer to that is obvious - I didn't use it yet. Otherwise I would already be used to it (as human beings eventually get used to everything).
That's the reason I can offer this perspective of a new user. There's only one chance to get the first impression, right?
need i say more?
I use PortableApps on my PC..
Whether I used it once or thousand times, there are still so many illogical things in the format. The fact that I'm using PAF for the first time enables me to see how unintuitive it is. Intuitiveness is directly related to using something for the first time.
I guess most older users eventually find their own solutions and (not so efficient) workarounds. But workarounds don't make the platform any better.
Ofc, if this PAF system is only 1-2 years old then I can understand it didn't have time to evolve. So that's why I'm reporting the problems, to help the evolution. How old is the platform?