GIMP Portable launcher removes default %PATH% entry, so it can use only internal GTK. This greatly increases it's size...
Is it due to the problems with xmlparse and xmltok? If so, the better solution would be setting %PATH%=(gtk path);%PATH%. This way Windows should find the internal ones first, but if they don't exist, still would be able to find the shared ones.
You are here
GIMP: [Feature Request] shared GTK not found
October 9, 2007 - 10:11am
#1
GIMP: [Feature Request] shared GTK not found
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 not a bug, it's a feature. GTK is *supposed* to be included on your portable device. Most PCs won't have GTK, so you have to have it on your device, anyway. And, chances are the version on a given PC that did happen to have it would be an older version that would cause issues.
How does it 'greatly' increase the size? GTK compressed is like 5MB and you can use one copy between GIMP and Pidgin.
Sometimes, the impossible can become possible, if you're awesome!
GTK *is* on my portable device. And 2 versions of it are shared between several apps. GTK, recompressed takes 5.3 MB for me. GIMP with launcher and settings - 10.2. Isn't 50% size increase significant?
Furthermore, it adds redundancy to a pendrive and therefore increases maintenance time.
Having GTK built-in is a feature, actually it is required to call it portable. But lack of possibility of using external one is still a bug...
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
You can call it a bug if you want (it's obviously not... it's a feature request by one user after 3 million downloads) ... but using a local GTK is a very bad idea... it increases complexity, increases support issues and serves absolutely no purpose aside from saving 5MB for .001% of users (most users will need to have it portable).
In short, it ain't happening.
Sometimes, the impossible can become possible, if you're awesome!
John,
Sorry for hijacking this conversation but I have a related question:
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?
Ask in a new topic. I won't respond to thread hijacks. Thread hijacks make it impossible to follow existing threads and impossible for users with the same question to find the answer.
Sometimes, the impossible can become possible, if you're awesome!
You can call it a bug if you want (it's obviously not... it's a feature request by one user after 3 million downloads) ...
99.999% of windows programs have a feature of using the PATH user specified...I think this makes the word "bug" well-founded.
it increases complexity By 7 bytes? (";%PATH%")
increases support issues Because it's 7 bytes longer? I see no other reason.
serves absolutely no purpose aside from saving 5MB for .001% of users If you're counting only me - 0.001% sounds reasonable. Even if I tried to count users that are not registered on this forum, I couldn't argue that not really significant minority of users will profit from it.
BTW, did I mention redundancy?
Most users will need to have it portable Definitely agree. I'm one of them. But "portable" doesn't mean "separate for each app / pair of apps if you use both".
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
John asked me to move my question to a separate thread and he answered it there. I have a hunch the answer may be relevant to you too. You commented "GTK *is* on my portable device. And 2 versions of it are shared between several apps. " If you, like me, have multiple copies of the GTK directory under CommonFiles and Gimp and Pidgen, per John's response to me, we can delete the individual Gimp and Pidgen GTK directories and the apps will find the CommonFiles version. That should reduce the clutter on your drive while staying fully portable.
Your question is unrelated. He already knows about CommonFiles. He wants to eliminate GTK *ENTIRELY* from the drive and have the apps use the local version instead... which is not gonna happen.
Sometimes, the impossible can become possible, if you're awesome!
Please reread my posts, I wrote things totally different from what you present.
I want to eliminate GTK from app-specific directories and use the ones I have already on my pendrive.
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
Adding the PATH is a no-brainer if all it involved is what you said... but it doesn't. Not by a long shot.
The first problem is that the GTK on the local PC could be a version that is incompatible with the app, or corrupted, or infected with a virus, etc... and we'd be encouraging the user to use these copies. This will result in crashes, additional support issues for us, etc.
The second problem is the fact that the launcher specifically ensures that a portable version of GTK is in one of the two locations and if it isn't, it presents an error to the user. In your version, we'd need to also check the local PC for a version which involves checking the registry key, then the default location and then, if you want to be thorough, parsing the path looking for it.
Bottom line, it is NOT going to happen. It's extra work in terms of code, maintenance and support for near-zero benefit. It's completely unnecessary.
Sometimes, the impossible can become possible, if you're awesome!
The first problem is that the GTK on the local PC could be a version that is incompatible with the app, or corrupted, or infected with a virus, etc... and we'd be encouraging the user to use these copies. This will result in crashes, additional support issues for us, etc.
The second problem is the fact that the launcher specifically ensures that a portable version of GTK is in one of the two locations and if it isn't, it presents an error to the user. In your version, we'd need to also check the local PC for a version which involves checking the registry key, then the default location and then, if you want to be thorough, parsing the path looking for it.
Both are NO PROBLEMS. Just put the portable path before the given one and GIMP will see the "portable" dlls instead of the given ones, as long as they exist! Even though I don't know NSIS, I didn't read your code I still claim, that these 7 bytes will solve the problem and won't create any others!
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
Once again, please go back and re-read what I *JUST WROTE*.
1. We'd be *ENCOURAGING* users to use local installs instead of portable ones, which introduces all those problems. By adding a feature... people use it... and when people use it, they find new ways to break it. And when they break it, they want it fixed.
2. As I very plainly laid out, it requires several additional code checks as the launcher has to ensure GTK is available or error to the user. If you don't know how the launcher works, please learn it before lecturing me about what's involved.
Please learn about how this works before making additional unfounded and incorrect claims.
Sometimes, the impossible can become possible, if you're awesome!
1. We'd be *ENCOURAGING* users to use local installs instead of portable ones, which introduces all those problems. By adding a feature... people use it... and when people use it, they find new ways to break it. And when they break it, they want it fixed.
If sb. asks for help in such case, can you give a better answer than "Please reinstall GIMP Portable". Ok, it's not 7 bytes. It's c.a. 30 bytes / month.
As I very plainly laid out, it requires several additional code checks as the launcher has to ensure GTK is available or error to the user. You can try to load it. 20 bytes?
If you don't know how the launcher works, please learn it before lecturing me about what's involved.
I know WINAPI well enough to say the sentences above. I also know some things about NSIS, together it doesn't make me an expert, but is enough to state some things. (BTW, I guess you don't remember, but I wrote a NSIS plugin for you. You didn't ask for it, but it fixed some of your "bugs"(I'm quoting this word, again, you may not agee with it)) Please don't interpret my posts as lecturing you. I'm just pointing out the things that I'm sure can be done better easily. As I did c.a 10 times already and always been ignored.
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
As I already stated, the launcher, right now, checks to ensure that GTK is included portably. If it's not, it lets the user know. That way the base app won't error on load with a less helpful error message. Here's the pseudocode:
1. Check to see if GTK is included within the app directory
... If it is, set the GTK path appropriately
... If not, continue to step 2
2. Check to see if GTK is in CommonFiles
... If it is, set the GTK path appropriately
... If not, display an error message
If we take your suggestion, we'd need to change it to:
1. Check to see if GTK is included within the app directory
... If it is, set the GTK path appropriately
... If not, continue to step 2
2. Check to see if it's in CommonFiles
... If it is, set the GTK path appropriately
... If not, continue to step 3
3. Read the GTK variable from the local registry
... If not set, go to step 5
... If set, go to step 4
4. Check to see if GTK exists at the location specified in the registry
... If it does, set the GTK path appropriately
... If not, continue to step 5
5. Check to see if GTK is installed in the default location
... If it is, set the GTK path appropriately
... If not, display an error message (or go to 6)
6. (if you want to be thorough) Parse the path looking for GTK
... If found, set the GTK path appropriately
... If not, display an error message
That is what is required to properly handle a local instance of GTK and ensure proper notification of errors to the end user. And that doesn't even begin to address the fact that people using local GTK will probably encounter additional issues requiring additional support.
So, once again, why on earth would we add all that complexity to the launcher. Additional code to support. And an additional feature to support. All in the name of a feature that one single user has asked for among 3 million downloads and has stated that he doesn't even plan to use. This discussion is so surreal, it's insane.
And a note on your plugin. I already stated that I would get to it when and if I had time, since it is an extremely minor issue. And, when I checked, there was no documentation or example code with your newadvsplash replacement... not even a readme text file with the proper call to make.
I look forward to your response in which I'm sure you'll post another snide remark criticizing my coding, my support abilities or something else. Maybe you could try and work my family or personal appearance in it to complete the picture. That would be perfect.
Sometimes, the impossible can become possible, if you're awesome!
1. Check to see if GTK is included within the app directory
... If it is, set the GTK path appropriately
... If not, continue to step 2
2. Check to see if GTK is in CommonFiles
... If it is, set the GTK path appropriately
... If not, display an error message
If we take your suggestion, we'd need to change it to:
1. Check to see if GTK is included within the app directory
... If it is, set the GTK path appropriately
... If not, continue to step 2
2. Check to see if it's in CommonFiles
... If it is, set the GTK path appropriately
... If not, continue to step 3
3. Read the GTK variable from the local registry
... If not set, go to step 5
... If set, go to step 4
4. Check to see if GTK exists at the location specified in the registry
... If it does, set the GTK path appropriately
... If not, continue to step 5
5. Check to see if GTK is installed in the default location
... If it is, set the GTK path appropriately
... If not, display an error message (or go to 6)
6. (if you want to be thorough) Parse the path looking for GTK
... If found, set the GTK path appropriately
... If not, display an error message
You can replace it with
1. Use the System plugin to call LoadLibrary("libgtk-win32-2.0-0.dll").
I look forward to your response in which I'm sure you'll post another snide remark criticizing my coding, my support abilities or something else. Maybe you could try and work my family or personal appearance in it to complete the picture. That would be perfect.
John, everybody here, including me and you, know you write a good code. You use the strictest "portability" model and your apps do work with it.
I'm neither criticizing you nor your code. Please treat my post as highly recommended suggestions. Portable Apps are working, but sometimes can be more or less easily improved. In such cases I just have to write my 2 cents, I'm a perfectionist. Criticism was never my goal, I just give my best to improve the software many of us are using.
And a note on your plugin(...)
I skipped the full citation because it's EOT for me. Please excuse that side note, I just felt that my will to help was ignored - I was wrong, sorry then.
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
All LoadLibrary will tell us is that there's a gtk somewhere. It won't tell us where. We'd still need to figure that out so we can set GTK_BASEPATH. And it'll add another 10KB DLL inside the launcher. One more DLL to have yet another free antivirus client find a false positive in, which yields another 10 forum posts.
Once again, there's really no point in doing any of this. Extra code for the sake of it. Extra support for the sake of it. We don't want people using local GTK since it's unreliable, an unknown. Why add the code, the support and the maintenance to the launcher for an unnecessary feature?
Regardless of how much you want it, I've yet to hear any compelling reason to support it. And certainly not reason enough for the extra work and complexity involved. Just because you want something doesn't mean it's worth it to implement it. Heck, I have some small things I've wanted to add to apps (I'm a bit obessessive/perfectionist as well) but I leave some of them out because they add lots of code, complexity or support for something that hardly anyone would use.
The mantra here is KISS (Keep It Simple, Stupid). Unless there is a truly compelling reason to add a feature and it will be of use to a good number of folks and it won't negatively impact other folks... it won't be added. The ability to use a local GTK isn't terribly useful, won't be of use to much of anyone, and there's a decent likelihood of a negative impact in terms of support and maintenance. So, the answer is no.
Sometimes, the impossible can become possible, if you're awesome!
GetModuleFileName. A single WINAPI call will give you the path. Add 10 KB to reduce the size by 5MB? Works for me. Especially that it's going to take less than 10KB due to compression.
False positives - you're right, it can happen. But the system plugin is so popular that AV that would call it problematic would get 20 reports within first hour. And an hour later it would get fixed definitions.
ADDED:
Mistake. I just took a look into the launcher code and it uses the system plugin already. So you don't need any other dll, there's no problem with AVs.
I don't write this addition to try to convince you, your words below are clear enough. I just want to emphasize how unreasonable is your resistance.
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
The answer is no. You can keep asking all you want. But I will not increase the complexity (and support and maintenance) of the launchers just to add a feature that only you want that serves no purpose and no one else wants. Won't happen. Period. End of story.
STOP ASKING.
Sometimes, the impossible can become possible, if you're awesome!
I feel compelled to ask one question after reading all of this information very completely.
WHERE, I ask, would this make any sense to implement? Why would it be worth the work?
If you are REALLY worried about space on your thumb drive, it's time to wake up. You can get a 512MB drive for less than $10. It's time to upgrade if you are that short. The point of having portable apps, is making them truly portable. This would defeat that purpose and would increase the amount of work that the people here have to do.
This really, honestly, doesn't make any sense whatsoever from a development standpoint. Period.
Yes, I am REALLY worried about space on my cell phone. Because I do care to keep programs as light as possible, they take only 835 MB. ( w/out GMIP
) This doesn't leave too much space for music...but if I increased it by 50%....I've been told that firmware doesn't support cards bigger than 1 GB. I won't get a new cell for 10$.
And can you write how would this defeat anything?
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
You write:
And can you write how would this defeat anything?
which is an intentionally naive follow-up question to Gizmokid2005's clearly worded statements:
The point of having portable apps, is making them truly portable. This would defeat that purpose and would increase the amount of work that the people here have to do.
As John explained multiple times in excruciating detail, reverting to a local install of a critical component breaks portability. Put simply, the local critical component isn't part of the packaged app so it's impossible to confidently know anything about its version, configuration, compatibility or safety. Not to mention that the app will [mis]behave differently depending on which host the drive's connected to. Ergo, it ain't portable. The limitless possibilities of [mis]configuration by end-users makes support untenable, especially for a free platform.
If you truly need the ability to de-portabilize a Portable App for your personal use case, you might consider the handy
*Sourcedirectories.I don't want to put words in John's mouth, but as Dana Carvey and the former President Bush would say:
Not gonna do it! Wouldn't be prudent! *
-hea
You write:
And can you write how would this defeat anything?
which is an intentionally naive follow-up question to Gizmokid2005's clearly worded statements:
The point of having portable apps, is making them truly portable. This would defeat that purpose and would increase the amount of work that the people here have to do.
It's not naive. He gave no arguments, just a slogan. Up to now, nobody did.
As John explained multiple times in excruciating detail, reverting to a local install of a critical component breaks portability. Put simply, the local critical component isn't part of the packaged app so it's impossible to confidently know anything about its version, configuration, compatibility or safety. Not to mention that the app will [mis]behave differently depending on which host the drive's connected to. Ergo, it ain't portable. The limitless possibilities of [mis]configuration by end-users makes support untenable, especially for a free platform.
If you truly need the ability to de-portabilize a Portable App for your personal use case, you might consider the handy *Source directories.
Please reread what I wrote. 2 times before your post. THIS IS NOT GOING TO CAUSE GIMP PORTABLE USE LOCAL GTK UNLESS USER ASKS IT TO.
And I don't it to use the local, but portable, shared ones.
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
Again, you lead me to believe you have another copy of GTK on your stick besides the App-specific ones or the CommonFiles one. If that is true, can you save space by using your PATH idea to point to the CommonFiles copy and then delete your other copy? You would then simply need a batch file when you start your connected session for your other GTK apps to work.
I'm just trying to help.
Thanks, but it's not a solution for me. Now I have a well integrated pack of tools that works wherever I put it. I have a directory for shared libraries. "lib". On none media I put it on, it's in X:\PortableApps. So here's the 1st problem, I should either add a separate X:\PortableApps\CommonFiles directory, which would spoil the integration or rename the main directory to "PortableApps" and fix all shortcuts from the outside.
The 1st case is not acceptable for me. In the second I have 2 paths. Either rename "lib"->"CommonFiles" and fix all internal shortcuts...which is way too much work, as I said, it's well integrated package...or add separate "CommonFiles" directory and fix just GTK references. Very ugly solution isn't it?
I have a better one, I'll make GIMP use my %PATH%. The first think I thought about is doing the 5-minute modification of the launcher's code myself. Doing this every update? No good. So I'll write a launcher that starts GIMPPortable and forces it to work the way I want it to.
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
So you want us to change the way GIMP and Pidgin's launchers work, potentially causing other issues, just because of your oddball directory layout which you, for some reason, refuse to just use a CommonFiles\GTK directory in the same directory as GIMPPortable and PidginPortable?
Ain't happening. Done. Over. EOT.
Sometimes, the impossible can become possible, if you're awesome!
I want you to do the patch suggested one branch above. As I have no hope you will do it. I have no hope you'll do it, I'll write my launcher to start your launcher and I don't ask you to add it to the release. If you wanted to do this, internal path would be much better solution, wouldn't it?
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
I thought this was pretty clear: "Ain't happening. Done. Over. EOT."
A patch and potentially introducing bugs for a feature used by ONE user? Are you honestly insane?
Sometimes, the impossible can become possible, if you're awesome!
Are you questioning my sanity because I ask for a bug fix or because I fix the problems I have?
Let's better finish this discussion.
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
If you are running these on your cell-phone...then why would you have a local install of GTK anyways?! Honestly, what all could you be installing on YOUR PHONE through portable apps that would take 835MB? My ENTIRE portableapps directory on my current flash drive is only 530MB. That includes: 7-Zip, Aspell, CommandPrompt, Firefox, Gimp, GTK, Kompozer, Notepad++, NVU, OO, PidginPortable, (and the recompilation through pidgins website), PABackup, PAMenu, Sudoku, T-bird, Tunnelvision, VirtualDub, VLC, WINSCP, NOT too mention all the DATA for the aforementioned programs. With Pidgin it's over a year of chat logs in HTML, and over a years worth of 4 email accounts worth of email in t-bird...
Yes, making this "simple" change to the code, could potentially cause droves of issues by normal users who may have used a local program requiring GTK, but GTK being out of date and pidgin (or another program) needing a newer version that doesn't exist on the local machine. Not too mention, the problems with the AV companies, which I beg to differ with you, there are so many companies out there these days, and it would not be fixed within an hour...not even 24 hours. When there was a false-positive with a dll for LogMeIn, AVG didn't have it resolved for nearly 48 hours.
Plain and simple, this is not a request that is even worth considering.
I wrote it twice already. I'm NOT going to use local GTK. I want to use the one in my lib directory.
The things bigger than 10 MB:
Firefox - 320.5 MB
Miranda - 20.5
XAMPP - 24.6(installer only)
OpenOffice - 86.1
MinGW - 27.4
PSPad - 12.3
ClamWin - 29.7
EMCO Malware Destroyer - 27.7
Spybot S&D - 11.7
Common Libraries - 51 MB, mostly because of Python and GhostScript
Yes, making this "simple" change to the code, could potentially cause droves of issues by normal users who may have used a local program requiring GTK, but GTK being out of date and pidgin (or another program) needing a newer version that doesn't exist on the local machine.
As long as you have the standard, build-in GTK, there's no difference, your Pidgin won't notice that there's one installed in the system already!
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
How can you have 320 MB in your firefox dir? On my USB-HDD I have cookies, history, and other stuff enabled, as well as 10MB of extensions, and even then I only have 115MB of space being used.
"In three words I can sum up everything I've learned about life: it goes on." -- Robert Frost
"In three words I can sum up everything I've learned about life: baby ain't mine." -- Adam Holguin
I left cache on. When working from a slow drive I don't use FF anyway, so it speeds me up significantly.
"Those people who think they know everything are a great annoyance to those of us who do." Asimov