New: HomeBank (Sep 03, 2023), Platform 26.2.1 (Sep 17, 2023)
450+ real apps (49GB), 1.1 billion downloads, Please donate.
Jack Haller, Advisor and Father of Our Founder, Has Passed Away
This question is also related to other GTK-based apps, but I don't want to post multiple copies.
I have six folders named GTK and a number more as GTK2.0 on my drive, under CommonFiles, GimpPortable, PidgenPortable, X-ChatPortable, PlannerPortable, EasyTAGPortable, Claws-MailPortable, GNUCashPortable, and GNUBackgammonPortable. Are any of these removable? If so, which ones?
Thanks for your consideration...
The official PortableApps.com apps (GIMP and Pidgin) both support using a single GTK instance within X:\PortableApps\CommonFiles\GTK. As long as one is there, you can delete the ones within GIMP and Pidgin.
I don't know about the current test releases of the other apps. But, once they hit pre-release stage (with PortableApps.com splashes and such) they will support CommonFiles as well.
Thank you.
How about specifying a custom GTK path?
Preferably one that is not portableapps.com - specific one.
Making is PortableApps.com specific makes it easier to use with the whole platform without getting errors, and it's easier for the average end-user. They are PortableApps.com apps after all. Windows has the exact same setup.
I have the latest version of GIMP Portable 2.2.1.7. Should I have a GTK in my common files?
I believe it will work work by both Pidgin and GIMP (i think they use the same verison), and X-Chat.
Why not have new releases of GTK apps delete App\GTK and install into CommonFiles\GTK instead?
Since they don't do this yet, the mechanism could even be implemented with a CommonFiles\GTK\dependencies.ini file such as:
[GTK-minimum] GIMPPortable=2.10 PidginPortable=2.10 [GTK-maximum] GIMPPortable=2.99 PidginPortable=2.99
Obviously, the required GTK version info would be updated with each dependent app install/update, and the app installers would install or upgrade GTK as necessary. The future "app deleter" would remove the corresponding GTK dependency and, if it was the last app dependent on an installed GTK version, delete that common GTK install.
I did notice that nearly all of the GTK du is under GTK\bin with no versioning other than the individual DLLs. So, the GTK dir tree could be branched a la Java (e.g., GTK\gtk-2.10.0) or the dependencies.ini file could specify GTK versions as such:
[GTK-2.10.0] file00=bin\libexpat.dll ... file1f=bin\libgtk-win32-2.0-0.dll file20=lib\gtk-2.0\2.10.0\bluecurve.dll ... [GTK-3.0.0] file00=bin\libexpat3.dll ...
Of course, if GTK is guaranteed to always be backwards compatible with older versions, you could implement versioning with a simple version.ini file. The app installers would just make sure not to overwrite an extant newer version unless the user selected a "re-install GTK" option.
Or, you could ignore everything I said except for the first line in bold. 
-hea
Unfortunately, GTK has issues with both backward and forward compatibility. For a while, the latest GTK that came with GIMP caused Pidgin to crash. So, we can't assume to install it. In fact, some people were using the portable version of one or the other of these apps because of this incompatiblity.
The GTK-dependent app launchers would have to look in only one location to determine if the supported GTK version is present (CommonFiles\GTK only, rather than App\GTK then CommonFiles\GTK).
If CommonFiles\GTK were branched (a la Java), then the dir structure would look something like:
CommonFiles\GTK\ CommonFiles\GTK\dependencies.ini CommonFiles\GTK\gtk-2.10.13.0\ CommonFiles\GTK\gtk-2.something.else\
and the dependencies.ini would look something like:
[GTK-version] GIMPPortable=2.10.13.0 PidginPortable=2.10.13.0 OTHERAPP=2.something.else
When a GTK-dependent app installer goes to install GTK, it looks to see if that version is already present (and kosher?) and installs only if not present, not kosher, or user has selected "re-install GTK" option. It updates dependencies.ini with the new app=version info, then deletes any orphaned GTK version branches.
As previously described, the future "app deleter" would remove the corresponding GTK dependency and, if it was the last app dependent on an installed GTK version, delete that common GTK install. A power-user could add app=version entries to dependencies.ini to retain GTK versions for apps that would not be matched by PA installers/deleters.
In the worst-case scenario, all N installed GTK apps would require different versions of GTK, so there would be N CommonFiles\GTK\gtk-version branches with N GTK installations. This is functionally identical to the current mechanism of installing GTK privately under each app, except that the app launchers need look in only one location for their respective GTK installs.
Starting with the worst-case scenario, if any future GTK-dependent app installer finds its desired GTK version already present, it doesn't have to perform a duplicate install (and may even delete an older GTK version if one gets orphaned by this install). Of course, the newer installers would also delete any private GTK installs present under their respective apps.
Just a thought. -hea
EDIT: Of course, the app launchers already know their GTK version and resulting GTK path, so they can blissfully ignore the dependencies.ini file.
Some users don't use their apps in conjunction with the menu and as such don't use CommonFiles\ or even PortableApps\
But the PAF installers create a PAM-compliant directory structure under the installation directory, regardless of the existence of PortableApps\ or PAM:
${INSTALL_DIR}\
${APP_NAME}Portable\
App\
AppInfo\
DefaultData\
${APP_NAME}\
Data\
Other\
${APP_NAME}PortableSource\
${APP_NAME}Source\
I'm simply proposing that the PAF installers add ${INSTALL_DIR}\CommonFiles\ as necessary. If the user chooses a different install dir for each app, they'll maintain separate "common" files; opting for a common install dir would automatically optimize Common File usage for normal users.
I understand that a neophyte user might be surprised to find an extra directory with a non-obvious name (CommonFiles), especially if he cleverly installed to C:\ or his Desktop. If that's a concern, I'd certainly recommend a readme.txt, and the directory could be called something like PortableCommon, PortableShared or PACommonFiles instead. Even the current "CommonFiles" spelling varies from the M$ "Common Files", so I don't think changing it should hurt too much. Any existing Portable Apps CommonFiles\ wasn't likely put there by a neophyte user anyway. 
Still just a thought, but a durn good one. -hea
X-Chat Portable supports common files as well. It's a modified Pidgin launcher (thanks to John's hard work on that), just remove the GTK directory under \App and it will use CommonFiles if the version is appropriate.
If you have any problems and find the CommonGTK is not working, post a comment in the X-Chat Portable beta topic.
Inkscape Portable which I am currently working on doesn't support having seperate GTK files and they all have to be in the same folder as inkscape.exe
I've talked to the development team and they said they won't be changing it, as it just simplifies everything for them and the user.
Visit the Community page
Join our forums
Follow us on BlueSky