After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 171200 - GIMP HELP Problem
GIMP HELP Problem
Status: RESOLVED NOTGNOME
Product: GIMP
Classification: Other
Component: Help
2.2.x
Other Windows
: Normal normal
: ---
Assigned To: GIMP Bugs
GIMP Bugs
: 309790 486521 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-03-22 12:09 UTC by Torsten Streicher
Modified: 2008-01-15 12:50 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Torsten Streicher 2005-03-22 12:09:20 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?
Comment 1 Sven Neumann 2005-03-22 12:21:47 UTC
Huh? What exactly did you download and where from?
Comment 2 Michael Schumacher 2005-03-22 12:36:18 UTC
I guess we (me) should restart the effort to get the libgtkhtml2 based help
viewer built on Win32.
Comment 3 Torsten Streicher 2005-03-22 17:32:47 UTC
I downloaded the GIMP Help file installer for Windows Pattforms, which I 
installed then on my Windows runned Gimp 2.2.4
Comment 4 Sven Neumann 2005-04-05 11:15:32 UTC
I'd like to see a screenshot of these dialogs. Could you perhaps provide them
and attach them to this bug-report? Thank you.
Comment 5 Michael Schumacher 2005-05-11 10:41:23 UTC
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.
Comment 6 Torsten Streicher 2005-05-20 07:44:56 UTC
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.
Comment 7 Michael Schumacher 2005-05-20 08:40:40 UTC
Does Fotofiltre use IE directly or the default browser?
Comment 8 Torsten Streicher 2005-05-20 08:52:41 UTC
PhotoFiltre is using the default browser.
Comment 9 Sven Neumann 2005-05-20 22:19:04 UTC
That information would be very helpful if you could point us to the source code
of  PhotoFiltre.
Comment 10 Torsten Streicher 2005-05-21 00:15:52 UTC
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.
Comment 11 Sven Neumann 2005-05-21 01:40:22 UTC
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).
Comment 12 Michael Schumacher 2005-05-21 19:49:28 UTC
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.
Comment 13 Torsten Streicher 2005-05-21 21:08:53 UTC
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 ;-)
Comment 14 Michael Natterer 2005-05-21 23:20:59 UTC
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).
Comment 15 Tor Lillqvist 2005-05-23 09:09:44 UTC
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.
Comment 16 Michael Schumacher 2005-06-04 11:52:00 UTC
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.
Comment 17 Lilla 2005-06-04 19:36:33 UTC
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
Comment 18 Tor Lillqvist 2005-06-04 19:42:46 UTC
No, I am not going to run "Regseeker".

"Doctor, doctor, it hurts when I do like this".
Comment 19 Michael Schumacher 2005-06-04 22:02:32 UTC
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?
Comment 20 Sven Neumann 2005-07-05 21:52:48 UTC
Since this is obviously a misbehaviour of Regseeker, I am closing this report as
NOTGNOME.
Comment 21 Manish Singh 2005-07-08 15:51:25 UTC
*** Bug 309790 has been marked as a duplicate of this bug. ***
Comment 22 Torsten Streicher 2005-07-12 06:29:22 UTC
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...
Comment 23 Torsten Streicher 2005-07-12 12:13:34 UTC
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...
Comment 24 Michael Schumacher 2005-07-13 08:12:46 UTC
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.
Comment 25 Michael Schumacher 2007-10-14 09:48:21 UTC
*** Bug 486521 has been marked as a duplicate of this bug. ***