gtk-osx-users — User discussions and support for GTK+-2 on OSX

[Gtk-osx-users] for noobs

[Lee G <ven...@me...>]

I am wondering is there an application in the works to help us do all of this.I am pretty new to command line, I have successfully hacked my apple tv, via ssh and can do simple things like empty trash, software update and clear my print queue in terminal. But this project seems pretty involved to get, lets say, inkscape to run with quartz rather than x11. I really want to do this but my head starts to spin when I see all the steps I have to go through to do it. I meet the system requirements and have the developer kit. I am hoping any helpful hints or direction to cut out steps in this task.  am hoping for a drag and drop app that allows you to drop inkscape or gimp into it and it magically creates this re-compiled quartz version. I am probably grabbing for straws here :)

[Gtk-osx-users] Compile GTK 2.22

[Gabriele G. <gab...@gm...>]

Just sharing some experiences and problems I got trying to compile GTK 2.22
using the intermediate moduleset.

I've started with the stock files from here:

https://github.com/jralls/gtk-osx-build/tree/master/modulesets

..but the first problem I found is that gtk 2.22 depends from glib 2.25+, so
I downloaded the modulesets locally, modified my .jhbuildrc-custom to point
to them, and changed the glib-2-24 branch tag to glib-2-26.

Once I got this to work I run in another problem, since gtk 2.22 gdk-pixbuf
is a separate package, so I added in gtk-osx.modules the following lines:

  <autotools id="gdk-pixbuf">
    <branch />
      <dependencies>
          <dep package="glib"/>
          <dep package="cairo"/>
      </dependencies>
    <after>
      <dep package="meta-gtk-osx-bootstrap"/>
    </after>
  </autotools>

The strange thing is that the "git" for gdk-pixbuf is of a few hundreds
megabytes and counts half a million of objects, thats really strange since
the tree once extracted contains maybe 100/150 files.

*** Checking out gdk-pixbuf *** [4/10]
git clone git://git.gnome.org/gdk-pixbuf
Initialized empty Git repository in /Users/gabry/gtk/source/gdk-pixbuf/.git/
remote: Counting objects: 229414, done.
remote: Compressing objects: 100% (32677/32677), done.
remote: Total 229414 (delta 197053), reused 228519 (delta 196355)
Receiving objects: 100% (229414/229414), 133.77 MiB | 674 KiB/s, done.
Resolving deltas: 100% (197053/197053), done.
git pull --rebase
Current branch master is up to date.


It seems there is something wrong in that git module :)

Also, apart from it's strange size, gdk-pixbuf does not compile out of the
box, there is a problem with msgmerge and OSX file permission, the fast
workaround as found here:

http://subcommanderblog.wordpress.com/2009/05/16/msgmerge-on-macosx-and-no-such-file-or-directory/

Is to add --backup=off to the msgmerge command line.

To do this I've had to change po/Makefile.in.in, not sure how I can do it
without altering the original GIT tree :(

Anyway *now* the libraries compile, so I hope my problems can be useful to
someone :)

-- 
Bye,
 Gabry

Re: [Gtk-osx-users] Selecting Python installation for PyGtk

[Richard P. <ric...@gm...>]

Hi Ian, 

On 15/11/2010, at 2:43 PM, Ian Bell wrote:

> [snip]
> 
> import pygtk 
> 
> fails.  I can see that the PyGtk is hiding in ~/gtk . How do I get the pygtk files to be found by my Python installation so that I can sucessfully use PyGtk on OSX?

The python sys.path needs to include pygtk, which a 'jhbuild shell' session achieves (amongst other things) by setting the PYTHONPATH environment variable appropriately.

regards, 
Richard. 

For example, on my system I have a small script that lets me work with multiple trees each in their own 'home jail'. 

"buildshell.sh"

#!/bin/bash
ROOT=/Volumes/Vault/unstable

export PATH=${ROOT}/.local/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin  # .*sbin probably unnecessary 
export HOME=${ROOT} 
export IS_BUILDSHELL=1
bash 

-- 
".bashrc" in /Volumes/Vault/unstable to help keep track of what's happening. 

export PS1='\u@\h:\w\n\$ '
if [ -n "$IS_BUILDSHELL" ]; then export PS1="[buildshell - unstable/intel/10.6] $PS1" ; fi
if [ -n "$JHBUILD_PROMPT" ]; then export PS1="$JHBUILD_PROMPT $PS1"; fi

-- 

Having built my gtk/pygtk tree by running under a 'buildshell' and following the gtk-osx wiki instructions I can then 

$ jhbuild shell 
$ python 
>>> import gtk # note: 'import pygtk; pygtk.require('2.0')' is no longer required as far as I know
>>> gtk.Window()
<gtk.Window object at 0x1c13198 (GtkWindow at 0x87d8b8)>

Re: [Gtk-osx-users] Selecting Python installation for PyGtk

[John R. <jr...@ce...>]

On Nov 14, 2010, at 5:43 PM, Ian Bell wrote:

