New: OneLoupe (May 1, 2025), Platform 30.0.2 (Mar 27, 2025)
1,100+ portable packages, 1.2 billion downloads
Ad Free! Please donate today
Right now, when the PA downloader is started (Menu -> Get More Apps), all apps in the list are unchecked. I'm looking for a way to start with a list where I can configure it to automatically check apps of my choice.
Is there any way to accomplish this with the current downloader?
If not, would you consider adding such a feature?
Please help support us by making a donation so we can keep bringing you awesome free software. We accept credit card, wire transfer, PayPal, cryptocurrency, and more.
If you recently donated, thank you!
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
Follow us on Twitter
The ability to do this in some fashion is coming. But it's planned to be more connected to the website and suites. How would you have pre-selected the apps you have in mind to be pre-checked?
Sometimes, the impossible can become possible, if you're awesome!
Some sort of configuration file. Can be a simple list of app names to automatically check, that would be either loaded from within the updater (would require extending the GUI, perhaps in ways that are not that easy or even possible with NSIS), or specified on the command line (but then, the updater cannot be started on its own, so I wouldn't know how to pass command line arguments to it).
Ideally, the updater would also let me save my app selection to that configuration file so no manual edits would be required. Regardless of this, it'd be desirable that the format is kept simple and humanly readable/editable.
Re app names, it should be possible to use the the mnemonic names as they are used in Update.ini (the folder names), i.e. "FooPortable" as opposed, or in addition to "Foo Portable".
But is there not a way right now to modify Update.ini to tell the updater what apps to pre-select? AFAICT the NSIS code seems like it does use Update.ini to at least temporarily save what apps are selected (but then NSIS reads worse than Perl to me, so I may be wrong.)
How about with the suite you can login to your PA.c username which it would then use to sync up with the list of apps you have saved on the website to automatically update on all of your drives, then for those who just use the downloader without the suite they can login on the website and download the settings file as-is but it can't sync to other drives unless they move it into the suite and login through it.
On a related point in case of app renames each app should have an internal id number which would be stored in a file in each app folder maybe appid.ini and this not the name of the folder would tell the updater what should be installed there, and this number would remain the same if a developer decided to rename the app such as from qwerty to SupermodPortable.
Uhm, I was asking about a bicycle, but this sound to me like an airplane.
The ability to control what's downloaded via some sort of configuration is fundamental to the ability to manage and sync those configurations across devices. So it would be quicker to implement, and we wouldn't have to wait that functionality until all the required website infrastructure and sync software are finished.
Also, personally I'd like to keep my data on my computer. I wouldn't want to log in into whatever site just in order to access data that is inherently mine. (But that's just me, call me privacy-obsessed.)
Re app ID: I vote against it. App names have been extremely stable in the past, and in the rare cases they'd change, an alias concept can be utilized to map old to new names w/o sacrificing human readability of the data.
Verdict: I'd prefer a simple format that I can create myself (be it w/ or w/o the PA platform software) w/o the help of any website.
An afterthought: I don't think syncing is an issue here. One beauty of portable apps is they can be synced between computers via a simple USB stick, or via Dropbox, or any other file sync service. No need for a special service there.
The appid would also help for users who wanted to change the folder names for the apps just for individuality.
I was thinking of security like the FireFox sync system along with similar functionality. Which would be good for if someone doesn't keep regular backups of their drive themselves in case of that drive being destroyed or formatted accidentally to keep all of their settings and perhaps documents as well, while keeping their data completely private.
Nonetheless, it doesn't change that configurable downloads are fundamental to syncing across devices and such.
I don't see an appealing reason to rename the app folder of a portable app. I reckon there are far better and more fruitful ways to express individuality than by going through a bunch of folders that have already been created by the PA updater, and manually renaming them. So such an option would be strongly under-utilized. And indeed, the beauty of the PAP is that it just works, with nothing to configure. It's so relieving to NOT have a bunch of options for once!
The suite may not have anything you have to configure, but uTorrent, Skype, Thunderbird, and probably about 99% of the apps do and syncing those could be very useful and many of those apps were designed to only be used on one computer per one user so it is extremely unlikely that the original app designers will add that, even with the built in sync I would probably use a PA.c sync instead for FF because I use a lot of power-hungry add-ons and settings on my computer because I know my PC can handle them while most public PCs I've used probably couldn't.
Adding App-IDs could also allow people to keep two completely different installations of the same app on the same drive. Even keep a copy of an outdated app at the same time as having an install of the current version of the same thing without removing access to either in the suite menu or having to change one of their internal names in order to tell them apart.
that can be done now
I've got an old version of Firefox (I don't use it, but it has one addon that I don't want to lose) in my Portable Apps menu while having the current version of Firefox Portable installed (and using that one as my main web browser).
You can rename the Folder to something the PortableApps auto-updater doesn't recognize (ie: from X:\PortableApps\FirefoxPortable to X:\PortableApps\FirefoxPortableOLD)
and then in the Portable Apps Menu hover the mouse cursor over the App Icon and wait for the information popup to appear, then right click on the one that needs renaming and select the Rename option.
That should give you access to both Apps in the suite menu, and allow you to tell which is which at a glance
Exactly!
As I said, that can already be done by any file syncing method there is, either between computer and thumb drive directly, or via DropBox and co.
I started this thread about one simple and specific feature: The ability to quickly download a set of portable apps w/o the need to go through the app list every time and manually tick the check boxes. I wouldn't want to make that feature "bigger" than that. B/c in practice, making features bigger only results in them being implemented later, if at all, and nobody benefits from that.
Right now, the updater uses the lowercase'd app folder names as "ID's", and that's perfect for me.
John, or anybody versed with the PA updater: Is there not a way right now to modify Update.ini to tell the updater what apps to pre-select?
AFAICT the NSIS code seems like it does use Update.ini to at least temporarily save what apps are selected (but then NSIS reads worse than Perl to me, so I may be wrong.)
The updater is to update existing apps. The app store is to allow the end user to select which apps they want. There is no way to force either one to do a pre-selected set of apps.
Sometimes, the impossible can become possible, if you're awesome!
There is PortableAppsPlatform.exe and there is PortableAppsUpdater.exe; There is no PortableAppsStore.exe. But we don't want to argue semantics... What I was refering to is this fragment from PortableApps.comUpdaterU.nsi:
WriteINIStr ${strAppListFile} "Item 1" "Checked" "1"It seems the updater is storing the checked state in AppList.ini at least temporarily. If so, my idea was to modify AppList.ini externally, but the file gets deleted at start up. Any chance this can be changed so the updater does not delete the file? Perhaps to add a command line option or so?
When we add the ability to specify sets of apps, it will be handled in its own special way without anything crufty like this being needed.
Sometimes, the impossible can become possible, if you're awesome!
Hmm... Since there are no statements on when that ability will be officially added, I'd like to give my "crufty" way a shot and do the code modifications myself (heil open source, right?) Can you please give me some hints on whether my premise is right, and whether it is safe to suppress the deletion of AppList.ini in the updater, or generally point me to what parts I'd need to tweak?
Thanks.
The planned method will allow you to pass in a set of apps to the platform which will pass it to the updater/app store (same EXE for both). It won't involve the section of code you're looking at directly as it will be a new process. As such, I haven't looked at your way of doing it, so am unsure if it will break other bits in the process or not.
Sometimes, the impossible can become possible, if you're awesome!
If you're unsure, I'll just try it and see what happens. What do I need to compile the updater exe file? "NSIS Portable" (and which one)? Or rather the "PortableApps.com Installer"?
Hmm, three days and no response yet?
This weekend is Thanksgiving weekend in the United States, which is where John is located. I'm sure he's busy spending time with family.
Be patient.
Seven days, and still no response?
This prompts me to articulate the feeling that I've been getting all along this thread, and even before it:
Open source license or not, I've been getting the impression that, for whatever reason, information about the inner working of the software is not readily shared.
I do not base this impression on the ongoing silence alone, but also on the way the other responses were formulated, in this thread and elsewhere, and which seem to continuously avoid to reveal any hands-down information about the "how's".
Be that as it may, I can live with not getting the answers I'm looking for, but I would appreciate the decency to be told to not expect a nuts-and-bolts response if there is no intention to provide one.
zoc, I'm sorry for the slow responses, but we've been very busy with quite a few things as well as otherwise occupied with things like hurricane recovery, holidays and family, updating apps, releasing new apps, and a major upcoming platform release. All detailed here: https://portableapps.com/blogs/johnhaller/2012-11-16--status-update-new-...
If you want to hack around with the updater and app store, you can build it with NSIS Portable (nothing else is required) by grabbing the Platform/updater/app store code from SF (linked to from the Download page). The only thing you need to be sure and do is switch NSIS to 'big UI' mode, a custom mode I added, by running switch_to_big.bat within the NSISPortable\App\NSIS\Contrib\UIs directory.
As stated, we have methods of doing 'packs' of apps in the works. These involve connections to both the updater and platform and will not work using the bits you are planning to modify. They will be connected to online postable links and will be shareable amongst friends, colleagues, companies, publicly, etc.
Sometimes, the impossible can become possible, if you're awesome!