I still don't get the point of these variables or how they would be used. Currently, I have an app on the desktop. So, PAL:LastPortableAppsBaseDir reads C:\Users\Kenny Williams (not C:\Users\Kenny Williams\Desktop), but what if I move the app to a different directory? It can never check for the \Desktop portion of the location of the file and thus will never be able to change the directory correctly.
Wouldn't it make more sense to remove these two variables and implement PAL:LastPortableAppsDir instead?
The main issue I am having is using Notepad++ Portable as an editor for Cppcheck Portable. If I have them in the same directory, how do I update the location if I change the directory entirely without the use of a PAL:LastPortableAppsDir?
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
It's for improving the quality of path replacement with directory moving.
When an app is installed to X:\PortableApps\AppNamePortable, this variable will be X:\. So far, drive replacement would do just fine for updating paths like X:\PortableApps\AppNamePortable\Data\foo and X:\Documents\bar and X:\Something else\baz (such a structure as people are wont to create). But if the contents of the drive (i.e. the PortableApps.com installation) are moved to C:\Users\jargon\Documents\Dropbox\PortableApps\AppNamePortable, simple path replacement would yield C:\PortableApps\AppNamePortable\Data\foo, which is wrong, and if replacements were done on the documents directory, the portable app directory and the drive, X:\Something else\baz would be changed to C:\Something else\baz. With PAL:PortableAppsBaseDir, it is more likely to be caught and strung along in its new path, C:\Users\jargon\Documents\Dropbox\Something else\baz.
So, the recommended form for now is, I think, replacing
PAL:Drive, (b) PAL:PortableAppsBaseDir and (c) if required the package directory. In the future, this should be tidied up so that these replacements can be made in one pass.
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
I somewhat get it now.
And essentially, from my understanding, it's not for use with what I want to do then? Since there is no PAL:LastPortableAppsDir, how would I update paths for apps installed in the same directory as the current app?
PortableAppsBaseDir serves as a point of portablization for both links to other apps and to the Documents, Music, Etc directory. Generally, folks have all their apps within a given directory. So, if they moved that directory to another location, PortableAppsBaseDir would work fine. If they moved from the X:\SomePath\OtherPath\PortableApps\AppNamePortablesHere to Y:\SomeOtherPath\PortableApps\AppNamePortablesHere, those apps would still find each other via PortableAppsBaseDir. If they go around moving individual apps in pairs, though, it'll break. I don't know of any reason to do that off-hand, though. And I can't imagine users expecting it to continue working moving apps around all willy-nilly
Sometimes, the impossible can become possible, if you're awesome!
Let's consider PortableApp1 and PortableApp2 are in C:\PortableApps. I'm attempting to move the PortableApps directory to the desktop, now both apps are in C:\Users\Kenny Williams\Desktop.
PortableApp1 uses PortableApp2 as an editor when it opens up a certain kind of file. Currently, if I try to replace PAL:LastPortableAppsBaseDir (X:\) with PAL:PortableAppsBaseDir (C:\Users\Kenny Williams), the new path would show C:\Users\Kenny Williams\PortableApps\PortableApp2, which would be incorrect. (Obviously, in this case PAL:AppDir doesn't work either because it contains location information for PortableApp1 which we don't need if we're updating the path to PortableApp2).
Oh, I thought of that one, but... Honestly, it's pretty unlikely that a user is gonna move individual apps at all AND expect relative stuff to keep working, so I'm unconcerned with supporting it. Relative paths have to be relative to a specific point and we can't support EVERY point. I think between LastAppDir (for in-app paths like extensions and such), LastPortableAppsBaseDir (for between app relativity and relativity to Documents, etc) and LastDrive (for a fall-back for people with oddball paths on portable drives), we're fairly well covered. If someone is randomly moving individual or pairs of apps around, they're kinda on their own. I know I'm certainly not keen to go back and update all my apps for additional relativity.
Sometimes, the impossible can become possible, if you're awesome!
I thought that was one of the portablization issues we were aiming for when we first added directory updating, but I see your point (well, sorta, as I don't see adding PAL:LastPortableAppsDir being a huge effort. =P).
Though my issue still remains, as I have to have a default directory in DefaultData for Notepad++Portable and without PAL:LastPortableAppsDir there's no way to update it properly. I can add env var substitution in the registry via custom code though, I suppose.
You don't need custom code. You just need a single entry replacing REPLACETHISSPECIALPORTABLEAPPSPATH with PortableAppsDir. We do that in a ton of apps. And that way you don't need a fake AppNamePortableSettings.ini file in DefaultData.
And we can add LastPortableAppsDir to PortableAppsDir as one of the things replaced once we do an all-in-one for the edge case. We're doing a single LASTPATHSVAR to CURRENTPATHSVAR setup to handle most everything. But adding it as yet another string to replace isn't needed as we have AppNamePortable.ini files that are long enough already.
Sometimes, the impossible can become possible, if you're awesome!
Done and done. Cppcheck Portable DT update soon to come, and it should be ready to release.