I consider this a bug. You know you need to check for update of an app at startup. You also know that app is marked for auto-start, and you have the limitation of not being able to update it while it is running. It's clearly a bug. You trip yourself and call not doing it a feature?
However I see something similar in the list of features for the future.
Delay apps set to autorun until after the updater has done a check, possibly not starting the ones that require an update
Problem is, this is actually a very annoying bug. I mean your apps start and are loading and then updater checks them, informs they have updates, your apps still don't show their main window so you click on next and get them to update, then your apps show up and the updater says it cannot update because the app is running.
So you close the app, update it, and manually launch it again. That's pretty annoying if it happens every other day, which happened to me during this week.
So here is an up vote and hopefully a severity increase or something, to get it up on the todo list.
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
At the moment, it's up to the user. Users generally know what they have set to auto-run (most important always-used apps) and will often untick the boxes to update the ones they autorun if they are in a hurry. That's why it operates the way it does. That plus the fact that autorun and updater are entirely separate processes and code at the moment.
In addition to all that, the updater is currently a bit slow, taking 10 to 20 seconds or more to check for updates (download the app database, compare it to installed apps, check the individual INI files for version info, etc). The current internal build of the platform speeds this up to about 2 seconds for most users due to a combination of re-coding the updater to check for the app's directory first (faster) before checking for existence of the INI (slower), downloading the database in compressed form (32KB vs 172KB), and what I'm working on now to be able to cache the app database and be able to just check if there is an updated version (about 43B of communication instead of 32KB). This will be launched as the next beta.
Then we'll be working on getting the updater to be able to pass to the platform when it is done checking and what apps need updates and to optionally skip auto-starting the apps that need updates (an optional setting in Options which will be enabled by default).
I hope that helps explain the current setup, the complexity, and the process for moving forward. I'm also the only one currently working on it. Unpaid, of course.
Sometimes, the impossible can become possible, if you're awesome!
Thanks for the detailed explanation. I understand your position.
Keep up the good work
delphi developer
There might be a bug or something in the version detection of the update tool. I went with leaving the portable apps (which support it) to update themselves (eg: chrome, firefox, skype).
The updater tools reports these, with their current up-to-date version as needing an update.
It's weird. It's not a "problem" I just figured I'd mention it.
delphi developer
This is a totally different issue and would appear to be a bug, but we'd need far more information to troubleshoot. Information like the exact version of Firefox you have installed vs asking to update to, install location, contents of the appinfo.ini file within FirefoxPortable, etc. All that should be posted in a new topic.
Sometimes, the impossible can become possible, if you're awesome!
This is a won't fix, as it isn't the updater's fault, it's the way the apps are packaged.
When our updater updates the apps, it updates the version listed in appinfo.ini, which is where the updater checks for version numbers, whereas the inbuilt updaters only update the apps themselves, as they don't "know" they're in PortableApps.com Format, and can't update that information.
The best option is to always update using the packages provided here, rather than allowing apps to auto-update. We do occasionally add features to our launchers for apps that auto-update, and not updating them in such a manner means those specific features may be missed. Note, of course, that I said occasionally - as this doesn't happen often.
On one hand, the auto-updater is not able to properly manage the update and the auto-start of the applications because of how it's implemented.
On the other hand, the auto-updater is not able to properly manage the installed versions because it is relying on an ini setting.
All in all, you can't use the auto-updater to update an application out of the box because by the time auto-updater sees the updates, the auto-launcher has already started it, so you must wait 1 or 2 minutes for the app to finish loading, close it, update it and manually start it again, because the auto-updater won't start it for you.
Am I really the only one who sees a lot of fixable problems here? The whole (base) point of a launcher is to take manual operations off your hand.
Won't fix is a bit too strong with all these "implementation" quirks. The whole thing in a "bug" is that it's a bad implementation thing. Now if you tell me that this was specifically designed to work like this, then fine, all these are not bugs, but if these are side effects of a flawed design (I've never done a perfect one), then they're bugs. Simple as that.
All these problems are fixable by a simple checkbox in the launcher settings, "Start apps after updater", which I already mentioned in my very first post, is in the up-coming "Features".
You CANNOT ignore that the trend in applications is to update themselves. This means that there will be cases in which the application will update itself maybe 1 or 2 days faster than the portable version will be rolled out (like urgent security releases or whatever, or simply the developers of that app will forget to release it or whatever).
So for an increasing number of applications, basing yourself on an in-house ini to get the application version when you clearly know where the application exe is (because you launch it) and so can certainly read the version from it, I'm sorry to tell you, but it's stupid.
But sure, go ahead and don't fix it.
It's not my call and I can always go about doing my own version if this get's too annoying and there isn't a better alternative.
I've done my share of opensource programming at my time and I don't recall developers being so negative. You clearly have a few bugs here and yet you try to show it off as non-bugs, features even. Is there some contest or something on which open source app has the fewer bugs or something?
A feature is defined as a new behavior. You are marking a bug-fix as a feature and call it that for what? What possible purpose would any sane person have to NOT use that "feature" after it is implemented? Who in his right mind will want the auto-updater to tell him he has updates, after the applications already started? How the hack does this help you? You need to wait, close, update, start, all manually.
Clearly we're not getting anywhere except wasting each others time and what not so I'll just stop using the auto-updater and call it a "fix".
delphi developer
Your point about starting after updating was already answered in detail above:
https://portableapps.com/node/37671#comment-208871
As for auto-updates of the apps vs the portable apps, they are disabled on purpose for most apps already. Including Google Chrome and Skype (whose updaters either aren't included or can't update their portable form anyway). The only apps that are affected are Firefox and Thunderbird and we aren't allowed to disable their auto-updater by default for licensing reasons. But we do have it set to notify but not update itself. So, of your 3 examples, Firefox is the only one you could actually have this problem with (the other two are impossible unless you manually copied in the files from a local install) and then only if you manually auto-updated it (if that's not the case, let us know as it's a bug).
Even in a situation where you did update Firefox, you'd still be need to update the portable package. We regularly update the launcher (FirefoxPortable.exe) and Firefox's auto-update process doesn't update that. Firefox's auto-update process could also break at some point and not update portably. It's not an officially supported feature of Firefox. So, you should always update via the platform. We don't plan to rewrite the system to auto-detect when an end-user has copied files in from a local install to update an app manually. Nor the edge case where a user manually lets Firefox or Thunderbird update itself and then checks for updates via the platform. We're even adding the ability for Firefox and Thunderbird to detect when they are used in conjunction with the PA.c Platform and disable their internal auto-updaters entirely (which will eliminate the issue).
I think Gord's issue is that you seem to be intentionally blowing these problems out of proportion. You did this in your last post by listing Skype and Google Chrome as having auto-updated, which is not possible.
Sometimes, the impossible can become possible, if you're awesome!