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

___

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

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.

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

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

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

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:

http://keithp.com/fonts/

* 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

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

"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

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

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

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

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

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' 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.

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

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

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

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

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

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.

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

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]

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

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

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

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

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

Scripsit Akkana

http://shallowsky.com/gimpbuild.html

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).

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 exhibits

this 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

Hi,

Henning Makholm writes:

Scripsit Akkana

http://shallowsky.com/gimpbuild.html

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

On 2002-06-09 at 1304.03 +0200, Sven Neumann typed this mail:

Hi,

Henning Makholm writes:

Scripsit Akkana

http://shallowsky.com/gimpbuild.html

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