On Tuesday 14 June 2005 12:59, John R. Culleton wrote:

Am running 2.3.0 without incident. I downloaded 2.3.1 and attempted to configure. I got a message about pygtk-2.0 missing.

What is this, is it essential and where can I find it?

Not a huge deal. 2.3.0 is OK.

From gimp 2.3.1 and ahead, teh gimp python extension is enabled by default.

With it in, you get some new plug-ins, but above everythiong else, a powrfull high level language to script up the GIMP in better and easy ways.

Search google to find the best way to install pygtk on your system (if you have to build it, it is buitl easily and without mess ) These are the bindings of the python language to GTK .

If you are in ahurry, however, you cvan just pass --disable-python to the ./configure script, and live a little more withou the python plug-ins.

JS
->

On Tue, Jun 14, 2005 at 03:59:24PM +0000, John R. Culleton wrote:

Am running 2.3.0 without incident. I downloaded 2.3.1 and attempted to configure. I got a message about pygtk-2.0 missing.

What is this, is it essential and where can I find it?

i am not certain where to find this, however ./configure --help will tell you how to configure it without python.

2.3.1 has a problem with maintaining transparent layers, so you might stick with 2.2 for that reason.

mr. culleton, i am going to respectfully ask the reason that after all of this time you are not running a cvs version of gimp? you seem overdue for this.

if you find pygtk and get python running on gimp, i would like to have your feedback about my silly little script writing attempts.

carol

Joao S. O. Bueno Calligaris wrote:

On Tuesday 14 June 2005 12:59, John R. Culleton wrote:

Am running 2.3.0 without incident. I downloaded 2.3.1 and attempted to configure. I got a message about pygtk-2.0 missing.

What is this, is it essential and where can I find it?

Not a huge deal. 2.3.0 is OK.

From gimp 2.3.1 and ahead, teh gimp python extension is enabled by default.

With it in, you get some new plug-ins, but above everythiong else, a powrfull high level language to script up the GIMP in better and easy ways.

How will this affect Windows' builds for the eventual 2.4 release? I wonder if it will have to be disabled... I hope the Windows compiler crew can figure out a way to accommodate this (i.e., compiling with Python support)

EP

Von: Eric P

How will this affect Windows' builds for the eventual 2.4 release?

Not at all.

I wonder if it will have to be disabled...

No.

I hope the Windows compiler crew can figure out a way to accommodate this (i.e., compiling with Python support)

The configure check and compiling isn't the problem (you just have to add -lpython2x to your LDFLAGS). If anyone can tell why the autotools based pygimp module isn't recognized, please tell me. The distutils build also uses gcc and ld, but different compiler and linker flags - knowing which of them cause this problem might help to adapt the pygimp build.

Michael

On Tue, Jun 28, 2005 at 10:46:12AM +0000, John R. Culleton wrote:

On Tuesday 28 June 2005 10:13 am, John R. Culleton wrote:

On Tuesday 14 June 2005 08:42 pm, Carol Spears wrote:

mr. culleton, i am going to respectfully ask the reason that after all of this time you are not running a cvs version of gimp? you seem overdue for this.

With other packages there is an overnight snapshot of the CVS, bundled as tarball. Does such a facility exist for Gimp? Where?

if you find pygtk and get python running on gimp, i would like to have your feedback about my silly little script writing attempts.

Still struggling with pygtk. More later.

Happy to report that they pygtk problem has bee ameliorated. I found pygtk-2.0 and installed it. Then after a little cut-and try I copied pygtk-2.0.pc to /usr/lib/pkgconfig. That bypassed the error messages.

Why the pygtk make install didn't do this automatically I don't know.

Because you're supposed to set PKG_CONFIG_PATH in the environment to point to where the .pc file lives, instead of copying it.

This is mentioned in INSTALL, although the context is regarding gtk+ itself, not pygtk.

-Yosh

On 6/28/05, Manish Singh wrote:

Because you're supposed to set PKG_CONFIG_PATH in the environment to point to where the .pc file lives, instead of copying it. -Yosh
_______________________________________________ Gimp-user mailing list
Gimp-user@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user