> All,
> 
> Got pygtk to build without problems on 10.6 Snow Leopard by following the instructions from https://sourceforge.net/apps/trac/gtk-osx/wiki/PyGtk
> 
> I ran the terminal commands:
> 
> jhbuild bootstrap --ignore-system
> jhbuild build meta-gtk-osx-bootstrap
> jhbuild build meta-gtk-osx-core
> jhbuild build meta-gtk-osx-python
> 
> 
> 
> and the last few lines of my .jhbuildrc-custom file looks like:
> 
> 
> 
> build_policy = "updated-deps"
> moduleset = "http://github.com/jralls/gtk-osx-build/raw/master/modulesets-stable/gtk-osx.modules"
> setup_sdk("10.6", "10.6", ["i386"])
> _gtk_osx_use_jhbuild_python=True
> append_autogenargs("python", "--with-universal-archs=32-bit --enable-universalsdk=/Developer/SDKs/MacOSX10.5.sdk")
> branches["python"] = "http://www.python.org/ftp/python/2.6.4/Python-2.6.4.tar.bz2"
> 
> 
> 
> and I went through the Python unpacking step and everything seemed to be working.  But when I run python (with all the different versions on my computer) 
> 
> 
> 
> import pygtk 
> 
> 
> 
> fails.  I can see that the PyGtk is hiding in ~/gtk . How do I get the pygtk files to be found by my Python installation so that I can sucessfully use PyGtk on OSX?
> 
> 
> 
> Thanks for any information you can provide.
> 
> 
> 

Just as a guess, you need to start by learning Python. Go read up on $PYTHON_PATH.

Regards,
John Ralls

Re: [Gtk-osx-users] Problems building lablgtk

[John R. <jr...@ce...>]

On Dec 1, 2010, at 3:40 PM, Quentin Pré wrote:

> Hi, 
> I freshly installed gtk-osx on my Snow Leopard, everything worked fine, 
> 
> I'm now trying to build lablgtk2 on my system, but when I'm using "./configure" outside jhbuild shell I get a GTK+ not found (maybe is it normal, but i added my gtk-prefix to my path), 
> when trying in a jhbuild shell, i get no error at configuring but when compiling i get an error with "-lGLU not found", 
> 
> I'm pretty sure it's just a few thing i forgot to do, if anyone as an idea...ty!

Well, as you figured out, you need jhbuild to set up the environment for you before doing anything manually. That's mentioned on the build page, so I guess you forgot to read it carefully.

The other obvious thing you forgot to do is to build libGLU, whatever that is. I guess it's a failure of lablgtk2's configure script that they don't check for it up front.

Oh yeah, one more thing: You forgot to subscribe to the mailing list before trying to post.

Regards,
John Ralls

[Gtk-osx-users] Problems building lablgtk

[Quentin P. <pre...@gm...>]

Hi, 
I freshly installed gtk-osx on my Snow Leopard, everything worked fine, 

I'm now trying to build lablgtk2 on my system, but when I'm using "./configure" outside jhbuild shell I get a GTK+ not found (maybe is it normal, but i added my gtk-prefix to my path), 
when trying in a jhbuild shell, i get no error at configuring but when compiling i get an error with "-lGLU not found", 

I'm pretty sure it's just a few thing i forgot to do, if anyone as an idea...ty!

Re: [Gtk-osx-users] Segmentation fault accessing widget props

[John R. <jr...@ce...>]

On Dec 1, 2010, at 5:01 AM, David Lowe wrote:

