I thought I'd post here first before I went to the newsgroup, hoping someone was aware.
New: Run-Command (Dec 2, 2024), Platform 29.5.3 (Jun 27, 2024)
1,100+ portable packages, 1.1 billion downloads
No Ads Nov/Dec!, Please donate today
New: Run-Command (Dec 2, 2024), Platform 29.5.3 (Jun 27, 2024)
1,100+ portable packages, 1.1 billion downloads
No Ads Nov/Dec!, Please donate today
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
how did you pin your icon to the task bar?
I'd guess that you ran Firefox Portable and then, once it was up and running, you right-clicked the icon there and selected "pin to" on it.
If you, you've just discovered one of the design flaws of the new task bar. You can't do that with any application where the main executable isn't the same exe as the initially launched executable. This problem affects not only portable apps, but also applications such as Digsby and World of Warcraft.
The app that you have pinned, and which has the jumplist is not the Portable launcher. You are effectively running the embedded non-portable exe file without the launcher, and, since it is the launcher that does all of the stuff like telling it to use your FFP profile, it doesn't work.
This isn't going to be fixed, since it isn't really acutally fixable until Microsoft change how the bar works, to, for example, allow you to explicitly register more than one exe against a bar-icon, or to track the parent/launching process of apps that are running.
As it stands, the only way that it could be done differently would be in Mozilla started to explicitly set a fixed static AppID in Firefox, which would then allow PortableApps to use the same AppID for the launcher, but would break the capacity for the bar to distinguish between separate instances of firefox, communitiy builds, the local and portable versions, multiple separate profile launchers, etc.
This is one of the reasons that a lot of developers aren't overly impressed with the new taskbar and its jumplists. It has the potential to be an exellent function, but until the API for it has been expanded a bit, there are some serious limitations.
The closest you are going to be able to get would be to drag the launcher icon onto your bar and pin that, which would then allow you to use that button to launch FFP with its profile, but you would then get a second icon showing on the taskbar while it is running. (See above, that's a limitation of the bar)
Thanks Jimbo!
Spot on I say.
Shame really, these issues.
If the focus was more on portability, rather than Open Source parse, then I think developers could do a great justice to Windows generally, as it can run pretty stable most of the time and there will always be a need for commercial software since many people need a shop to buy something then get support.
Anyway, it's probably not the time to philosophize but this seems to be the only place that provides a professional touch to what it does without being so geeky that only geeks can understand.
That's what I like about this place and I hope that greater things can happen.
Many regards.
Right-click the FirefoxPortable.exe & select "pin to taskbar", or make a shorcut & then the right-click.
I don't really have any idea how AppID's work, but everything I've read says that they can be specified by the app itself, and if it isn't specified, Windows takes over and generates one. Well, if the app can specify its own AppID, is that something that can be done dynamically at runtime, like perhaps via a command-line parameter or config file or something? I know that would have to be done on Mozilla's end, I'm just thinking out loud here... Again, I don't understand how they work so I may be totally off base, just a thought.
Edit: Something along the lines of this:
original article
Quamquam omniam nescio, nec nihil scio.
I've read up on these AppIDs. I think to make it work, Mozilla would have to explicitly set an AppID, tell us what it is, then we'd have to find a way to set a matching ID in the FF launcher. Then if you pin the launcher, it should stack the running instance of FF.
I'm afraid the second part is harder since the AppID of a launcher would probably be the AppID of the NSIS interpreter, which is either hard coded by the NSIS team or not specified at all. Either way we wouldn't be able to change it.
You're right, I've looked into it a bit and it's not easily do-able.
PS - Eraser 5.87 came out and *IS* portable. It saves settings in config files now. So you can simplify EDT's code and update it if you'd like, I'm doing Eraser now.
Sometimes, the impossible can become possible, if you're awesome!
Isn't that the one that has already been out and wasn't portable?
Thanks for the heads up, I'll take a look next week.
That's such a shame. In the code snippet given, it's just passing the pointer to a string to the API, it's not really apparent why that must be a static, set value rather than one dynamically determined at runtime... hopefully Microsoft will continue to improve the taskbar API to allow such things in the future. In that article it discusses Visual Studio launching a child debug process as an example of something that could be made to work. Also, just before the quote I posted, that quote actually begins talking about how to set an AppID for an entire process, implying that the code snippet in that quote sets an AppID to apply to an entire process, but that it would be different for each separate instance of that same application, which would seem to be similar to what we would want here... But, as I said, I haven't read up on it too much, so I will defer to those of you who have and just hope that Microsoft continues improving this nice feature that is the superbar. I wouldn't go so far as to call it "super" but it certainly does have potential
Quamquam omniam nescio, nec nihil scio.
The other thing to realize here is *when* the functions must be called to set the AppID. And that time is very early in app initizlization. After the app is running, the AppID cannot be changed. So it would already be too late for a launcher to even attempt to set the AppID. That's why I mentioned above that Mozilla would have to set the AppID for FF, and we'd have to find a way to match it in our launcher (which I also explained is probably impossible).
Re the portability, the Eraser.exe application may be modified to be portable, but the DLL still sets the Heidi registry key like older versions, so I'll still have to deal with that in EDT. Not a big deal. Only changes I see so far are that 5.87 has now gone unicode, so I had to upadte my API file.
I had checked it on Win2K with regshot and the portable version of it didn't do that. (grab the zip one not the installer one, they are different compiles)
Sometimes, the impossible can become possible, if you're awesome!
Right, you won't see it using the application, as I think Eraser.exe and Eraserl.exe take care of the registry entry and other portability issues. However EDT uses Eraser.dll directly, and internally the DLL is still creating that registry entry.
Ah, lame of it. Well, at least it doesn't have the odd links to the VC runtime. At least the EXE works fine on a base Win2K install, so we should be ok making it portable.
Sometimes, the impossible can become possible, if you're awesome!
So I downloaded the Eraser source and found where the registry key is being created. Unfortunately it's in MANY places and has to do with loading/saving of options/settings. Not at all a trivial thing to remove, and certainly not something I'd like to dig into every time it is updated. I have a strong feeling the Eraser EXE's deal with the key the same way we do in our launchers, export/delete and import/run. I'll keep the same logic in EDT as in old versions. But yes, the whole point of this version is to remove the dependencies on the runtimes, which is nice.