GNOME Bugzilla – Bug 171200
GIMP HELP Problem
Last modified: 2008-01-15 12:50:44 UTC
When I want to show the GIMP help, which I downloaded to use it offline and the help viewer is the Internet Explorer it shows first a dialog to move the index.html to another location and after cancelled this, a dialog to copy the same file to another location. After cancelled this it shows the help file as it should be. (Beside: I did not find the help viewer for GIMP for Windows on the internet.) What is the Problem?
Huh? What exactly did you download and where from?
I guess we (me) should restart the effort to get the libgtkhtml2 based help viewer built on Win32.
I downloaded the GIMP Help file installer for Windows Pattforms, which I installed then on my Windows runned Gimp 2.2.4
I'd like to see a screenshot of these dialogs. Could you perhaps provide them and attach them to this bug-report? Thank you.
There is a post at GUG (http://gug.sunsite.dk/forum/?threadid=2667) that mentions some context menu handlers, made available by some registry modifications: http://www.winguides.com/registry/display.php/1004/ Now, if one of them would become the default action for handling files - each file, probably, this could explain the problem (and also explains why e.g. I don't see this, as I don't do such registry hacks). I'd say that this is NOTGNOME - people who like to play with their systems should think of side effects this might have.
Sorry for being away from this dsicussion. Now, the last comment pointed to the right direction. I had some registry modifications, where I allowed to show the entries "copy to..." and "move to ..." at the Explorer sub menu, when I click the right mouse button, contect menu. After I did undo the modification the help file is started in the browser properly. But I still think its a bug, since other programms I am running are working fine without these problems I mentioned above. One is PhotoFiltre of a french programmer. This is starting the help file with an internet explorer as well and there are no problems.
Does Fotofiltre use IE directly or the default browser?
PhotoFiltre is using the default browser.
That information would be very helpful if you could point us to the source code of PhotoFiltre.
I dont have the source code of PhotoFiltre, but I can give you the web address of the programmers page: http://www.photofiltre.com/ and email: photofiltre@free.fr. There you find more and probably you could contact Antonio Da Cruz the programmer. I mean it shouldnt be that difficult since other programms start websites as well and dont have the problem as GIMP has. Probably its a somehow very little miss set trigger GIMP uses opening the default browser. I am sorry, my excuses, I am not a programmer.
GIMP uses the API that Microsoft documents as to be used. But the involvement of GIMP developers with the win32 OS are limited and I think that if you are interested in fixing this problem, then it might be a good idea to investigate this further instead of expecting us to do something about it. I can of course point you to the GIMP source code that is related here. Actually, what we are talking about is a single line of code as discussed in comment #27 of bug #158463 (a report for which this one should be marked a duplicate of).
Got the code by email - Torsten, why didn't you paste it yourself? var S: string; begin S := 'http://www.photofiltre.com'; ShellExecute(GetDesktopWindow(), 'open', PChar(S), nil, nil, SW_SHOW); end; As it can be seen here, no local files are accessed, so this doesn't tell us how to do it right.
PhotoFiltre is using a local file : 'file:///C:/Programme/PhotoFiltre/PhotoFiltre.htm' I think Antonio Da Cruz just send me this small documentation how he handles to open the help file with the standard browser and just set S := 'http://www.photofiltre.com' as an example. I mean just define S:='file:///C:/Programme/PhotoFiltre/PhotoFiltre.htm' then its a local file. If it does not help then I do not know further. And probably this bug is not much more worth talking about: the results are kind of annoying but not problematic at all. But thanks anyway ;-)
Apparently the pasted ShellExecute() command differs from what GIMP uses. Reopening and adding Tor to CC (he added the win32 code to the webbrwoser plug-in).
GIMP's webbrowser plug-in uses ShellExecute (HWND_DESKTOP, "open", url, NULL, NULL, SW_SHOWNORMAL) I don't think GetDesktopWindow() vs. HWND_DESKTOP should have any dramatic effect. (HWND_DESKTOP == NULL). Not sure about SW_SHOWNORMAL vs. SW_SHOW. Anyway, if otherwise everything works as before, and it helps the special case of the original poster here with the Registry hack in place, sure it could be changed.
Let's see if this help - at least it still works on my machines, so it's probably not worse than before: 2005-06-04 Michael Schumacher <schumaml@cvs.gnome.org> * plug-ins/common/webbrowser.c: use GetDesktopWindow() and SW_SHOW as suggested in bug #171200. Applied to both branches.
I just installed GIMP, and I find that Help is broken in the same way that Torsten reported in his initial post, and in his followup in comment #6. My install, and the steps to reproduce the problem are... Windows XP SP2 Home Edition, with all critical updates. Internet Explorer v6.0.2900.2180...(SP2) RegSeeker (freeware): http://www.hoverdesk.net/freeware.htm download this utility and run it (see steps below) to add the registry entries that Torsten tells about in comment 6. My GIMP components, all downloaded on 3 Jun 2005: gtk+-2.6.7-setup-1.zip gimp-2.2.7-i586-setup.zip gimp-help-2-0.8-setup.zip To reproduce the problem with GIMP Help, do this first: 1. Run Regseeker 2. click Tweaks (in left column) 3. check the boxes [x] Add 'Copy to...' in context menu [x] Add 'Move to...' in context menu 4. click the 'Apply changes!' button Then, run GIMP and click on Help menu > Help You will now experience the GIMP Help problem I am experiencing, which is the same as reported by torsten... PROBLEM: When I want to show the GIMP help, which I downloaded to use it offline and the help viewer is the Internet Explorer it shows first a dialog to move the index.html to another location and after cancelled this, a dialog to copy the same file to another location. After cancelled this it shows the help file as it should be. What is the Problem? Now run Regseeker and uncheck the two boxes (Add 'Copy to', Add 'Move to') then run GIMP, and click on Help menu > Help. Yep, it works correctly now. Like Torsten, I feel that this problem is probably caused by a bug in the way GIMP accesses Help, or in Gimp Help itself because I have been using RegSeeker with 'Copy to/Move to' options enabled for years without experiencing any problems. Regseeker appears on many Favorite/Best utility lists, so I'm sure that many people have used it to add the Copy to/Move to context menu items. I hope this information will help sort the problem. Lilla
No, I am not going to run "Regseeker". "Doctor, doctor, it hurts when I do like this".
BTW, what do the Regseeker authors have to say about this - after all, changing the behaviour of a very basic command is quite serious? Did anyone who is hit by the problem contact them already?
Since this is obviously a misbehaviour of Regseeker, I am closing this report as NOTGNOME.
*** Bug 309790 has been marked as a duplicate of this bug. ***
I installed the latest version of GIMP 2.2.8 with the changes mentioned in #16. Unfortunately it did not work out. But thanks for the effort... For the moment it should be the best to disable the Move To/Copy To registry changes that should work fine. (Or just to click away the wrong placed boxes mentioned again in #17 ;.) Or just using the new implemented help browser of GIMP. The problem is not about RegSeeker since I am using X-Setup Pro for this registry changes. (And other programs dont have this problem as mentioned in #6. Using the command like in that programm couldnt help...) I was going to write to the authors of X Setup about this problems. I will bring this into the forum and probably there will be another hint to solve this...
the calls (as mentioned in #12 and #15) of the help file do not cause the problem. I posted this bug to the X Setup Forum (http://x-setup.net/forum/showthread.php?t=818) They gave a test program for the two different calls which works fine... That means the problem is not about the calls itself as well not about RegSeeker...
http://blogs.msdn.com/oldnewthing/archive/2004/02/02/66160.aspx is a ncie explanation why this can fail terribly - and someone from Microsoft should probably know... As a short summary: Copy to and Move to where never supposed to be on the context menu and are activated frequently - for example, whenever any program want to open a file.
*** Bug 486521 has been marked as a duplicate of this bug. ***