> On 1 Dec, 2010, at 1:21 AM, Richard Procter wrote:
> 
>> It's also a bit odd that the idiom is still available if it's effectively useless (i.e. can't read or write via foo.props.bar).
> 
> 	I will try to defend the indefensible by saying that there are a lot of versions of glib/gtk out there, and that method still works on some of them.  However, PyGtk docs really should have a comment that banging the structures directly is deprecated.  It also would have been nice of them to remark which version took away the direct access.
> 

A big part of the problem is undoubtedly that PyGtk development has been pretty desultory the last year or so. That isn't help by introspection, which essentially obsoletes it for Gtk3.

Regards,
John Ralls

Re: [Gtk-osx-users] Segmentation fault accessing widget props

[David L. <doc...@ve...>]

On 1 Dec, 2010, at 1:21 AM, Richard Procter wrote:

> It's also a bit odd that the idiom is still available if it's effectively useless (i.e. can't read or write via foo.props.bar).

	I will try to defend the indefensible by saying that there are a lot of versions of glib/gtk out there, and that method still works on some of them.  However, PyGtk docs really should have a comment that banging the structures directly is deprecated.  It also would have been nice of them to remark which version took away the direct access.

Sent from my MacBookPro

"Dyslexic Christian sells soul to Santa" - News at 11:00

Re: [Gtk-osx-users] Segmentation fault accessing widget props

[Richard P. <ric...@gm...>]

On 1/12/2010, at 5:59 PM, John Ralls wrote:

> 
> On Nov 30, 2010, at 5:14 PM, Richard Procter wrote:
> 
> That's a new "feature" of Gtk and GLib. You aren't allowed to access properties directly any more, you have to use the accessor functions. If you look in the C source code, you'll see GSEAL all over the place. It's the "we can write OO code in C, yes we can!" version of the private variables in real OO languages. (Yes, that's a slam at Python, because van Rossum doesn't believe in data hiding. He's wrong and Stroustroup's right.)

You know, I was thinking on the way home tonight of that saying "if you try to write an OO runtime you'll end up reinventing C++, badly". I'm not certain that it has to be C++ but it does seem to me that writing a custom OO layer is asking for trouble simply because a) it is in itself so difficult to do well and b) really deserves language support and, further, c) it will be written as a means and not as an end in itself and so will be liable to all sorts of 'pragmatic' compromises in the heat of the moment that create nasty unforseen side-effects, path-dependencies, and plain old unnecessary complexity. And few people will want to maintain the resultant hairball. 

I was also thinking that the whole shooting box would have been better off written in objective-C or C++. If I remember right, the compiler support was there back in the day for both languages. And, from my tiny experience of pyobjc, it seems that objective-C has the facilities for good introspective bindings. And NeXTSTEP was extant at the time, and probably GNUstep, too. 

Anyways, it's easy to criticise in hindsight, etc, etc. Show us the code, etc, etc. /End of Rant. 

As for private variables - that's an interesting discussion in itself! I'll have to look up GvR's rationale for that design decision sometime. I agree that the C++ way is invaluable when reworking large projects while wanting some hope of retaining confidence in the result. 

> It is a bit rude of PyGtk to segfault rather than to fail gracefully, but that's not a gtk-osx problem. Go bug them.

Ah - thanks, no that's all I need to know. 

And, yes that's a rather nasty surprise for someone who isn't in the know (where is the best place to pick this sort of thing up - the gtk lists? I must admit I didn't read the release notes). It's also a bit odd that the idiom is still available if it's effectively useless (i.e. can't read or write via foo.props.bar). None of which, of course, is a gtk-osx issue. 


cheers, 
Richard. 

Re: [Gtk-osx-users] Segmentation fault accessing widget props

[John R. <jr...@ce...>]

On Nov 30, 2010, at 5:14 PM, Richard Procter wrote:

> Hi everyone, 
> 
> I've been looking into why my app segfaults with the latest GTK/PyGTK binaries and have whittled it down to this minimal fragment: 
> 
> import gtk
> w = gtk.Window() 
> w.props.visible 
> 
> This isn't limited to the gtk.Window's visible property: accessing the label property of a gtk.MenuItem breaks just as well.
> Replacing the last line with w.get_property('visible') eliminates the fault.
> 
> I've reproduced this over a couple of builds on different machines but it seems so basic that I'd appreciate it if someone could confirm it for me. 
> 
> Details on versions below. 
> 

That's a new "feature" of Gtk and GLib. You aren't allowed to access properties directly any more, you have to use the accessor functions. If you look in the C source code, you'll see GSEAL all over the place. It's the "we can write OO code in C, yes we can!" version of the private variables in real OO languages. (Yes, that's a slam at Python, because van Rossum doesn't believe in data hiding. He's wrong and Stroustroup's right.)

It is a bit rude of PyGtk to segfault rather than to fail gracefully, but that's not a gtk-osx problem. Go bug them.

Regards,
John Ralls

Re: [Gtk-osx-users] Segmentation fault accessing widget props

[Richard P. <ric...@gm...>]

On 1/12/2010, at 2:14 PM, Richard Procter wrote:

> Hi everyone, 
> 
> I've been looking into why my app segfaults with the latest GTK/PyGTK binaries and have whittled it down to this minimal fragment: 
> 
> import gtk
> w = gtk.Window() 
> w.props.visible 
> 
> This isn't limited to the gtk.Window's visible property: accessing the label property of a gtk.MenuItem breaks just as well.
> Replacing the last line with w.get_property('visible') eliminates the fault.
> 
> I've reproduced this over a couple of builds on different machines but it seems so basic that I'd appreciate it if someone could confirm it for me. 

Note that I also observe it with otherwise unchanged libraries under python 2.6.1 10.6/intel. 

regards, 
Richard.

[Gtk-osx-users] Segmentation fault accessing widget props

[Richard P. <ric...@gm...>]

Hi everyone, 

I've been looking into why my app segfaults with the latest GTK/PyGTK binaries and have whittled it down to this minimal fragment: 

import gtk
w = gtk.Window() 
w.props.visible 

This isn't limited to the gtk.Window's visible property: accessing the label property of a gtk.MenuItem breaks just as well.
Replacing the last line with w.get_property('visible') eliminates the fault.

I've reproduced this over a couple of builds on different machines but it seems so basic that I'd appreciate it if someone could confirm it for me. 

Details on versions below. 

best, 
Richard. 

Known good version:
Python is  2.5.2 (r252:60911, Jul 29 2010, 16:21:54) [GCC 4.0.1 (Apple Inc. build 5465)]
GTK  is  (2, 18, 8)
glib is  (2, 24, 1)
PyGTK Version is 	(2, 16, 0)
PyGObject Version is 	(2, 20, 0)

Fault observed under: (occurs under both the home-baked jhbuild python and system python2.5) 
Python is  2.5.2 (r252:60911, Nov 26 2010, 13:41:11) [GCC 4.0.1 (Apple Inc. build 5465)]
GTK  is  (2, 20, 1)
glib is  (2, 24, 1)
PyGTK Version is 	(2, 22, 0)
PyGObject Version is 	(2, 26, 0)

Here's a gdb session run on 10.6/intel of a 10.5 tree built on 10.5:  

>>> import gtk
[...reading symbols...]
>>> w = gtk.Window()
[...reading symbols...] 
>>> w
<gtk.Window object at 0x31e080 (GtkWindow at 0x2016010)>
>>> w.props.visible

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xffffffff
0x00058f0b in PyTuple_Pack ()
(gdb) bt
#0  0x00058f0b in PyTuple_Pack ()
#1  0x0009d5d7 in PyEval_EvalFrameEx ()
#2  0x000a022a in PyEval_EvalCodeEx ()
#3  0x000a0337 in PyEval_EvalCode ()
#4  0x000c3d74 in PyRun_InteractiveOneFlags ()
#5  0x000c3fb3 in PyRun_InteractiveLoopFlags ()
#6  0x000c47b9 in PyRun_AnyFileExFlags ()
#7  0x000d2d68 in Py_Main ()
#8  0x00002b36 in start ()
(gdb) 

 

Re: [Gtk-osx-users] gimp bundle

[John R. <jr...@ce...>]

On Nov 30, 2010, at 4:46 AM, Gim Photo wrote:

> hi,
> thanks for detailed info about creating app bundle.
> 
> i have success creating gimp bundle and it is running oke on my computer,
> but when i testing the bundle using other computer, there is an error message:
> 
> "There was an error parsing the menu definition from image-menu.xml: Failed to open file '/Users/ekk/gtk/inst/share/gimp/2.0/menus/image-menu.xml': No such file or directory"
> 
> when i ran gimp on testing computer, gimp toolbox is appear but none of menu items is showing.
> it's look like gimp is still trying to access my user account at my actual computer that not exist at testing computer.
> how i can fix that error?
> 
> and, is that possible to use 2 different user account to create gtk-osx build system for 32 bit system and for 64 bit system?
> 
> 
> i'm sorry for many questions because i'm new on osx and on gtk-osx.
> thank you very much for your valuable helps and informations.

The first problem is caused by Gimp using a hard-coded path to find their data files. Very sloppy of them. You can either patch Gimp to fix that or you can compile to a neutral prefix (/Library is standard for Macs, but it requires that the user be an admin to install there; /usr/local and /opt are often used in other Unixes, but both require sudo authentication to install in them) and then create a symlink from there to your app bundle in the launcher script.

Sure, it's possible to do it with two different user accounts, but it's easier to use two prefixes and checkoutdirs.

Regards,
John Ralls

[Gtk-osx-users] gimp bundle

[Gim P. <gim...@gm...>]

hi,
thanks for detailed info about creating app bundle.

i have success creating gimp bundle and it is running oke on my computer,
but when i testing the bundle using other computer, there is an error
message:

"There was an error parsing the menu definition from image-menu.xml: Failed
to open file '/Users/ekk/gtk/inst/share/gimp/2.0/menus/image-menu.xml': No
such file or directory"

when i ran gimp on testing computer, gimp toolbox is appear but none of menu
items is showing.
it's look like gimp is still trying to access my user account at my actual
computer that not exist at testing computer.
how i can fix that error?

and, is that possible to use 2 different user account to create gtk-osx
build system for 32 bit system and for 64 bit system?


i'm sorry for many questions because i'm new on osx and on gtk-osx.
thank you very much for your valuable helps and informations.


Regards,
ek kian

Re: [Gtk-osx-users] Build glib

[Gertwin G. <ger...@gm...>]

I deleted everything, now it build like it should.
Problem solved!
Thank you all.

Regards,
Gertwin

2010/11/23 Shawn Bakhtiar <sha...@ho...>:
>
> FYI --
>
> I have done both the 32bit and 64bit builds last week with no issues when I
> moved to my new laptop.
>
> OS X Version 10.6.5 (Xcode 3.2.4)
>
> Make sure to clear out ALL the directories. If you don't you run into all
> kinds of problems. When ever I neglect to delete EVERYTHING something
> inevitably goes wrong. I usually like to start from scratch.
>
> prompt> rm .local Sources tmp-jhbuild-revision .jhbuild* .cache
> prompt> sh ./gtk-osx-build-setup.sh
>
> edit the .jbuild-cusotm file
>
> Than do the three steps from the website to get a complete build.
>
>
>
>
>> From: jr...@ce...
>> Date: Mon, 22 Nov 2010 14:37:12 -0800
>> To: gtk...@li...
>> Subject: Re: [Gtk-osx-users] Build glib
>>
>>
>> On Nov 22, 2010, at 12:39 PM, Gertwin Groen wrote:
>>
>> > I wanted an 64 bit version so I removed the 32 bit version first
>> > before compiling 64 bit.
>> >
>> > I am using the standard compiler.
>> > bash-3.2$ cc -v
>> > Using built-in specs.
>> > Target: i686-apple-darwin10
>> > Configured with: /var/tmp/gcc/gcc-5664~105/src/configure
>> > --disable-checking --enable-werror --prefix=/usr --mandir=/share/man
>> > --enable-languages=c,objc,c++,obj-c++
>> > --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
>> > --with-slibdir=/usr/lib --build=i686-apple-darwin10
>> > --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10
>> > --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1
>> > Thread model: posix
>> > gcc version 4.2.1 (Apple Inc. build 5664)
>> >
>> > Strange is that the jhbuild bootstrap and jhbuild build
>> > meta-gtk-osx-bootstrap wen well.
>> >
>> > Regards,
>> > Gertwin
>> >
>> >
>> >
>> > 2010/11/22 John Ralls <jr...@ce...>:
>> >>
>> >> On Nov 21, 2010, at 2:08 PM, Gertwin Groen wrote:
>> >>
>> >>> Few days ago I build gtk-osx for i386 which went well.
>> >>> Today I want to build it for x64.
>> >>>
>> >>> Everything went well until glib:
>> >>>
>> >>> *** Configuring glib *** [2/11]
>> >>> ...
>> >>>
>> >>> configure: WARNING: No ANSI prototypes found in library. (-std1 didn't
>> >>> work.)
>> >>> ...
>> >>>
>> >>> checking size of char... 0
>> >>> checking size of short... 0
>> >>> checking size of long... 0
>> >>> checking size of int... 0
>> >>> checking size of void *... 0
>> >>> checking size of long long... 0
>> >>> checking size of __int64... 0
>> >>> configure: error:
>> >>> *** GLib requires a 64 bit type. You might want to consider
>> >>> *** using the GNU C compiler.
>> >>>
>> >>> After this error I tried to rebuild my i386 build, which generates the
>> >>> same errors.
>> >>>
>> >>> Yesterday I upgraded to 10.6.5, I doubt this is the cause.
>> >>> Does anyone know what is the cause of this problem and how to solve
>> >>> it?
>> >>>
>> >>
>> >> Not really enough information. Are you building in separate prefixes
>> >> and checkoutroots? (You should be.)
>> >>
>> >> The "consider using the GNU C compiler" message is interesting. You
>> >> didn't set $CC to llvm or clang, did you?
>> >>
>>
>>
>> Like I said, not enough information.
>>
>> I've done 6 builds in the last 3 days with no problems, including a
>> git-master build, so it isn't a gtk-osx change that's messing you up. (The
>> last change to the modulesets was November 5, and it was a trivial change
>> because github only accepts https connections. Nothing at all to do with
>> glib.)
>>
>> My best guess is that you changed something in .jhbuildrc-custom when you
>> switched to x86_64 so that whatever that configure test is fails. You'll
>> have to either look at your changes there or dig into glib's configure and
>> config.log to find exactly what's wrong.
>>
>> Regards,
>> John Ralls
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
>> Tap into the largest installed PC base & get more eyes on your game by
>> optimizing for Intel(R) Graphics Technology. Get started today with the
>> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
>> http://p.sf.net/sfu/intelisp-dev2dev
>> _______________________________________________
>> Gtk-osx-users mailing list
>> Gtk...@li...
>> https://lists.sourceforge.net/lists/listinfo/gtk-osx-users
>
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> Gtk-osx-users mailing list
> Gtk...@li...
> https://lists.sourceforge.net/lists/listinfo/gtk-osx-users
>
>

Re: [Gtk-osx-users] gimp script-fu problems

[John R. <jr...@ce...>]

On Nov 23, 2010, at 12:28 AM, Gim Photo wrote:

> hi,
> after extensively testing GIMP using GTK-OSX, appearently all GIMP script-fu is broken.
> 
> everytime i run command that using script-fu then the script will run, it display UI dialog,
> and after i select the setting and klik OK button then it will run but after the script
> finished processing the image and will back to main GIMP then it crashed GIMP,
> GIMP application will close immediately and at terminal will display error message.
> 
> the error message, usually like this:
> (script-fu:156): LibGimpBase-WARNING **: script-fu: gimp_wire_read(): error Bus error
> or
> (script-fu:134): LibGimpBase-WARNING **: script-fu: gimp_wire_read(): error Segmentation fault
> 
> error only happened to script-fu command, for built-in command and plugins command its run ok.
> 
> steps for produce the error:
> - open image
> - select Menu > Filters > Artistic > Clothify
> or
> - select Menu > Filters > Render > Clouds > Difference Clouds
> 
> (this because not all filters functions using script-fu, some of it using plugins)
> 
> is this normal? or maybe it only happen with my compilation but there is no error in
> compilation process, it status is success. i'm afraid i miss some settings or steps :(
> 
> thanks for any info or help about this matters.

Bus errors and seg faults are almost always caused by trying to dereference a null pointer or uninitialized pointer; that's not a bug that shows up at compile time. Since you mention plugins, it could very well be a plugin that is missing or isn't loading correctly.

This isn't really the right list to help you track down the problem, though. You'll get better help from a Gimp list.

Regards,
John Ralls

Re: [Gtk-osx-users] Build glib

[Shawn B. <sha...@ho...>]

FYI --

I have done both the 32bit and 64bit builds last week with no issues when I moved to my new laptop.

OS X Version 10.6.5 (Xcode 3.2.4)

Make sure to clear out ALL the directories. If you don't you run into all kinds of problems. When ever I neglect to delete EVERYTHING something inevitably goes wrong. I usually like to start from scratch. 

prompt> rm .local Sources tmp-jhbuild-revision .jhbuild* .cache
prompt> sh ./gtk-osx-build-setup.sh

edit the .jbuild-cusotm file

Than do the three steps from the website to get a complete build.




> From: jr...@ce...
> Date: Mon, 22 Nov 2010 14:37:12 -0800
> To: gtk...@li...
> Subject: Re: [Gtk-osx-users] Build glib
> 
> 
> On Nov 22, 2010, at 12:39 PM, Gertwin Groen wrote:
> 
> > I wanted an 64 bit version so I removed the 32 bit version first
> > before compiling 64 bit.
> > 
> > I am using the standard compiler.
> > bash-3.2$ cc -v
> > Using built-in specs.
> > Target: i686-apple-darwin10
> > Configured with: /var/tmp/gcc/gcc-5664~105/src/configure
> > --disable-checking --enable-werror --prefix=/usr --mandir=/share/man
> > --enable-languages=c,objc,c++,obj-c++
> > --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
> > --with-slibdir=/usr/lib --build=i686-apple-darwin10
> > --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10
> > --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1
> > Thread model: posix
> > gcc version 4.2.1 (Apple Inc. build 5664)
> > 
> > Strange is that the jhbuild bootstrap and jhbuild build
> > meta-gtk-osx-bootstrap wen well.
> > 
> > Regards,
> > Gertwin
> > 
> > 
> > 
> > 2010/11/22 John Ralls <jr...@ce...>:
> >> 
> >> On Nov 21, 2010, at 2:08 PM, Gertwin Groen wrote:
> >> 
> >>> Few days ago I build gtk-osx for i386 which went well.
> >>> Today I want to build it for x64.
> >>> 
> >>> Everything went well until glib:
> >>> 
> >>> *** Configuring glib *** [2/11]
> >>> ...
> >>> 
> >>> configure: WARNING: No ANSI prototypes found in library. (-std1 didn't work.)
> >>> ...
> >>> 
> >>> checking size of char... 0
> >>> checking size of short... 0
> >>> checking size of long... 0
> >>> checking size of int... 0
> >>> checking size of void *... 0
> >>> checking size of long long... 0
> >>> checking size of __int64... 0
> >>> configure: error:
> >>> *** GLib requires a 64 bit type. You might want to consider
> >>> *** using the GNU C compiler.
> >>> 
> >>> After this error I tried to rebuild my i386 build, which generates the
> >>> same errors.
> >>> 
> >>> Yesterday I upgraded to 10.6.5, I doubt this is the cause.
> >>> Does anyone know what is the cause of this problem and how to solve it?
> >>> 
> >> 
> >> Not really enough information. Are you building in separate prefixes and checkoutroots? (You should be.)
> >> 
> >> The "consider using the GNU C compiler" message is interesting. You didn't set $CC to llvm or clang, did you?
> >> 
> 
> 
> Like I said, not enough information. 
> 
> I've done 6 builds in the last 3 days with no problems, including a git-master build, so it isn't a gtk-osx change that's messing you up. (The last change to the modulesets was November 5, and it was a trivial change because github only accepts https connections. Nothing at all to do with glib.)
> 
> My best guess is that you changed something in .jhbuildrc-custom when you switched to x86_64 so that whatever that configure test is fails. You'll have to either look at your changes there or dig into glib's configure and config.log to find exactly what's wrong.
> 
> Regards,
> John Ralls
> 
> 
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> Gtk-osx-users mailing list
> Gtk...@li...
> https://lists.sourceforge.net/lists/listinfo/gtk-osx-users
 		 	   		  

[Gtk-osx-users] gimp script-fu problems

[Gim P. <gim...@gm...>]

hi,
after extensively testing GIMP using GTK-OSX, appearently all GIMP script-fu
is broken.

everytime i run command that using script-fu then the script will run, it
display UI dialog,
and after i select the setting and klik OK button then it will run but after
the script
finished processing the image and will back to main GIMP then it crashed
GIMP,
GIMP application will close immediately and at terminal will display error
message.

the error message, usually like this:
(script-fu:156): LibGimpBase-WARNING **: script-fu: gimp_wire_read():
error Bus error
or
(script-fu:134): LibGimpBase-WARNING **: script-fu: gimp_wire_read():
error Segmentation fault

error only happened to script-fu command, for built-in command and plugins
command its run ok.

steps for produce the error:
- open image
- select Menu > Filters > Artistic > Clothify
or
- select Menu > Filters > Render > Clouds > Difference Clouds

(this because not all filters functions using script-fu, some of it using
plugins)

is this normal? or maybe it only happen with my compilation but there is no
error in
compilation process, it status is success. i'm afraid i miss some settings
or steps :(

thanks for any info or help about this matters.


regards,
ek kian

Re: [Gtk-osx-users] Build glib

[John R. <jr...@ce...>]

On Nov 22, 2010, at 12:39 PM, Gertwin Groen wrote:

> I wanted an 64 bit version so I removed the 32 bit version first
> before compiling 64 bit.
> 
> I am using the standard compiler.
> bash-3.2$ cc -v
> Using built-in specs.
> Target: i686-apple-darwin10
> Configured with: /var/tmp/gcc/gcc-5664~105/src/configure
> --disable-checking --enable-werror --prefix=/usr --mandir=/share/man
> --enable-languages=c,objc,c++,obj-c++
> --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
> --with-slibdir=/usr/lib --build=i686-apple-darwin10
> --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10
> --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1
> Thread model: posix
> gcc version 4.2.1 (Apple Inc. build 5664)
> 
> Strange is that the jhbuild bootstrap and jhbuild build
> meta-gtk-osx-bootstrap wen well.
> 
> Regards,
> Gertwin
> 
> 
> 
> 2010/11/22 John Ralls <jr...@ce...>:
>> 
>> On Nov 21, 2010, at 2:08 PM, Gertwin Groen wrote:
>> 
>>> Few days ago I build gtk-osx for i386 which went well.
>>> Today I want to build it for x64.
>>> 
>>> Everything went well until glib:
>>> 
>>> *** Configuring glib *** [2/11]
>>> ...
>>> 
>>> configure: WARNING: No ANSI prototypes found in library. (-std1 didn't work.)
>>> ...
>>> 
>>> checking size of char... 0
>>> checking size of short... 0
>>> checking size of long... 0
>>> checking size of int... 0
>>> checking size of void *... 0
>>> checking size of long long... 0
>>> checking size of __int64... 0
>>> configure: error:
>>> *** GLib requires a 64 bit type. You might want to consider
>>> *** using the GNU C compiler.
>>> 
>>> After this error I tried to rebuild my i386 build, which generates the
>>> same errors.
>>> 
>>> Yesterday I upgraded to 10.6.5, I doubt this is the cause.
>>> Does anyone know what is the cause of this problem and how to solve it?
>>> 
>> 
>> Not really enough information. Are you building in separate prefixes and checkoutroots? (You should be.)
>> 
>> The "consider using the GNU C compiler" message is interesting. You didn't set $CC to llvm or clang, did you?
>> 


Like I said, not enough information. 

I've done 6 builds in the last 3 days with no problems, including a git-master build, so it isn't a gtk-osx change that's messing you up. (The last change to the modulesets was November 5, and it was a trivial change because github only accepts https connections. Nothing at all to do with glib.)

My best guess is that you changed something in .jhbuildrc-custom when you switched to x86_64 so that whatever that configure test is fails. You'll have to either look at your changes there or dig into glib's configure and config.log to find exactly what's wrong.

Regards,
John Ralls

Re: [Gtk-osx-users] Build glib

[Gertwin G. <ger...@gm...>]

I wanted an 64 bit version so I removed the 32 bit version first
before compiling 64 bit.

I am using the standard compiler.
bash-3.2$ cc -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5664~105/src/configure
--disable-checking --enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
--with-slibdir=/usr/lib --build=i686-apple-darwin10
--program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10
--target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5664)

Strange is that the jhbuild bootstrap and jhbuild build
meta-gtk-osx-bootstrap wen well.

Regards,
Gertwin



2010/11/22 John Ralls <jr...@ce...>:
>
> On Nov 21, 2010, at 2:08 PM, Gertwin Groen wrote:
>
>> Few days ago I build gtk-osx for i386 which went well.
>> Today I want to build it for x64.
>>
>> Everything went well until glib:
>>
>> *** Configuring glib *** [2/11]
>> ...
>>
>> configure: WARNING: No ANSI prototypes found in library. (-std1 didn't work.)
>> ...
>>
>> checking size of char... 0
>> checking size of short... 0
>> checking size of long... 0
>> checking size of int... 0
>> checking size of void *... 0
>> checking size of long long... 0
>> checking size of __int64... 0
>> configure: error:
>> *** GLib requires a 64 bit type. You might want to consider
>> *** using the GNU C compiler.
>>
>> After this error I tried to rebuild my i386 build, which generates the
>> same errors.
>>
>> Yesterday I upgraded to 10.6.5, I doubt this is the cause.
>> Does anyone know what is the cause of this problem and how to solve it?
>>
>
> Not really enough information. Are you building in separate prefixes and checkoutroots? (You should be.)
>
> The "consider using the GNU C compiler" message is interesting. You didn't set $CC to llvm or clang, did you?
>
> Regards,
> John Ralls
>
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today
> http://p.sf.net/sfu/msIE9-sfdev2dev
> _______________________________________________
> Gtk-osx-users mailing list
> Gtk...@li...
> https://lists.sourceforge.net/lists/listinfo/gtk-osx-users
>

Re: [Gtk-osx-users] Build glib

[John R. <jr...@ce...>]

On Nov 21, 2010, at 2:08 PM, Gertwin Groen wrote:

> Few days ago I build gtk-osx for i386 which went well.
> Today I want to build it for x64.
> 
> Everything went well until glib:
> 
> *** Configuring glib *** [2/11]
> ...
> 
> configure: WARNING: No ANSI prototypes found in library. (-std1 didn't work.)
> ...
> 
> checking size of char... 0
> checking size of short... 0
> checking size of long... 0
> checking size of int... 0
> checking size of void *... 0
> checking size of long long... 0
> checking size of __int64... 0
> configure: error:
> *** GLib requires a 64 bit type. You might want to consider
> *** using the GNU C compiler.
> 
> After this error I tried to rebuild my i386 build, which generates the
> same errors.
> 
> Yesterday I upgraded to 10.6.5, I doubt this is the cause.
> Does anyone know what is the cause of this problem and how to solve it?
> 

Not really enough information. Are you building in separate prefixes and checkoutroots? (You should be.)

The "consider using the GNU C compiler" message is interesting. You didn't set $CC to llvm or clang, did you?

Regards,
John Ralls

[Gtk-osx-users] Build glib

[Gertwin G. <ger...@gm...>]

Few days ago I build gtk-osx for i386 which went well.
Today I want to build it for x64.

Everything went well until glib:

*** Configuring glib *** [2/11]
...

configure: WARNING: No ANSI prototypes found in library. (-std1 didn't work.)
...

checking size of char... 0
checking size of short... 0
checking size of long... 0
checking size of int... 0
checking size of void *... 0
checking size of long long... 0
checking size of __int64... 0
configure: error:
*** GLib requires a 64 bit type. You might want to consider
*** using the GNU C compiler.

After this error I tried to rebuild my i386 build, which generates the
same errors.

Yesterday I upgraded to 10.6.5, I doubt this is the cause.
Does anyone know what is the cause of this problem and how to solve it?

Regards,
Gertwin

Re: [Gtk-osx-users] Unable to locate theme engine in module_path

[Gertwin G. <ger...@gm...>]

Hi Richard,

Thanks for your hints, it solved my problem.

I listed the environment variables in my profile, after that the theme
engines are found.

However the line
  export DYLD_LIBRARY_PATH="${bundle_resources}/lib"
must be left out the profile, otherwise errors like
  dyld: Symbol not found: __cg_jpeg_resync_to_restart
occur.

Regards,
Gertwin


2010/11/18 Richard Procter <ric...@gm...>:
> Hi Gertwin,
>
> Here is the environment setup for my PyGTK application bundle.
>
> I don't know why the extra GTK environment are necessary but
> I've found GTK_PATH to be insufficient for GTK to reliably find
> itself, at least within a bundle on OS X and possibly elsewhere.
>
> regards,
> Richard.
>
>
> self_path=`dirname $0`
> bundle_base="${self_path}/../.."
> bundle_contents="${bundle_base}/Contents"
> bundle_resources="${bundle_contents}/Resources"
>
> # These really ought not be necessary but GTK_PATH
> # is insufficient to switch our GTK tree. GTK_IM_MODULE_FILE may
> # be redundant. PANGO_RC_FILE is necessary, as GDK_PIXBUF_MODULE_FILE
>
> export GTK2_RC_FILES="$bundle_resources/etc/gtk-2.0/gtkrc"
> export GTK_IM_MODULE_FILE="$bundle_resources/etc/gtk-2.0/gtk.immodules"
> export GDK_PIXBUF_MODULE_FILE="$bundle_resources/etc/gtk-2.0/gdk-pixbuf.loaders"
> export PANGO_RC_FILE="${bundle_resources}/pango/pangorc"
>
> export DYLD_LIBRARY_PATH="${bundle_resources}/lib"
> export GTK_PATH="${bundle_resources}"
> export GTK_DATA_PREFIX="${bundle_resources}"
> export GTK_EXE_PREFIX="${bundle_resources}"
> export PYTHONPATH="${bundle_resources}:${bundle_resources}/lib/python2.5/site-packages:${PYTHONPATH}"
>
>
>
> On 19/11/2010, at 5:05 AM, Gertwin Groen wrote:
>
>> Hi,
>>
>> For some reason gtk is unable to load theme engines:
>> Gtk-WARNING **: Unable to locate theme engine in module_path: "quartz"
>>
>> I build an 64 bits and a 32 version, both version are unable to locate
>> the theme engine's.
>> This warning is printed for all engines that I compiled (64 and 32 bits).
>>
>> I tried to use "export GTK_PATH=/Users/gertwin/gtk/inst/lib/", but
>> this did not help.
>>
>> Does anyone know a solution for this?
>>
>> Thanks,
>> Gertwin
>>
>> ------------------------------------------------------------------------------
>> Beautiful is writing same markup. Internet Explorer 9 supports
>> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
>> Spend less time writing and  rewriting code and more time creating great
>> experiences on the web. Be a part of the beta today
>> http://p.sf.net/sfu/msIE9-sfdev2dev
>> _______________________________________________
>> Gtk-osx-users mailing list
>> Gtk...@li...
>> https://lists.sourceforge.net/lists/listinfo/gtk-osx-users
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today
> http://p.sf.net/sfu/msIE9-sfdev2dev
> _______________________________________________
> Gtk-osx-users mailing list
> Gtk...@li...
> https://lists.sourceforge.net/lists/listinfo/gtk-osx-users
>

Re: [Gtk-osx-users] Unable to locate theme engine in module_path

[Richard P. <ric...@gm...>]

Hi Gertwin, 

Here is the environment setup for my PyGTK application bundle.

I don't know why the extra GTK environment are necessary but 
I've found GTK_PATH to be insufficient for GTK to reliably find 
itself, at least within a bundle on OS X and possibly elsewhere. 

regards, 
Richard. 


self_path=`dirname $0` 
bundle_base="${self_path}/../.." 
bundle_contents="${bundle_base}/Contents"
bundle_resources="${bundle_contents}/Resources"

# These really ought not be necessary but GTK_PATH 
# is insufficient to switch our GTK tree. GTK_IM_MODULE_FILE may  
# be redundant. PANGO_RC_FILE is necessary, as GDK_PIXBUF_MODULE_FILE

export GTK2_RC_FILES="$bundle_resources/etc/gtk-2.0/gtkrc"
export GTK_IM_MODULE_FILE="$bundle_resources/etc/gtk-2.0/gtk.immodules"
export GDK_PIXBUF_MODULE_FILE="$bundle_resources/etc/gtk-2.0/gdk-pixbuf.loaders"
export PANGO_RC_FILE="${bundle_resources}/pango/pangorc"

export DYLD_LIBRARY_PATH="${bundle_resources}/lib"
export GTK_PATH="${bundle_resources}"
export GTK_DATA_PREFIX="${bundle_resources}"
export GTK_EXE_PREFIX="${bundle_resources}"
export PYTHONPATH="${bundle_resources}:${bundle_resources}/lib/python2.5/site-packages:${PYTHONPATH}"



On 19/11/2010, at 5:05 AM, Gertwin Groen wrote:

> Hi,
> 
> For some reason gtk is unable to load theme engines:
> Gtk-WARNING **: Unable to locate theme engine in module_path: "quartz"
> 
> I build an 64 bits and a 32 version, both version are unable to locate
> the theme engine's.
> This warning is printed for all engines that I compiled (64 and 32 bits).
> 
> I tried to use "export GTK_PATH=/Users/gertwin/gtk/inst/lib/", but
> this did not help.
> 
> Does anyone know a solution for this?
> 
> Thanks,
> Gertwin
> 
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today
> http://p.sf.net/sfu/msIE9-sfdev2dev
> _______________________________________________
> Gtk-osx-users mailing list
> Gtk...@li...
> https://lists.sourceforge.net/lists/listinfo/gtk-osx-users

[Gtk-osx-users] Unable to locate theme engine in module_path

[Gertwin G. <ger...@gm...>]

Hi,

For some reason gtk is unable to load theme engines:
Gtk-WARNING **: Unable to locate theme engine in module_path: "quartz"

I build an 64 bits and a 32 version, both version are unable to locate
the theme engine's.
This warning is printed for all engines that I compiled (64 and 32 bits).

I tried to use "export GTK_PATH=/Users/gertwin/gtk/inst/lib/", but
this did not help.

Does anyone know a solution for this?

Thanks,
Gertwin