I don't suppose you're going to tell us that the pkgconfig setup is supposed to do this for us?

John R. Culleton wrote:

Sorry folks, I am an old line pragmatist. The quickest and surest way to make something work is the one I will choose. Instead of expanding the list of locations searched just for a single package used by a single application, moving the required file to a place where the system will find it makes more sense to me. It is simple, it is sensible and it is robust.

... until you install a new version, have forgotten about the copying, the old version is picked up, you wonder why it doesn't work, you steal valuable time from the developers when asking why it doesn't work, and so on... :)

SCNR,
Michael

On Tue, Jun 28, 2005 at 01:59:04PM +0000, John R. Culleton wrote:

On Tuesday 28 June 2005 04:01 pm, Manish Singh wrote:

On Tue, Jun 28, 2005 at 10:46:12AM +0000, John R. Culleton wrote:

On Tuesday 28 June 2005 10:13 am, John R. Culleton wrote:

On Tuesday 14 June 2005 08:42 pm, Carol Spears wrote:

mr. culleton, i am going to respectfully ask the reason that after all of this time you are not running a cvs version of gimp? you seem overdue for this.

With other packages there is an overnight snapshot of the CVS, bundled as tarball. Does such a facility exist for Gimp? Where?

if you find pygtk and get python running on gimp, i would like to have your feedback about my silly little script writing attempts.

Still struggling with pygtk. More later.

Happy to report that they pygtk problem has bee ameliorated. I found pygtk-2.0 and installed it. Then after a little cut-and try I copied pygtk-2.0.pc to /usr/lib/pkgconfig. That bypassed the error messages.

Why the pygtk make install didn't do this automatically I don't know.

Because you're supposed to set PKG_CONFIG_PATH in the environment to point to where the .pc file lives, instead of copying it.

Fine. so if I have 148 packages, then this environment variable is set to all 148 locations? Two facts intrude:

Well, if you configure all 148 packages into separate prefixes, then yeah. But that would be silly.

On one of my development machines, I build HEAD versions of gimp, pygtk, gtk+ and it's dependents. They go in *one* prefix, and PKG_CONFIG_PATH contains *one* path to find them. They don't belong in /usr/lib since I don't really want to use unstable libraries for the entire system.

1. 148 other files with the suffix .pc reside in the directory previously mentioned.

Which are installed by the system package manager.

2. The environmental variable you mention doesn't appear to exist on my machine currently. I used the "set" command with no parameters and it did not show up on the list.

LD_LIBRARY_PATH doesn't exist on a system by default either, but that's how you configure the runtime linker to look in non-default locations. PKG_CONFIG_PATH is similar in concept, but for compile time stuff.

Sorry folks, I am an old line pragmatist. The quickest and surest way to make something work is the one I will choose. Instead of expanding the list of locations searched just for a single package used by a single application, moving the required file to a place where the system will find it makes more sense to me. It is simple, it is sensible and it is robust.

It violates the principle that stuff in /usr should only be controlled by the package manager.

If you'd used a pygtk package for your system instead of building your own (assuming one exists), the .pc file would indeed be in /usr.

If you're building stuff by hand, add the appropriate stuff to your environment based on what --prefix you choose. It's not really complex.

-Yosh

Hi,

"John R. Culleton" writes:

With other packages there is an overnight snapshot of the CVS, bundled as tarball. Does such a facility exist for Gimp? Where?

That doesn't exist and it would be a terrible waste of bandwidth since you are likely going to download that tarball frequently whereas a simple CVS update would just pull in the changes from CVS.

Sven

Hi,

"John R. Culleton" writes:

I am not expert in CVS (translation, I just printed out the manual this morning) but it seems that it is command line driven. Do I sign on to a Gimp CVS server somewhere using telnet? If so what is the address etc.?

This might be a good start: http://gimp.org/source/#gimp_from_cvs

Hmm, is that really the best documentation on CVS that we currently offer? Perhaps the classic version (classic and outdated, adjust version numbers!) can help: http://classic.gimp.org/devel_cvs.html

Sven

PS: We could really use some help with the gimp website.

On Tue, Jun 28, 2005 at 10:13:28AM +0000, John R. Culleton wrote:

