auto-deactivate of (extension) tool : where is it done?
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
new xinput device: no movement when button down
I'm writing a new xinput extension module. I'm implementing support for my device as a *NON-CORE* device.
[This is for gtk compiled with --xinput=xfree ]
I've got cursor movement working just fine. Plus, when I press on the pen, an appropriately dark splotch appears on the canvas.
However... gimp wont allow for any movement while a pen button is down. I press down, and a mark is made. I move the pen, and nothing happens until I stop pressure. At which point, the cursor appears in the spot I have moved the pen to, with no interveaning trail.
Debug output from my driver confirms that the driver is still sending MotionNotify events, while the button is down.
Can anyone suggest what I need to do, to make gimp happy? I'm not following the gimp code very well.
I wanted to use an alternate, 'pure X11' program like xink to do more direct testing... except I CANT FIND xink any more :-( kiwi.cs.berkeley.edu no longer exists
urgent help?
hi all,
i've a few doubts and requirements too. Please help
me with these.
1. I've to enable a plugin only when 2 images are
already opened by GIMP, how do i do it?
2. The output of my plugin is another image, Will i
be able to display it together with those 2 already
open images.
3. Finally, how can i get the image path from the
drawable ID(or for that matter, the image opened in
GIMP), that is obtained after opening the image.
4. Last but not the least, is the image
representation in GIMP and that of the libarary
IMAGEMAGICK compatible. Is there any way i can get
gimp's representation of the image from the other and
vice versa.
Please reply ASAP thank you
___
new xinput device: no movement when button down
Hi,
Philip Brown writes:
I'm writing a new xinput extension module. I'm implementing support for my device as a *NON-CORE* device.
[...]
Can anyone suggest what I need to do, to make gimp happy? I'm not following the gimp code very well.
I'd try to make GTK+ happy in the first place. As a side-effect this should as well satisfy The GIMP.
I wanted to use an alternate, 'pure X11' program like xink to do more direct testing... except I CANT FIND xink any more :-( kiwi.cs.berkeley.edu no longer exists
what about using testinput as found in the GTK+ source in the tests directory ?
Salut, Sven
new xinput device: no movement when button down
On Sat, Jun 01, 2002 at 09:43:02AM -0700, Philip Brown wrote:
However... gimp wont allow for any movement while a pen button is down. I press down, and a mark is made. I move the pen, and nothing happens until I stop pressure. At which point, the cursor appears in the spot I have moved the pen to, with no interveaning trail.
Yes, I've seen problems like this. I'm pretty certain it is GTK+ or GIMP at fault but I never tracked it further.
Nick.
new xinput device: no movement when button down
On Sun, Jun 02, 2002 at 02:53:57PM +0200, Sven Neumann wrote:
Philip Brown writes:
I'm writing a new xinput extension module. I'm implementing support for my device as a *NON-CORE* device.
[...]
Can anyone suggest what I need to do, to make gimp happy? I'm not following the gimp code very well.
I'd try to make GTK+ happy in the first place. As a side-effect this should as well satisfy The GIMP.
I just tried gsumi, and IT is happy. which by definition means GTK+ is happy. So it seems to be entirely a GIMP issue.
what about using testinput as found in the GTK+ source in the tests directory ?
thanks for the pointer - i didnt notice that before. it is also happy and works fine with my tablet.
new xinput device: no movement when button down
Well, I commented out the pointer_grab/ungrab in paint_core_button_press() and release()
in app/paint_core.c (gimp 1.2.3)
and that makes my tablet work.
I literally only have a few minutes every other day to poke at this, so I dont really have a chance to fully examine the code, and find out what a "proper" patch is.
Could someone who is more intimately familiar with gimp internals (and has a tablet :-) please look into this?
I am guessing that all you have to do is take OUT the 'AlwaysCore' hack for the wacom tablet, and you will see the same problems.
new xinput device: no movement when button down
Philip Brown writes:
Well, I commented out the pointer_grab/ungrab in paint_core_button_press() and release()
in app/paint_core.c (gimp 1.2.3)
and that makes my tablet work.
I literally only have a few minutes every other day to poke at this, so I dont really have a chance to fully examine the code, and find out what a "proper" patch is.
Could someone who is more intimately familiar with gimp internals (and has a tablet :-) please look into this?
I am guessing that all you have to do is take OUT the 'AlwaysCore' hack for the wacom tablet, and you will see the same problems.
Hi,
this seems related to http://bugzilla.gnome.org/show_bug.cgi?id=6901
Did you try to remove just the GDK_POINTER_MOTION_HINT_MASK? XInput drivers are known to send wrong motion hints so this may well be the reason for your problem.
(Checking "Perfect but slow Pointer Tracking" in preferences does the same without patching the source, but will work only for the paint tools)
ciao, --mitch
new xinput device: no movement when button down
On Wed, Jun 05, 2002 at 11:23:02AM +0200, Michael Natterer wrote:
this seems related to http://bugzilla.gnome.org/show_bug.cgi?id=6901
Did you try to remove just the GDK_POINTER_MOTION_HINT_MASK? XInput drivers are known to send wrong motion hints so this may well be the reason for your problem.
Hmm. I read the bugid, but it didnt really tell me what gimp is expecting
in this case. Can you enlighten me?
I didnt see anything about 'motion hint' in the xinput 'port' document.
(Checking "Perfect but slow Pointer Tracking" in preferences does the same without patching the source, but will work only for the paint tools)
It was already checked, under Interface->Image Windows. I unchecked it in a vanilla gimp1.2.3, with no difference. The grab still stops anything getting drawn except a single dot.
Also - you seem to imply that it is possible to use a non-core xinput device for things other than plain drawing. I'd like to know how. I find it somewhat irritating, for example, that a button3 on my pen will bring up a menu, that I can do nothing with , with the pen. Not only can I do nothing with it: I have to grab the core mouse to get rid of it.
It seems like there has been too much of an assumption that the user will
run their xinput device with the 'AlwaysCore' hack.
I think it should be quite possible to have a very usable interface,even
when the pen is non-core.
Making that menu traversable would be a great start.
new xinput device: no movement when button down
Hmmm. Another piece of wierdness :
my commenting out the gdk_pointer_grab makes the airbrush, pencil, and paintbrush work.
But NOT the 'ink' drawing tool.
any ideas?
new xinput device: no movement when button down
Philip Brown writes:
On Wed, Jun 05, 2002 at 11:23:02AM +0200, Michael Natterer wrote:
this seems related to http://bugzilla.gnome.org/show_bug.cgi?id=6901
Did you try to remove just the GDK_POINTER_MOTION_HINT_MASK? XInput drivers are known to send wrong motion hints so this may well be the reason for your problem.
Hmm. I read the bugid, but it didnt really tell me what gimp is expecting in this case. Can you enlighten me?
GIMP just expects that the motion events' "is_hint" boolean is set correctly. Motion hints are used to reduce the number of motion events X delivers.
I didnt see anything about 'motion hint' in the xinput 'port' document.
Which is probably the reason why at least the wacom driver sets them wrongly and thus breaks software which request hints.
It should just choose to not send hints at all end everything would be fine (at least on the motion hint front :-)
(Checking "Perfect but slow Pointer Tracking" in preferences does the same without patching the source, but will work only for the paint tools)
It was already checked, under Interface->Image Windows. I unchecked it in a vanilla gimp1.2.3, with no difference. The grab still stops anything getting drawn except a single dot.
Then, unfortunately, the bug you see seems not to be related to the hints.
Also - you seem to imply that it is possible to use a non-core xinput device for things other than plain drawing. I'd like to know how.
Nope, I just wanted to make clear that only the paint tools have the builtin possibility to switch hints on/off. Other tools like the rect_select tool don't have this.
I find it somewhat irritating, for example, that a button3 on my pen will bring up a menu, that I can do nothing with , with the pen. Not only can I do nothing with it: I have to grab the core mouse to get rid of it.
Yes, i have the same effect. We could check if the device which sent button3 is the core pointer...
It seems like there has been too much of an assumption that the user will run their xinput device with the 'AlwaysCore' hack.
There is no such assumption.
I think it should be quite possible to have a very usable interface,even when the pen is non-core.
Making that menu traversable would be a great start.
I don't understand what you mean by this.
BTW, would you try gimp 1.3.7 (or CVS) and try if the problem still persists there? If they behave different we'd have a hint how to fix 1.2. If 1.3.7 has the effect too, we have a bug on both branches :(
ciao, --mitch
new xinput device: no movement when button down
On Wed, Jun 05, 2002 at 09:19:07PM +0200, Michael Natterer wrote:
..
I find it somewhat irritating, for example, that a button3 on my pen will bring up a menu, that I can do nothing with , with the pen. Not only can I do nothing with it: I have to grab the core mouse to get rid of it.
Yes, i have the same effect. We could check if the device which sent button3 is the core pointer...
Okay, glad to see someone else sees that problem is a problem :-)
BTW, would you try gimp 1.3.7 (or CVS) and try if the problem still persists there? If they behave different we'd have a hint how to fix 1.2. If 1.3.7 has the effect too, we have a bug on both branches :(
I already tried. I was very disappointed to see that you guys seem to be following in GNOME's footsteps, and suddenly requiring 3 times the amount of library dependancies. With the similar effect that the required libraries dont build well on Solaris.
To be explicit, I cannot build the required libraries for gimp 1.3.7 on Solaris, my development platform.
[PS: I am on the list. No need to Cc me]
new xinput device: no movement when button down
Philip Brown wrote:
BTW, would you try gimp 1.3.7 (or CVS) and try if the problem still persists there? If they behave different we'd have a hint how to fix 1.2. If 1.3.7 has the effect too, we have a bug on both branches :(
I already tried. I was very disappointed to see that you guys seem to be following in GNOME's footsteps, and suddenly requiring 3 times the amount of library dependancies.
I feel your pain.
This is as good a point to ask as any; in following the latest incarnation of the crazy dep-chain I ran into a dead-end finding the mysterious 'fontconfig' (fontconfig is needed by pango is needed by gtk2 is needed by gimp). Anyone know where I can find such a thing? I thought that it sounded like it was probably part of pkgconfig (pkgconfig is needed by... etc) but it doesn't seem to be.
Thanks,
--Adam
new xinput device: no movement when button down
At 21:37 05.06.02 +0100, Adam D. Moss wrote:
I already tried. I was very disappointed to see that you guys seem to be following in GNOME's footsteps, and suddenly requiring 3 times the
amount of
library dependancies.
I feel your pain.
This is as good a point to ask as any; in following the latest incarnation of the crazy dep-chain I ran into a dead-end finding the mysterious 'fontconfig' (fontconfig is needed by pango is needed by gtk2 is needed by gimp). Anyone know where I can find such a thing? I thought that it sounded like it was probably part of pkgconfig (pkgconfig is needed by... etc) but it doesn't seem to be.
The info was on gtk-devel just a few days ago. I'm pasting it here while trying to no comment on cvs gtk/pango brokeness for other backends as X11 ...
Hans
At 11:44 04.06.02 -0400, Owen Taylor wrote:
Pango HEAD now is using fontconfig and Xft2:
Notes:
* A 'fcpackage' source tarball containing both of these can be found at:
* Red Hat RPMS can be found at:
http://people.redhat.com/otaylor/xft-rpms/
* If you aren't interested in bleeding-edge Pango developement, you should be using use the pango-1-0 branch of Pango.
* Until we get a Win32 port of fontconfig, the pango-1-0 branch will also be needed on Windows.
* The fontconfig library is now used for both the Xft and FT2 backends. mini-xft is gone. The font configuration file is found in /etc/fonts/fonts.conf
-------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert
dependancies (used to be xinput)
On Wed, Jun 05, 2002 at 09:37:41PM +0100, Adam D. Moss wrote:
...
This is as good a point to ask as any; in following the latest incarnation of the crazy dep-chain I ran into a dead-end finding the mysterious 'fontconfig' (fontconfig is needed by pango is needed by gtk2 is needed by gimp). Anyone know where I can find such a thing? I thought that it sounded like it was probably part of pkgconfig (pkgconfig is needed by... etc) but it doesn't seem to be.
seems that the latest version of pkgconfig is not compatible with the
latest version of pango.
Which is a really good reason to not do this sort of nonsense.
Just use autoconfig like always, instead of this silly pkgconfig.
It's too redhat, for a software tool that's supposed to be cross-UNIX
compatible.
dependancies (used to be xinput)
ons 2002-06-05 klockan 23.28 skrev Philip Brown:
This is as good a point to ask as any; in following the latest incarnation of the crazy dep-chain I ran into a dead-end finding the mysterious 'fontconfig' (fontconfig is needed by pango is needed by gtk2 is needed by gimp). Anyone know where I can find such a thing? I thought that it sounded like it was probably part of pkgconfig (pkgconfig is needed by... etc) but it doesn't seem to be.
seems that the latest version of pkgconfig is not compatible with the latest version of pango.
Which is a really good reason to not do this sort of nonsense. Just use autoconfig like always, instead of this silly pkgconfig. It's too redhat, for a software tool that's supposed to be cross-UNIX compatible.
Good conspiracy theory or troll, but the problem is that fontconfig has nothing to do with pkgconfig, so that puts your little offtopic rant at shame.
fontconfig is designed by Keith Packard of XFree86 fame. There's a fontconfig tarball at http://keithp.com/~keithp/download/. Haven't tried it though.
Christian
dependancies (used to be xinput)
On Wed, Jun 05, 2002 at 11:35:25PM +0200, Christian Rose wrote:
ons 2002-06-05 klockan 23.28 skrev Philip Brown:
seems that the latest version of pkgconfig is not compatible with the latest version of pango.
Which is a really good reason to not do this sort of nonsense. Just use autoconfig like always, instead of this silly pkgconfig. It's too redhat, for a software tool that's supposed to be cross-UNIX compatible.Good conspiracy theory or troll, but the problem is that fontconfig has nothing to do with pkgconfig, so that puts your little offtopic rant at shame.
Actually, fontconfig has nothing to do with the issues *I* had compiling (as far as I know). That was the original poster's problem.
My problems hit because of 'pangoft2', which is required by gtk1.3.7, but is NOT INSTALLED by pango1.0.2, the latest version of pango.
Here's a fuller list of all the issues I have compiling the various dependancies under solaris, for the curious:
======================================================================
glib2.0 fails with non-GNU make:
...
Making all in docs
Making all in reference
Making all in glib
make: Fatal error: Don't know how to make target `all-local'
Current working directory /home/phil/build/glib-2.0.3/docs/reference/glib
GNU make is 'recommended', but not stated as required. The really stupid thing is, its a bogus dependancy. Doing gmake at that point, doesnt seem to actually compile anything extra.
Similar problem with atk 1.0.2. however, GNU make is not mentioned at all, "recommended" or otherwise
make: Fatal error: Don't know how to make target `all-local' Current working directory /home/phil/build/atk-1.0.2/docs
pango suffers from similar GNU-make-itis
pkg-config when called from other libraries' configure scripts, keeps whining about 'sh: gnome-config: not found' eg:
checking for libpng12... sh: gnome-config: not found
gtk+-2.0.3 README claims that png, jpg, and tiff libraries are optional. However, in gtk+-2.0.3/gdk-pixbuf
/usr/ccs/bin/ld -G -h libpixbufloader-png.so -o .libs/libpixbufloader-png.so io-png.lo -R/home/phil/build/gtk+-2.0.3/gdk-pixbuf/.libs -R/directio/lib -R/directio/lib -L/directio/lib -lpng -lz ./.libs/libgdk_pixbuf-2.0.so /directio/lib/libgmodule-2.0.so -ldl /directio/lib/libgobject-2.0.so /directio/lib/libglib-2.0.so -lm -lc ld: fatal: library -lpng: not found ld: fatal: File processing errors. No output written to .libs/libpixbufloader-png.so
Similarly for -ljpeg, once I get over the png error. Similarly for -ltiff, once I get over the jpeg error.
In gtk/stock-icons, failed to load "./stock_add_16.png": Failed to load image './stock_add_16.png': Fatal error in PNG image file: Incompatible libpng version in application and library *** Error code 1
[This was with libpng1.2; downgraded to 1.0.2, and reconfigured... ]
Hit another GNU-make-ism in docs/reference/gdk-pixbuf
Making all in gdk-pixbuf
make: Fatal error: Don't know how to make target `all-local'
Current working directory
/home/phil/build/gtk+-2.0.3/docs/reference/gdk-pixbuf
*** Error code 1
And finally, the killer, while trying to configure gimp 1.3.7:
checking for GTK+ - version >= 2.0.0... yes (version 2.0.3)
checking for pangoft2 >= 1.0.0... sh: gnome-config: not found
sh: gnome-config: not found
Package pangoft2 was not found in the pkg-config search path.
Perhaps you should add the directory containing `pangoft2.pc'
to the PKG_CONFIG_PATH environment variable
No package 'pangoft2' found
And before you say I should set my PKG_CONFIG_PATH... 'pangoft2' **was** **not** **installed** by pango1.0.2, even when I used gmake to compile and install, from scratch.
$ find /usr/local -name 'pangoft*' -print
returns nothing.
new xinput device: no movement when button down
On Wed, Jun 05, 2002 at 10:57:13PM +0200, Hans Breuer wrote:
...
The info was on gtk-devel just a few days ago. I'm pasting it here while trying to no comment on cvs gtk/pango brokeness for other backends as X11 ...Hans
At 11:44 04.06.02 -0400, Owen Taylor wrote:
...
* If you aren't interested in bleeding-edge Pango developement, you should be using use the pango-1-0 branch of Pango.
Unfortunately, that isnt very informative for people who are downloading tarfiles, rather than using CVS. :-(
We need "only use pango x.y.z tarball"
dependancies (used to be xinput)
On Wed, Jun 05, 2002 at 04:05:18PM -0700, Philip Brown wrote:
And finally, the killer, while trying to configure gimp 1.3.7: ...
Package pangoft2 was not found in the pkg-config search path. ...
$ find /usr/local -name 'pangoft*' -printreturns nothing.
BTW: I went back and did a configure ; gmake; gmake install for pango 1.0.0
that did not install pangoft2* anywhere either, although i certainly see
pango-1.0.0/pango/pangoft2.h
sitting in the source directories.
same with pango-1.0.2/pango/pangoft2.h
new xinput device: no movement when button down
On Wed, Jun 05, 2002 at 09:09:24AM -0700, Philip Brown wrote:
my commenting out the gdk_pointer_grab makes the airbrush, pencil, and paintbrush work.
But NOT the 'ink' drawing tool.
Seems as those the airbrush, etc. share a common routine, paint_core_button_press(), whereas the ink tool has its own ink_button_press()
same thing: I commented out the pointer grab in there, and matched up with ink_button_release(), and now the ink drawing tool works for me okay.
new xinput device: no movement when button down
"Adam D. Moss" writes:
Philip Brown wrote:
BTW, would you try gimp 1.3.7 (or CVS) and try if the problem still persists there? If they behave different we'd have a hint how to fix 1.2. If 1.3.7 has the effect too, we have a bug on both branches :(
I already tried. I was very disappointed to see that you guys seem to be following in GNOME's footsteps, and suddenly requiring 3 times the amount of library dependancies.
I feel your pain.
This is as good a point to ask as any; in following the latest incarnation of the crazy dep-chain I ran into a dead-end finding the mysterious 'fontconfig' (fontconfig is needed by pango is needed by gtk2 is needed by gimp). Anyone know where I can find such a thing? I thought that it sounded like it was probably part of pkgconfig (pkgconfig is needed by... etc) but it doesn't seem to be.
Hi Adam,
It's just the HEAD version of pango which requires fontconfig, you probably wanted to checkout the "pango-1-0" branch.
The branches are glib-2-0, pango-1-0, atk HEAD, gtk-2-0.
ciao, --mitch
new xinput device: no movement when button down
Philip Brown writes:
On Wed, Jun 05, 2002 at 09:19:07PM +0200, Michael Natterer wrote:
..
I find it somewhat irritating, for example, that a button3 on my pen will bring up a menu, that I can do nothing with , with the pen. Not only can I do nothing with it: I have to grab the core mouse to get rid of it.
Yes, i have the same effect. We could check if the device which sent button3 is the core pointer...
Okay, glad to see someone else sees that problem is a problem :-)
BTW, would you try gimp 1.3.7 (or CVS) and try if the problem still persists there? If they behave different we'd have a hint how to fix 1.2. If 1.3.7 has the effect too, we have a bug on both branches :(
I already tried. I was very disappointed to see that you guys seem to be following in GNOME's footsteps, and suddenly requiring 3 times the amount of library dependancies. With the similar effect that the required libraries dont build well on Solaris.
To be explicit, I cannot build the required libraries for gimp 1.3.7 on Solaris, my development platform.
What library exactly are you unable to build? We resolved some Solaris build issues the night before the 1.3.7 release on irc...
ciao, --mitch
new xinput device: no movement when button down
Hi,
Philip Brown writes:
BTW, would you try gimp 1.3.7 (or CVS) and try if the problem still persists there? If they behave different we'd have a hint how to fix 1.2. If 1.3.7 has the effect too, we have a bug on both branches :(
I already tried. I was very disappointed to see that you guys seem to be following in GNOME's footsteps, and suddenly requiring 3 times the amount of library dependancies. With the similar effect that the required libraries dont build well on Solaris.
I don't think it is as worth as you describe it here. We have been very careful about choosing our dependencies. The only dependency that was added to GIMP-1.3 that wasn't part of GIMP-1.2 or hasn't been introduced by GTK+-2.0 is libart2.
To be explicit, I cannot build the required libraries for gimp 1.3.7 on Solaris, my development platform.
you should file bug-reports against the required packages then. Solaris is very special in lots of places and you can't expect free software developers to know and care about these little details by themselves.
Salut, Sven
new xinput device: no movement when button down
Hi,
"Adam D. Moss" writes:
I feel your pain.
This is as good a point to ask as any; in following the latest incarnation of the crazy dep-chain I ran into a dead-end finding the mysterious 'fontconfig' (fontconfig is needed by pango is needed by gtk2 is needed by gimp). Anyone know where I can find such a thing? I thought that it sounded like it was probably part of pkgconfig (pkgconfig is needed by... etc) but it doesn't seem to be.
you shouldn't be using unstable development versions of glib, pango and gtk+. If you are using CVS, please make sure that you checkout the stable branches, glib-2-0, pango-1-0 and gtk-2-0. If you insist on working with the unstable versions, subscribe to gtk-devel-list where this stuff is being discussed in all details.
Salut, Sven
dependancies (used to be xinput)
Hi,
Philip Brown writes:
seems that the latest version of pkgconfig is not compatible with the latest version of pango.
this is complete nonsense. Please don't say this kind of stuff on public mailing-lists.
Which is a really good reason to not do this sort of nonsense. Just use autoconfig like always, instead of this silly pkgconfig. It's too redhat, for a software tool that's supposed to be cross-UNIX compatible.
you obviously didn't understand what pkg-config does since it does a completely different thing than autoconf and in no way intents to replace it.
Salut, Sven
dependancies (used to be xinput)
Hi,
Philip Brown writes:
My problems hit because of 'pangoft2', which is required by gtk1.3.7, but is NOT INSTALLED by pango1.0.2, the latest version of pango.
and there is the file INSTALL which you should have read:
3. We require PangoFT2, a Pango backend that uses FreeType2. Make sure you have FreeType2 installed before you compile Pango.
if you had freetype2 installed, PangoFT2 would probably have been built and installed.
Here's a fuller list of all the issues I have compiling the various dependancies under solaris, for the curious:
no, we don't want and can't care about your problems compiling glib. You should file a bug-report against glib instead.
BTW. Sun's make is really akward and I don't see why you are putting extra pain on you and other people by refusing to install GNU make. It's a well known fact that a whole bunch of GNU software requires GNU make and that it definitely makes your life easier to install and use it.
pkg-config when called from other libraries' configure scripts, keeps whining about 'sh: gnome-config: not found' eg:
checking for libpng12... sh: gnome-config: not found
this is a stupid problem with pkg-config that tries some hardcoded fallbacks if it can't find the .pc file it should look for. I don't like this fact either but Havoc seems to think that it is a good idea.
gtk+-2.0.3 README claims that png, jpg, and tiff libraries are optional.
they are required but you may choose to switch this requirement off and build without them. You will end up with an image manipulation program that doesn't support the most important image formats.
However, in gtk+-2.0.3/gdk-pixbuf
GTK+ depends on png, jpg, and tiff just as GIMP depends on them. This is a good choice since application developers can then be sure that the functionality to load these image file formats is available. You should only switch these dependencies off (by using the --without-foo configure options) if you are building GTK+ for a special target like an embedded device where you know exactly what software will be using GTK+ later.
And finally, the killer, while trying to configure gimp 1.3.7:
checking for GTK+ - version >= 2.0.0... yes (version 2.0.3) checking for pangoft2 >= 1.0.0... sh: gnome-config: not found sh: gnome-config: not found
Package pangoft2 was not found in the pkg-config search path. Perhaps you should add the directory containing `pangoft2.pc' to the PKG_CONFIG_PATH environment variable No package 'pangoft2' foundAnd before you say I should set my PKG_CONFIG_PATH... 'pangoft2' **was** **not** **installed** by pango1.0.2, even when I used gmake to compile and install, from scratch.
$ find /usr/local -name 'pangoft*' -print
returns nothing.
I will end this mail with the statement I started it with:
and there is the file INSTALL which you should have read:
3. We require PangoFT2, a Pango backend that uses FreeType2. Make sure you have FreeType2 installed before you compile Pango.
if you had freetype2 installed, PangoFT2 would probably have been built and installed.
Salut, Sven
new xinput device: no movement when button down
Hi,
Philip Brown writes:
* If you aren't interested in bleeding-edge Pango developement, you should be using use the pango-1-0 branch of Pango.
Unfortunately, that isnt very informative for people who are downloading tarfiles, rather than using CVS. :-(
We need "only use pango x.y.z tarball"
use whatever tarball you like. There is no tarball released (yet) that would require fontconfig.
pango-1.0.2 would be appropriate. Or pango-1.0.1 since it doesn't have the stupid bug in pango_ft2_fontmap_list_families that makes GIMP's font selector crash.
Salut, Sven
dependancies
On Thu, Jun 06, 2002 at 11:08:36AM +0200, Sven Neumann wrote:
Philip Brown writes:
Which is a really good reason to not do this sort of nonsense. Just use autoconfig like always, instead of this silly pkgconfig. It's too redhat, for a software tool that's supposed to be cross-UNIX compatible.
you obviously didn't understand what pkg-config does since it does a completely different thing than autoconf and in no way intents to replace it.
From the pkgconfig README:
"pkg-config is a script to make putting together all the build flags when compiling/linking a lot easier. "
Sounds a whole like like autoconf to me. Or at most, autoconf plus libtool. Which you guys already use. So pkg-config is redundant.
To put the same thing another way: autoconf+libtool seemed to work fine for gimp1.2.3. So if it wasnt broke, why are you trying to 'fix' it?
dependancies
Another dependancy issue:
In the INSTALL file, #5, "you MAY want to install other third party..." stuff, should be reworded to
"we EXPECT the following third-party libraries to be installed".
"may" implies an optional thing, that configure will automatically figure
out and work around.
"expect" indicates that configure expects these things by default, and
breaks if they are not installed.
[like libgimpprint, in addition to all the other stuff like libpng. etc]
dependancies
Philip Brown writes:
> "pkg-config is a script to make putting together all the build
> flags when compiling/linking a lot easier. "
> Sounds a whole like like autoconf to me.
Umm, no. Autoconf produces a configure script, using large amounts of m4 code and whatnot. pkg-config only combines static information from a couple of (small) files and outputs one line of text. They do *not* do the same thing, not by a long shot.
The configure.in file that autoconf reads can contain calls to pkg-config (or, more correctly, m4 macro calls that expand to shell code that calls pkg-config).
(Yes, one could write configure scripts (or, configure.in files, or m4 macros used in such) without using pkg-config. However, using pkg-config makes the configure.in files *less* complex.)
(I am not saying that autoconf, pkg-config, libtool etc form an ideal solution. It can be very hard to understand what is going on. They are coded in shell, m4 and Perl. Perhaps it would be better to combine them *all*, including make, into one tool, written in one language. Or maybe not. But until something better comes along, and authors adopt it, no use whining.)
--tml
dependancies
On Fri, Jun 07, 2002 at 08:02:35AM +0300, Tor Lillqvist wrote:
Philip Brown writes:
> "pkg-config is a script to make putting together all the build > flags when compiling/linking a lot easier. "> Sounds a whole like like autoconf to me.
Umm, no. Autoconf produces a configure script, using large amounts of m4 code and whatnot. pkg-config only combines static information from a couple of (small) files and outputs one line of text. They do *not* do the same thing, not by a long shot.
so far, you seem to have described a situation that implies that autoconf can work without pkgconfig, but pkgconfig isnt that useful without autoconf.
You did not mention, however, why pkgconfig was suddenly added to gimp1.3.7, when it was not neccessary for gimp1.2.x
(Yes, one could write configure scripts (or, configure.in files, or m4 macros used in such) without using pkg-config. However, using pkg-config makes the configure.in files *less* complex.)
really?
$ ls -l gimp-1.*/configure -rwxr-xr-x 1 phil other 392867 Feb 9 22:21 gimp-1.2.3/configure* -rwxr-xr-x 1 phil other 598688 May 30 06:34 gimp-1.3.7/configure*
To me, longer usually == "more complex".
Okay, thats not entirely fair, since there's more stuff in 1.3.7. And maybe pkgconfig helps lots of output, but simplifies the INPUT stuff.
$ ls -l gimp-1.*/configure.in -rw-r--r-- 1 phil other 28462 Feb 3 19:23 gimp-1.2.3/configure.in -rw-r--r-- 1 phil other 33696 May 30 06:28 gimp-1.3.7/configure.in
Hmm. no, dont see any significant savings there either :-)
So far, I just see extra hassle, to what is already a big hassle tracking down umpteen different new packages if you're not running linux or something that has them already.
dependancies
On Thu, Jun 06, 2002 at 10:09:02PM -0700, Philip Brown wrote: [...]
so far, you seem to have described a situation that implies that autoconf can work without pkgconfig, but pkgconfig isnt that useful without autoconf.
Please, this is quite boring for this list. At least do some research first. I regularly use pkg-config from the command line:
gcc `pkg-config --cflags --libs libgnomeui-2.0` foo.c
to build something that depends on libgnomeui and friends. This is a regular rule in some Makefiles I have,
Can we please revert to exciting Gimo features now? :(
Malcolm
dependancies
On 2002-06-06 at 2209.02 -0700, Philip Brown typed this mail:
On Fri, Jun 07, 2002 at 08:02:35AM +0300, Tor Lillqvist wrote:
You did not mention, however, why pkgconfig was suddenly added to gimp1.3.7, when it was not neccessary for gimp1.2.x
probably you should stick with the stable branch. i don't know why it hasn't been suggested before.
really?
$ ls -l gimp-1.*/configure -rwxr-xr-x 1 phil other 392867 Feb 9 22:21 gimp-1.2.3/configure* -rwxr-xr-x 1 phil other 598688 May 30 06:34 gimp-1.3.7/configure*
here is another example of why the stable branch is more suited to you and your computer.
To me, longer usually == "more complex".
also, this screams "stable packages only". sticking with the stable gimp is prolly just the ticket.
Okay, thats not entirely fair, since there's more stuff in 1.3.7. And maybe pkgconfig helps lots of output, but simplifies the INPUT stuff.
$ ls -l gimp-1.*/configure.in -rw-r--r-- 1 phil other 28462 Feb 3 19:23 gimp-1.2.3/configure.in -rw-r--r-- 1 phil other 33696 May 30 06:28 gimp-1.3.7/configure.in
yep. stick with the stable gimp. 1.2 is a fine gimp.
Hmm. no, dont see any significant savings there either :-)
So far, I just see extra hassle, to what is already a big hassle tracking down umpteen different new packages if you're not running linux or something that has them already.
you make the best arguement for yourself not delving into development. maybe you should take this to the user list.
carol
dependancies
On Fri, Jun 07, 2002 at 02:21:39AM -0400, Carol Spears wrote:
So far, I just see extra hassle, to what is already a big hassle tracking down umpteen different new packages if you're not running linux or something that has them already.
you make the best arguement for yourself not delving into development. maybe you should take this to the user list.
I'm trying to encourage the developers, to make it easy for future users. That should be the goal of good software development: to make it easier for users, rather than easier for the programmers.
That is to say, making things easier for the programmers is great, as long as it doesnt come at the EXPENSE of the users.
dependancies
Hi,
Philip Brown writes:
On Thu, Jun 06, 2002 at 11:08:36AM +0200, Sven Neumann wrote:
you obviously didn't understand what pkg-config does since it does a completely different thing than autoconf and in no way intents to replace it.
From the pkgconfig README:
"pkg-config is a script to make putting together all the build flags when compiling/linking a lot easier. "
Sounds a whole like like autoconf to me. Or at most, autoconf plus libtool. Which you guys already use. So pkg-config is redundant.
To put the same thing another way: autoconf+libtool seemed to work fine for gimp1.2.3. So if it wasnt broke, why are you trying to 'fix' it?
could you please just stop talking about things you don't understand. Thanks.
Salut, Sven
FYI: pkg-config replaces glib-config, gtk-config, gimp-config and all those other foo-config scripts that have been around in the time before pkg-config.
dependancies
Hi,
Philip Brown writes:
I'm trying to encourage the developers, to make it easy for future users. That should be the goal of good software development: to make it easier for users, rather than easier for the programmers.
That is to say, making things easier for the programmers is great, as long as it doesnt come at the EXPENSE of the users.
your plan of encouraging people is doomed to fail unless you change your attitude.
We put a lot of effort into maintaining our tree and making compilation as easy as possible. We have spent a lot of our free time to make GIMP compile on platforms we not even have access too. This has been possible because people that use such platforms sent detailed descriptions of their problems and suggestion on how to improve them. Some even sent patches which is even more appreciated.
You on the other hand show up and without deeper knowledge state that we are doing things all wrong because it doesn't work for you. You question the use of pkg-config as if we have a choice whether to use it or not to use it. You didn't even read it's man-page to inform yourself about it's purpose.
Salut, Sven
new xinput device: no movement when button down
Michael Natterer wrote:
This is as good a point to ask as any; in following the latest incarnation of the crazy dep-chain I ran into a dead-end finding the mysterious 'fontconfig' (fontconfig is needed by pango is needed by gtk2 is needed by gimp). Anyone know where I can find such a thing? I thought that it sounded like it was probably part of pkgconfig (pkgconfig is needed by... etc) but it doesn't seem to be.
Hi Adam,
It's just the HEAD version of pango which requires fontconfig, you probably wanted to checkout the "pango-1-0" branch.
The branches are glib-2-0, pango-1-0, atk HEAD, gtk-2-0.
Thanks! Got fontconfig now.
The reason I was trying pango HEAD was that pango-1-0
does not compile for me. However, the same problem (below)
occurs for me on HEAD too. D'oh.
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -DPANGO_ENABLE_ENGINE
-DSYSCONFDIR=\"/usr/local/etc\" -DLIBDIR=\"/usr/local/lib\
" -DG_DISABLE_DEPRECATED -I/usr/local/include
-I/usr/local/include/freetype2 -I/usr/X11R6/include -I../.. -g -O2 -Wa
ll -D_REENTRANT -I/usr/local/include/glib-2.0
-I/usr/local/lib/glib-2.0/include -Wp,-MD,.deps/pango-ot-info.pp -c pa
ngo-ot-info.c -fPIC -DPIC -o pango-ot-info.o
In file included from /usr/local/include/glib-2.0/gobject/gboxed.h:26,
from /usr/local/include/glib-2.0/glib-object.h:25,
from pango-ot-private.h:27,
from pango-ot-info.c:22:
/usr/local/include/glib-2.0/gobject/gtype.h:92: syntax error before
`typedef'
@@gtype.h:91:#if GLIB_SIZEOF_LONG == GLIB_SIZEOF_SIZE_T
@@gtype.h:92:typedef gulong GType;
/usr/local/include/glib-2.0/gobject/gtype.h:167: syntax error before
`gchar'
@@gtype.h:167:G_CONST_RETURN gchar* g_type_name (GType type);
/usr/local/include/glib-2.0/gobject/gtype.h:335: syntax error before
`gchar'
/usr/local/include/glib-2.0/gobject/gtype.h:336: syntax error before
`gchar'
In file included from /usr/local/include/glib-2.0/glib-object.h:25,
from pango-ot-private.h:27,
from pango-ot-info.c:22:
/usr/local/include/glib-2.0/gobject/gboxed.h:28: parse error before
`G_BEGIN_DECLS'
/usr/local/include/glib-2.0/gobject/gboxed.h:36: syntax error before
`typedef'
In file included from /usr/local/include/glib-2.0/glib-object.h:26,
from pango-ot-private.h:27,
from pango-ot-info.c:22:
/usr/local/include/glib-2.0/gobject/genums.h:28: parse error before
`G_BEGIN_DECLS'
/usr/local/include/glib-2.0/gobject/genums.h:46: syntax error before
`typedef'
In file included from /usr/local/include/glib-2.0/gobject/gobject.h:27,
from /usr/local/include/glib-2.0/glib-object.h:27,
from pango-ot-private.h:27,
[cut -- lots more like this]
new xinput device: no movement when button down
Hi,
"Adam D. Moss" writes:
Thanks! Got fontconfig now.
The reason I was trying pango HEAD was that pango-1-0 does not compile for me. However, the same problem (below) occurs for me on HEAD too. D'oh.
You expect the HEAD branch to compile if you can't get the stable version to build???
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -DPANGO_ENABLE_ENGINE -DSYSCONFDIR=\"/usr/local/etc\" -DLIBDIR=\"/usr/local/lib\ " -DG_DISABLE_DEPRECATED -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/X11R6/include -I../.. -g -O2 -Wa ll -D_REENTRANT -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -Wp,-MD,.deps/pango-ot-info.pp -c pa ngo-ot-info.c -fPIC -DPIC -o pango-ot-info.o In file included from /usr/local/include/glib-2.0/gobject/gboxed.h:26, from /usr/local/include/glib-2.0/glib-object.h:25, from pango-ot-private.h:27, from pango-ot-info.c:22: /usr/local/include/glib-2.0/gobject/gtype.h:92: syntax error before `typedef'
@@gtype.h:91:#if GLIB_SIZEOF_LONG == GLIB_SIZEOF_SIZE_T @@gtype.h:92:typedef gulong GType;
looks like glibconfig.h hasn't been generated properly. Are you sure you didn't overlook and errors when configuring glib? Perhaps take a look at /usr/local/lib/glib-2.0/include/glibconfig.h. It should have lines that say something like this:
#define GLIB_SIZEOF_VOID_P 4
#define GLIB_SIZEOF_LONG 4
#define GLIB_SIZEOF_SIZE_T 4
Salut, Sven
new xinput device: no movement when button down
Sven Neumann wrote:
You expect the HEAD branch to compile if you can't get the stable version to build???
I expect nothing. But it was worth a try???
looks like glibconfig.h hasn't been generated properly.
Good one, a 1.2 header was being picked up instead of the 2.0 one. Things are going smoother now.
Thanks, --Adam
new xinput device: no movement when button down
Hi,
"Adam D. Moss" writes:
Sven Neumann wrote:
You expect the HEAD branch to compile if you can't get the stable version to build???
I expect nothing. But it was worth a try???
looks like glibconfig.h hasn't been generated properly.
Good one, a 1.2 header was being picked up instead of the 2.0 one. Things are going smoother now.
your glib-1.2 installation is pretty old then. Glib has been changed to install headers into versioned directories ages ago.
Salut, Sven
dependancies
I just wrote up a page listing the packages I installed to build various versions of the gimp on my Redhat and Debian machines (in addition to whatever I previously had installed). It's mostly a set of notes to myself to make it easier in case I want to build on other machines, but I thought making it public might make life easier for other people who were getting started building the gimp.
http://shallowsky.com/gimpbuild.html
Of course, this doesn't address the issue of where Phil should get these packages for Solaris, but maybe having a list of package names will make it a little easier to do searches for the packages.
The list for the CVS tip is the list of what got me through configure. I'm hitting the same anon cvs problems that others have mentioned, resulting in build errors because I don't have the most current versions of some files (for instance, gimpunits.c seems to be out of date, and gimplist.[ch] are each one rev behind where they should be). Fortunately the 1.3.7 tarball builds fine, so the CVS problem isn't a big problem for me. Phil, have you tried building a tarball rather than CVS? You might have an easier time of it.
...Akkana
dependancies
On Fri, Jun 07, 2002 at 11:02:02PM -0700, Akkana wrote:
I just wrote up a page listing the packages I installed to build various versions of the gimp on my Redhat and Debian machines (in addition to whatever I previously had installed). ...
Fortunately the 1.3.7 tarball builds fine, so the CVS problem isn't a big problem for me. Phil, have you tried building a tarball rather than CVS? You might have an easier time of it.
Thanks for checking and making the list. Actually, I used all tarballs. I did not use CVS for any of it. So now I have an executable built. It just doesnt work properly, and makes my regular mouse unusable :-/
dependancies
Hi,
Philip Brown writes:
On Fri, Jun 07, 2002 at 11:02:02PM -0700, Akkana wrote:
I just wrote up a page listing the packages I installed to build various versions of the gimp on my Redhat and Debian machines (in addition to whatever I previously had installed). ...
Fortunately the 1.3.7 tarball builds fine, so the CVS problem isn't a big problem for me. Phil, have you tried building a tarball rather than CVS? You might have an easier time of it.Thanks for checking and making the list. Actually, I used all tarballs. I did not use CVS for any of it. So now I have an executable built. It just doesnt work properly, and makes my regular mouse unusable :-/
I'm sure you've tried some simpler GTK+-2.0 applications first, like the test applications and demos that come with the GTK+-2.0 source?
Salur, Sven
dependancies
Scripsit Akkana
Cool. You say on that page:
| for some reason, CVS builds have more dependencies than tarball builds.
At least one such reason (I'm not sure whether it's the only one) is that the CVS repository does not include Makefile.in files, the configure script and its various helper files (config.in and friends).
Leaving them out of CVS is Right, because they are automatically generated from the eventual source files by automake and autoconf. If CVS knew about them, spurious "changes" would be recorded each time a developer commits a working directory where he has built something with sligtly different versions of automake or autoconf.
This may also place more complex requirements on the installation of dependencies like pkgconfig where not the tool itself but the file with its associated autoconf macros needs to be located during the build process.
Likewise, the template script for libtool is included in the tarballs, but the CVS source expects to be able to copy it from an installed libtool package (on my machine the cvs tree's autogen.sh had trouble finding libtool, probably because it somehow doesn't like the way I tried to do a nonroot install of gtk+-2.0 on top of a system-supplied libtool).
dependancies
BTW: the 'dependancies' directory in
ftp://ftp.gtk.org/pub/gtk/v2.0/dependencies/
has a version of png that is incompatible with gimp. png1.2.1
At least, that's what the makefile in /home/download/build/gtk+-2.0.3/demos claims.
Just an FYI. I have no idea why it's "incompatible", but i figure folks who actually work with that directory, and any others that are "incompatible" with png1.2, should fix it, seeing as how its the version that gtk recommends these days.
dependancies
Ah, durnit... I forgot which part of things I was building, and just cut-n-pasted. i thought I was building gimp at that point. sorry folks
dependancies
On Sat, Jun 08, 2002 at 05:51:29PM +0200, Sven Neumann wrote:
Hi,
Philip Brown writes:
Thanks for checking and making the list. Actually, I used all tarballs. I did not use CVS for any of it. So now I have an executable built. It just doesnt work properly, and makes my regular mouse unusable :-/
I'm sure you've tried some simpler GTK+-2.0 applications first, like the test applications and demos that come with the GTK+-2.0 source?
Hmm. well, this is interesting...
I nuked everything, and did a complete rebuild today (as you might hve guessed :-)
and... now it seems to work normally.
So you have one confirmed "it works with solaris 8 (x86)" now, with a regular mouse.
however, its a smidge worrying why it went nuts before. My computer blew up, and I reinstalled it. Which means there may be a specific patch level that causes problems.
And related to that... there is a 'bug' with certain versions of Xsun,
which means that gimp wont work correctly with it, yet other programs will.
Just FYI: Xsun with XFree extensions is known to have a problem
with certain video cards, which makes some gtk programs that use pixmaps,
not display properly.
This used to be a problem with mozilla.
Oddly enough, mozilla works fine now on this box. But gimp.1.3.7 exhibits
this problem.
a precompiled binary of gimp1.2.1, linked agaist libgtk-1.2.so.0 => /opt/sfw/lib/libgtk-1.2.so.0 libgdk-1.2.so.0 => /opt/sfw/lib/libgdk-1.2.so.0 libgmodule-1.2.so.0 => /opt/sfw/lib/libgmodule-1.2.so.0 libglib-1.2.so.0 => /opt/sfw/lib/libglib-1.2.so.0 does not have this problem either.
new xinput device: no movement when button down
On Wed, Jun 05, 2002 at 09:19:07PM +0200, Michael Natterer wrote:
...
BTW, would you try gimp 1.3.7 (or CVS) and try if the problem still persists there? If they behave different we'd have a hint how to fix 1.2. If 1.3.7 has the effect too, we have a bug on both branches :(
Okay, now that I've actually gotten 1.3.7 built successfully, I can finally try it out :-)
bad news... same bug.
And yes, "testinput" from /home/download/build/gtk+-2.0.3/tests/testinput
works normally with the pentablet.
As I mentioned previously, I worked around this, by simply putting an '#ifdef' around the pointer grabs in 1.2.3
If you want this 'patch', you're welcome to it, at
http://www.bolthole.com/solaris/drivers/gimp-1.2.3.diffs
Apply in the app directory with **"patch -c"**, since it is a context diff.
However, I dont see it as suitable for integration into the normal code base as-is, for multiple reasons:
1. Its a pure #ifdef. Its not integrated into configure or anything. And it defaults to "dont do the grab at all".
2. What criteria would you USE in configure to enable/disable this? I have no idea why the grab is even done in the first place, so I cant even guess
dependancies
Hi,
Philip Brown writes:
And related to that... there is a 'bug' with certain versions of Xsun, which means that gimp wont work correctly with it, yet other programs will. Just FYI: Xsun with XFree extensions is known to have a problem with certain video cards, which makes some gtk programs that use pixmaps, not display properly.
This used to be a problem with mozilla. Oddly enough, mozilla works fine now on this box. But gimp.1.3.7 exhibitsthis problem.
I think this may be the GDK bug that Federice fixed some days ago:
2002-06-03 Federico Mena Quintero
* gdk/gdkpixbuf-drawable.c (rgb565msb): Fix the MSB -> MSB case. Fixes #79190.
since this is definitely not a GIMP problem, your report is slightly off-topic though. Please test such things with testgtk and if you can reproduce them, report them as GTK+ bug using Bugzilla.
Salut, Sven
dependancies
Hi,
Henning Makholm writes:
Scripsit Akkana
Cool. You say on that page:
| for some reason, CVS builds have more dependencies than tarball builds.
At least one such reason (I'm not sure whether it's the only one) is that the CVS repository does not include Makefile.in files, the configure script and its various helper files (config.in and friends).
these extra dependencies are described in the file HACKING.
I'd like to mention that Carol has made up a pretty complete Compiling-The-GIMP-from-CVS-Howto. Perhaps she wants to post the URL again to avoid more people duplicating her efforts.
Salut, Sven
dependancies
On 2002-06-09 at 1304.03 +0200, Sven Neumann typed this mail:
Hi,
Henning Makholm writes:
Scripsit Akkana
Cool. You say on that page:
| for some reason, CVS builds have more dependencies than tarball builds.
At least one such reason (I'm not sure whether it's the only one) is that the CVS repository does not include Makefile.in files, the configure script and its various helper files (config.in and friends).
these extra dependencies are described in the file HACKING.
I'd like to mention that Carol has made up a pretty complete Compiling-The-GIMP-from-CVS-Howto. Perhaps she wants to post the URL again to avoid more people duplicating her efforts.
bex wrote it ....
url is http://carol.gimp.org/gimp/howtos/cvs/cvs.html
it was written for 1.2 but the cvs info is good for both and the flag setting is proper for both also. Akkanas document seems to be a great snapshot of what is needed to build this gimp right now.
actually, getting HEAD from cvs is less complicated than getting a branch ...
carol
workaround to bad pixmaps on solaris
On Sun, Jun 09, 2002 at 01:00:27PM +0200, Sven Neumann wrote:
Hi,
Philip Brown writes:
Just FYI: Xsun with XFree extensions is known to have a problem with certain video cards, which makes some gtk programs that use pixmaps, not display properly.
...I think this may be the GDK bug that Federice fixed some days ago:
no, I dont think so.
I was re-reminded of it today, so I'll email the workaround:
compile gtk with --disable-shm, if and only if you see the bad pixmaps.
since this is definitely not a GIMP problem, your report is slightly off-topic though. Please test such things with testgtk and if you can reproduce them, report them as GTK+ bug using Bugzilla.
yes, its true it is not a gimp problem. But if people compile gimp and see wierd stuff, they'll wonder whats going on. So I think it is good to have this in the archive, and also to let you guys know in case anyone else bothers you about it :-)
auto-deactivate of (extension) tool : where is it done?
I'm having a little trouble adjusting the part of the code that is responsible for "main cursor is leaving the main window, so deactivate the active tool".
I've found gdisplay_update_cursor() , called by gdisplay_canvas_events(), for case GDK_LEAVE_NOTIFY:
however, I'm having difficulty understanding it. (probably because its so durn late. but anyways...)
my goal is to stop deactivation of active cursor, if there is an xinput device separate from the core pointer.
Any suggestions on which areas I should hit? Or suggestions on which of multiple ways I should tackle it?
([ I'm dealing with the 1.2.3 code, if it makes any difference)
I'm considering that the two ways are,
a) not call gdisplay_update_cursor at all from GDK_LEAVE_NOTIFY, IFF we have a non-core device active
b) making gdisplay_update_cursor() more intelligent.
Not sure at this point which direction is more appropriate.