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...
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 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.
Sometimes, the impossible can become possible, if you're awesome!
Thank you.
How about specifying a custom GTK path?
Preferably one that is not portableapps.com - specific one.
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
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?
Life is about the journey not the destination!
The Kazoo Spartan
I believe it will work work by both Pidgin and GIMP (i think they use the same verison), and X-Chat.
Do I just copy the GTK from GIMP or X-Chat to Common files?
Life is about the journey not the destination!
The Kazoo Spartan
Should do fine.
Why not have new releases of GTK apps delete
App\GTKand install intoCommonFiles\GTKinstead?Since they don't do this yet, the mechanism could even be implemented with a
CommonFiles\GTK\dependencies.inifile such as: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\binwith 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 thedependencies.inifile could specify GTK versions as such:Of course, if GTK is guaranteed to always be backwards compatible with older versions, you could implement versioning with a simple
version.inifile. 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.
Sometimes, the impossible can become possible, if you're awesome!
The GTK-dependent app launchers would have to look in only one location to determine if the supported GTK version is present (
CommonFiles\GTKonly, rather thanApp\GTKthenCommonFiles\GTK).If
CommonFiles\GTKwere branched (a la Java), then the dir structure would look something like:and the
dependencies.iniwould look something like: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.iniwith 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.inito 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-versionbranches 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.inifile.Some users don't use their apps in conjunction with the menu and as such don't use CommonFiles\ or even PortableApps\
"If you're not part of the solution, you're part of the precipitate."
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 areadme.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 AppsCommonFiles\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.
"If you're not part of the solution, you're part of the precipitate."