On Tuesday 14 June 2005 08:42 pm, Carol Spears wrote:

mr. culleton, i am going to respectfully ask the reason that after all of this time you are not running a cvs version of gimp? you seem overdue for this.

With other packages there is an overnight snapshot of the CVS, bundled as tarball. Does such a facility exist for Gimp? Where?

let me use an example from my government to demonstrate how cvs gimp works better than this "overnight" model -- the mozilla nightlies is the one example i have seen of this.

my government funded the SETI program. when funding was removed so many interested people used the SETI at home software to contribute. from what i heard of the success of this conversion, to free themselves from the limitations of the old mainframes and use all of those home computers to do the work, the amount of actual work they accomplished with the new set up is best measured exponentially.

i have watched this build process as it has progressed on windows. there was a time where Tor was building all of the gimps that were used on windows. since that time, (pardon misspellings) jernj and michael schumaml have been building gimp from cvs on windows and a few others as well. these poor souls are building gimp with a sane build system on an operating system that is not friendly to development like this. their efforts go far into making that build system better and better.

it would be nice to see some mac users with the same unafraid spirit to attempt to build gimp for their operating system as well. that might be an environment that is designed for critics and not for builders and makers though -- i dunno for sure.

i am not so certain that providing those snapshots did very much to actually make good software. the definition of what makes good software is greatly under debate -- i would still like to see a browser, from the free world, that is capable of displaying mng. my mozilla will gladly and easily display flash, which unfortunately includes the advertisements. and it downloads the files even though i do not have the plug-in installed. this is what the build-farm has rendered.

if you find pygtk and get python running on gimp, i would like to have your feedback about my silly little script writing attempts.

Still struggling with pygtk. More later.

yes, i admit i read that before i wrote this.

sorry for the delay, i was at a different place in my inbox than here while all of the fun was going on.

carol

On Tue, Jun 28, 2005 at 10:46:12AM +0000, John R. Culleton wrote:

On Tuesday 28 June 2005 10:13 am, John R. Culleton wrote:

On Tuesday 14 June 2005 08:42 pm, Carol Spears wrote:

mr. culleton, i am going to respectfully ask the reason that after all of this time you are not running a cvs version of gimp? you seem overdue for this.

With other packages there is an overnight snapshot of the CVS, bundled as tarball. Does such a facility exist for Gimp? Where?

if you find pygtk and get python running on gimp, i would like to have your feedback about my silly little script writing attempts.

Still struggling with pygtk. More later.

Happy to report that they pygtk problem has bee ameliorated. I found pygtk-2.0 and installed it. Then after a little cut-and try I copied pygtk-2.0.pc to /usr/lib/pkgconfig. That bypassed the error messages.

Why the pygtk make install didn't do this automatically I don't know.

if you installed the pygtk-dev package from your distribution, it would have installed the .h files and also the .pc files into /usr/

it was explained to me to let the distribution handle the /usr/ directory and to use /usr/local/ for the software that you are building for yourself. this way of building software can become confused and broken when you need the development parts of other software that you installed yourself in /usr/local/ and make finds the distributions files in /usr/

make will look there first.

your problems with make were different however. there is a little script available from the newer gimp web site that could have handled this for you:
http://www.gimp.org/source/howtos/gimpenv my personal copy of this sets the cvsroot for getting gimp from cvs as well. put the file anywhere and with the terminal you use to build gimp with type "source gimpenv". it creates a little build environment in which all of the PATHS are set to look for software gimp might need that can be found in /usr/local. the build environment remains this way for the whole instance of this terminal/console. i typically use it on an xterm.

it can be easily modified if you start to want to build other software and have it install in other directories on your computer system such as /opt or even ~/
i suggest that you stay with the traditional /usr/local until all this new stuff makes sense to you.

after some experience with building software and seeing others try to build it on different operating systems, this method will start to make sense to you. at least it did for me.

if you would like my personal version of gimpenv, i can fix it to work with the annon server and send it to you.

i highly recommend using the cvsrc that was provided on the new gimp web site as well:
http://www.gimp.org/source/howtos/cvsrc it sets your cvs up fairly logically and also keeps away some weird sync issues that the annonymous server can have.

