GNOME Bugzilla – Bug 490010
First launch of v.2.4.0 locks up
Last modified: 2008-10-30 20:01:56 UTC
I downloaded the binary of 2.4.0 from the usual site. When I ran setup, the installation went as expected. However, the first time I tried to run the GIMP it locked up and aborted installation. The status at the time it locked up said, "Starting Extensions extension-script-fu". No progress was shown on the progress bar while this was displayed. This occured several times, so I restarted the computer and tried again with the same results on multiple attempts. Since the installer removes the previous version of GIMP, I am now left without a working version of GIMP on this machine.
Created attachment 97817 [details] Screenshot of splash screen at lockup Screenshot of splash screen at lockup
Can you move away your personal GIMP folder and try again? Perhaps there is a problem migrating your settings from GIMP 2.2.
Just now I deleted the .gimp-2.2 folder and tried to launch 2.4 again with the same results. Maybe it needs to be reinstalled, so I will try to remove and reinstall 2.4.0 again later.
I ended up moving my scripts to another folder and then bringing them back a few at a time. It appears that at least some scripts that don't meet the new scheme syntax cause the problem when GIMP is launched. I would still say it is a problem, that GIMP should be more tolerant of this issue. But I'm up and running now, regardless.
Sure, the only thing that should happen is that the script doesn't work. Crashing the core or blocking its startup is not acceptable. If you isolated a script that causes the problem, it would help a lot if you could attach it to this bug report. This might be a duplicate of bug #490055 but I would like to make sure that there is not yet another problem.
I've attached two scripts. The dynamic range extender script was one of the crashers. It loaded and ran perfectly on v.2.2.13. The shadows & highlights script was not a crasher, but it had problems with unbound variables that I have now fixed. However, it is interesting because while the menu registry says _"<Image>/Script-Fu/Shadow/Shadows & Highlights", it instead finds its way under <Image>/Filters/Light and Shadow/Shadows & Highlights". I'm going to change the script so that it does register in the Light and Shadows menu because I like it there, but it's odd that it won't go where you tell it to go.
Created attachment 97994 [details] dynamic-range-extender version that causes program launch to fail.
Created attachment 97995 [details] Shadows & Highlights script that loads and runs OK, but installs in the wrong menu
Here's another script that isn't going where it is told to go. It loads fine, but while its menu registration line says "<Image>/Script-Fu/Alchemy/_Warp Sharp" it doesn't show up anywhere in any menu that I can find. Compare this to the registration line from dynamic-range-extender.scm that says "<Image>/Script-Fu/Photokit/_Dynamic Range Extender" which correctly ends up where it is supposed to go. If I change the Warp Sharp registration to "<Image>/Filters/Enhance/_Warp Sharp" it properly shows up under Filters/Enhance. I agree that the original direction this bug report was taking was a duplicate of bug #490055, but I believe in trying to figure this out another issue may have turned up. If you like, I will open a new report to cover these script-fu menu registration issues.
There's no issue here. Scripts that install into the old Script-Fu menu locations are intentionally relocated to the new sub menus. *** This bug has been marked as a duplicate of 490055 ***
That's not accurate. I currently have four script-fu's that are loading into a script-fu menu. This top level script-fu menu did not exist when I first installed 2.4.0, but when one of these four items (I don't recall which one was installed first) was install, the Script-Fu menu appeared. Three of the items are 1) dynamic range extender 2) vivid saturation and 3) smart sharpening, all by the same author. All three appear under "<Image>/Script-Fu/Photokit/". The fourth one is a script I wrote and it appears in "<Image>/Script-Fu". There is also the issue of the script I mentioned in comment #9 that doesn't show up anywhere. So the relocation process is not working consistently, or apparently as intended. I'm opening a new bug to address these issues.