carol

John R. Culleton (john@wexfordpress.com) wrote:

Earlier in my journey autogen.sh had complained about an obsolete intltool so I installed version 32 of that package.

Did you rerun autogen.sh after updating intltool?

BTW I switched from stable cvs to unstable by deleting the entire ~/cvs/gimp subdirectory and using the command cvs checkout -r HEAD gimp

I used this technique to avoid conflicts between versions.
The initial splash screen for the resulting Gimp says: Pixeldumper Developers Release 2.3

but the window displayed when I click help>about still says version 2.2.9

It seems you installed the old and the new gimp in the same prefix. The about dialog should say 2.3.1.

Make sure that you read the file HACKING and INSTALL in CVS.

Bye, Simon

On Wednesday 29 June 2005 12:40, John R. Culleton wrote:

Back to the drawing board. :

poor you :(. i am reading this thread with interest and am thinking of having a go myself but i am reluctant to do this incase it overwrites my current installation. can i install, or try to install the gimp 2.2.7 in a seperate folder/dir which will not interfere or overwrite the current working version of gimp i have ?

sammi

On Wednesday 29 June 2005 08:40, John R. Culleton wrote:

On Wednesday 29 June 2005 08:52 am, John R. Culleton wrote:

thought it was time to rename the thread since I have gone past the problems with pygtk.

If anything else comes up of interest I will report back.

It seems that the error reported earlier prevented final compilation so I had unstable splash screens but still the same old 2.2 Gimp in actuality.

Back to the drawing board. :

Are you running the program as "gimp-2.3" ?

"gimp" is just a symbolic link to the actual binary, and the unstable versions to not replace this link to themselves.

On Wed, Jun 29, 2005 at 04:55:16PM +0100, sam ende wrote:

On Wednesday 29 June 2005 12:40, John R. Culleton wrote:

Back to the drawing board. :

poor you :(. i am reading this thread with interest and am thinking of having a go myself but i am reluctant to do this incase it overwrites my current installation. can i install, or try to install the gimp 2.2.7 in a seperate folder/dir which will not interfere or overwrite the current working version of gimp i have ?

that jumps into advanced building skills.

did you get your current installed gimp from a distribution? it should be easy to remove and reinstall such a gimp.

carol

On Wed, Jun 29, 2005 at 12:59:31PM -0300, Joao S. O. Bueno Calligaris wrote:

On Wednesday 29 June 2005 08:40, John R. Culleton wrote:

On Wednesday 29 June 2005 08:52 am, John R. Culleton wrote:

thought it was time to rename the thread since I have gone past the problems with pygtk.

If anything else comes up of interest I will report back.

It seems that the error reported earlier prevented final compilation so I had unstable splash screens but still the same old 2.2 Gimp in actuality.

Back to the drawing board. :

Are you running the program as "gimp-2.3" ?

"gimp" is just a symbolic link to the actual binary, and the unstable versions to not replace this link to themselves.

this is a good point.

there is a configure option to make it the default gimp.

carol

On 6/28/05, Manish Singh wrote:

It violates the principle that stuff in /usr should only be controlled by the package manager.

Explain to me how this makes sense if by default, my builds go to /usr/local/... ? That *IS* in /usr, last I checked, and this is the default build prefix for 99% of applications AFAIK. Unless /usr/local isn't in /usr.

If you'd used a pygtk package for your system instead of building your own (assuming one exists), the .pc file would indeed be in /usr.

If not, shouldn't it be in /usr/local?

My apologies, I didn't read the last post before sending this. Next time I'll read all the posts before saying anything.

On 6/30/05, michael chang wrote:

On 6/28/05, Manish Singh wrote:

It violates the principle that stuff in /usr should only be controlled by the package manager.

Explain to me how this makes sense if by default, my builds go to /usr/local/... ? That *IS* in /usr, last I checked, and this is the default build prefix for 99% of applications AFAIK. Unless /usr/local isn't in /usr.

If you'd used a pygtk package for your system instead of building your own (assuming one exists), the .pc file would indeed be in /usr.

If not, shouldn't it be in /usr/local?

-- ~Mike