Inkscape native on OS X... almost

hello all,
Motivated by all the good things I saw about gtk on os x these days and repulsed by all the statistics I should be doing for my real life work, I gave a try at compiling inkscape with GTK native using MacPorts (so not using the all in one build script that Michael cook up a little while ago).
MacPorts is the OS X equivalent of apt-get, portage, yum or whatever. We use it to provide Inkscape dependencies currently and it is very convenient to compile Inkscape that way. It is both easy (all second level dependencies are managed by macports) and economic (the libraries I compile for inkscape can be used in other projects). I wanted to keep this ease of use and to leverage the work of others, so I wanted to keep using MacPorts.
The steps:
1- MacPorts includes native versions of gtk and cairo, which can be installed with: port install cairo +quartz gtk2 +quartz (gentoo and bsd users will recognize the "variants" switches added to both packages). there is a small bug in gtk which is known and solved by the patches in this ticket, at MacPorts: http://trac.macports.org/projects/macports/ticket/12566 hopefully they will commit this soon... but the bug report is quite old already.
2- Other libraries compiled against gtk or cairo need to be recompiled to use these new variants. namely: port -f uninstall cairomm gtkmm pango port install cairomm gtkmm pango this could possibly be solved by a clever use of upgrade when compiling gtk2 and cairo but I did not bother (I should have though...)
3- then compile inkscape from fresh make distsclean cd packaging/macosx/ change the compilation options to remove "--enable-osx-app" for now and then update, configure, build and install: ./osx-build-sh u a c b i compilation goes smoothly for latest svn... great great great!!! Now, on for the hard part:
4- run inkscape cd ../../Build/bin/ ./inkscape and here: (inkscape:20759): Pango-WARNING **: Error loading GDEF table 85
(inkscape:20759): Pango-WARNING **: Error loading GPOS table 85
(inkscape:20759): Pango-WARNING **: Error loading GSUB table 85
(inkscape:20759): Pango-WARNING **: Error loading GDEF table 85
(inkscape:20759): Pango-WARNING **: Error loading GPOS table 85
(inkscape:20759): Pango-WARNING **: Error loading GSUB table 85
(inkscape:20759): Pango-WARNING **: Error loading GDEF table 85
(inkscape:20759): Pango-WARNING **: Error loading GPOS table 85
(inkscape:20759): Pango-WARNING **: Error loading GSUB table 85
(inkscape:20759): Gdk-WARNING **: Unsupported cursor type 14, using default 2007-08-31 16:18:34.382 inkscape[20759] *** _NSAutoreleaseNoPool(): Object 0x14fef7a0 of class GdkQuartzWindow autoreleased with no pool in place - just leaking 2007-08-31 16:18:34.382 inkscape[20759] *** _NSAutoreleaseNoPool(): Object 0x14fee200 of class GdkQuartzWindow autoreleased with no pool in place - just leaking 2007-08-31 16:18:34.386 inkscape[20759] *** _NSAutoreleaseNoPool(): Object 0x14ffa730 of class GdkQuartzWindow autoreleased with no pool in place - just leaking 2007-08-31 16:18:34.390 inkscape[20759] *** _NSAutoreleaseNoPool(): Object 0x14fb9830 of class GdkQuartzWindow autoreleased with no pool in place - just leaking
(inkscape:20759): Gdk-WARNING **: Unsupported cursor type 14, using default CGBitmapContextGetBitsPerPixel: invalid context cairo.c:91: failed assertion `status > CAIRO_STATUS_SUCCESS && status <= CAIRO_STATUS_LAST_STATUS'
Emergency save activated! Emergency save completed. Inkscape will close now. If you can reproduce this crash, please file a bug at www.inkscape.org with a detailed description of the steps leading to the crash, so we can fix it.
(inkscape:20759): GLib-WARNING **: g_main_loop_run(): called recursively from within a source's check() or prepare() member, iteration not possible.
Aaaargh.
Anyway, the good points are that it is now quite easy to get GTK native in our regular building system and that Inkscape builds and links fine against it!
Now, about the crash, it may well be that my system is still kind of dirty (I have some native things but the rest of the libraries are the old ones) but I think it is more likely a bug in cairo +quartz. I'll be happy to try to track it down and see if it is fixable in Inkscape or if this needs to be solved ahead. From the gdb backtrace below it seems to involve pango_cairo_renderer_draw_glyph. If that rings a bell to anyone I'll be glad to know what you think or provide more info where it is needed. I will also probably try to reinstall a separate macports hierarchy this week end and reinstall everything with gtk native there, to be sure the dependencies are clean. We'll see.
Anyway, even if I only saw a blank window instead of Inkscape UI, I was still quite happy to see it without the X11 icon in the dock!!
Cheers,
Backtrace:
#0 0x9003d66c in kill () #1 0x9010e8cf in raise () #2 0x9010d422 in abort () #3 0x02000356 in __eprintf () #4 0x01f9d893 in _cairo_error () #5 0x01f9d8ab in _cairo_set_error () #6 0x01dbe0f6 in pango_cairo_renderer_draw_glyphs () #7 0x01dddd4c in pango_renderer_draw_glyphs () #8 0x01dbe6e4 in _pango_cairo_do_glyph_string () #9 0x01c9bae4 in gdk_pango_renderer_draw_glyphs () #10 0x01dddd4c in pango_renderer_draw_glyphs () #11 0x01ddf09c in pango_renderer_draw_layout_line () #12 0x01ddf2b9 in pango_renderer_draw_layout () #13 0x01c9d99a in gdk_draw_layout_with_colors () #14 0x01c9dca7 in gdk_draw_layout () #15 0x01a17406 in gtk_default_draw_layout () #16 0x01a1a113 in gtk_paint_layout () #17 0x01966e1c in gtk_label_expose () #18 0x0197e1ce in _gtk_marshal_BOOLEAN__BOXED () #19 0x01e0a634 in g_closure_invoke () #20 0x01e1b3e3 in signal_emit_unlocked_R () #21 0x01e1c857 in g_signal_emit_valist () #22 0x01e1d177 in g_signal_emit () #23 0x01ae03c3 in gtk_widget_event_internal () #24 0x01adffdb in gtk_widget_send_expose () #25 0x018ce122 in gtk_container_propagate_expose () #26 0x018cdcaa in gtk_container_expose_child () #27 0x01a1d7fe in gtk_table_forall () #28 0x018cbab6 in gtk_container_forall () #29 0x018cddad in gtk_container_expose () #30 0x0197e1ce in _gtk_marshal_BOOLEAN__BOXED () #31 0x01e0a634 in g_closure_invoke () #32 0x01e1b3e3 in signal_emit_unlocked_R () #33 0x01e1c857 in g_signal_emit_valist () #34 0x01e1d177 in g_signal_emit () #35 0x01ae03c3 in gtk_widget_event_internal () #36 0x01adffdb in gtk_widget_send_expose () #37 0x018ce122 in gtk_container_propagate_expose () #38 0x018cdcaa in gtk_container_expose_child () #39 0x01880aea in gtk_box_forall () #40 0x00c26ebf in Gtk::Container_Class::forall_vfunc_callback () #41 0x018cbab6 in gtk_container_forall () #42 0x018cddad in gtk_container_expose () #43 0x00ca9502 in Gtk::Widget::on_expose_event () #44 0x00ca5e8a in Gtk::Widget_Class::expose_event_callback () #45 0x0197e1ce in _gtk_marshal_BOOLEAN__BOXED () #46 0x01e0a634 in g_closure_invoke () #47 0x01e1b3e3 in signal_emit_unlocked_R () #48 0x01e1c857 in g_signal_emit_valist () #49 0x01e1d177 in g_signal_emit () #50 0x01ae03c3 in gtk_widget_event_internal () #51 0x01adffdb in gtk_widget_send_expose () #52 0x018ce122 in gtk_container_propagate_expose () #53 0x018cdcaa in gtk_container_expose_child () #54 0x01880aea in gtk_box_forall () #55 0x018cbab6 in gtk_container_forall () #56 0x018cddad in gtk_container_expose () #57 0x0197e1ce in _gtk_marshal_BOOLEAN__BOXED () #58 0x01e0a634 in g_closure_invoke () #59 0x01e1b3e3 in signal_emit_unlocked_R () #60 0x01e1c857 in g_signal_emit_valist () #61 0x01e1d177 in g_signal_emit () #62 0x01ae03c3 in gtk_widget_event_internal () #63 0x01adffdb in gtk_widget_send_expose () #64 0x018ce122 in gtk_container_propagate_expose () #65 0x018cdcaa in gtk_container_expose_child () #66 0x01880b35 in gtk_box_forall () #67 0x018cbab6 in gtk_container_forall () #68 0x018cddad in gtk_container_expose () #69 0x0197e1ce in _gtk_marshal_BOOLEAN__BOXED () #70 0x01e0a634 in g_closure_invoke () #71 0x01e1b3e3 in signal_emit_unlocked_R () #72 0x01e1c857 in g_signal_emit_valist () #73 0x01e1d177 in g_signal_emit () #74 0x01ae03c3 in gtk_widget_event_internal () #75 0x01adffdb in gtk_widget_send_expose () #76 0x018ce122 in gtk_container_propagate_expose () #77 0x018cdcaa in gtk_container_expose_child () #78 0x0187c3e3 in gtk_bin_forall () #79 0x018cbab6 in gtk_container_forall () #80 0x018cddad in gtk_container_expose () #81 0x018f3a4c in gtk_event_box_expose () #82 0x0197e1ce in _gtk_marshal_BOOLEAN__BOXED () #83 0x01e0a634 in g_closure_invoke () #84 0x01e1b3e3 in signal_emit_unlocked_R () #85 0x01e1c857 in g_signal_emit_valist () #86 0x01e1d177 in g_signal_emit () #87 0x01ae03c3 in gtk_widget_event_internal () #88 0x01adffdb in gtk_widget_send_expose () #89 0x0197b424 in gtk_main_do_event () #90 0x01cbf535 in -[GdkQuartzView drawRect:] () #91 0x933123b1 in -[NSView _drawRect:clip:] () #92 0x9331140b in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] () #93 0x9332336f in _recursiveDisplayInRect2 () #94 0x9083eb30 in CFArrayApplyFunction () #95 0x93311613 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] () #96 0x93310473 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisible RectForView:topView:] () #97 0x93311041 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisible RectForView:topView:] () #98 0x9330fb78 in -[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisible RectForView:topView:] () #99 0x9330f362 in -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] () #100 0x9330ec8e in -[NSView displayIfNeeded] () #101 0x9330ea32 in -[NSWindow displayIfNeeded] () #102 0x9335ed6c in _handleWindowNeedsDisplay () #103 0x9082dd6e in __CFRunLoopDoObservers () #104 0x9082ce10 in CFRunLoopRunSpecific () #105 0x9082cace in CFRunLoopRunInMode () #106 0x92ded8d8 in RunCurrentEventLoopInMode () #107 0x92decf19 in ReceiveNextEventCommon () #108 0x92dece39 in BlockUntilNextEventMatchingListInMode () #109 0x93293465 in _DPSNextEvent () #110 0x93293056 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #111 0x01cb8a86 in gdk_event_prepare () #112 0x0223faf4 in g_main_context_prepare () #113 0x022401b6 in g_main_context_iterate () #114 0x022408cd in g_main_loop_run () #115 0x0197a9f0 in gtk_main () #116 0x00c48d02 in Gtk::Main::run () #117 0x00004451 in sp_main_gui () #118 0x00158732 in Inkscape::NSApplication::Application::run () #119 0x00003357 in main ()
JiHO --- http://jo.irisson.free.fr/

hello again,
just replying to myself to add some information. The error below does not seem to be related to Inkscape in any way. I've just reinstalled mac ports from scratch, with native gtk, cairo and cairomm, and the gtk demo gives the same error. The backtrace is similar and also points to Pango. This would be logical since Pango does not seem to have a native port currently: it still installs x11 headers and Xft. So I can't expect it to work... Now, on to see why the hell MacPorts would provide gtk and cairo ports without the ability to use them since Pango is not native...
On 2007-August-31 , at 17:10 , jiho wrote:
(inkscape:20759): Pango-WARNING **: Error loading GDEF table 85
(inkscape:20759): Pango-WARNING **: Error loading GPOS table 85
(inkscape:20759): Pango-WARNING **: Error loading GSUB table 85
(inkscape:20759): Pango-WARNING **: Error loading GDEF table 85
(inkscape:20759): Pango-WARNING **: Error loading GPOS table 85
(inkscape:20759): Pango-WARNING **: Error loading GSUB table 85
(inkscape:20759): Pango-WARNING **: Error loading GDEF table 85
(inkscape:20759): Pango-WARNING **: Error loading GPOS table 85
(inkscape:20759): Pango-WARNING **: Error loading GSUB table 85
(inkscape:20759): Gdk-WARNING **: Unsupported cursor type 14, using default 2007-08-31 16:18:34.382 inkscape[20759] *** _NSAutoreleaseNoPool(): Object 0x14fef7a0 of class GdkQuartzWindow autoreleased with no pool in place - just leaking 2007-08-31 16:18:34.382 inkscape[20759] *** _NSAutoreleaseNoPool(): Object 0x14fee200 of class GdkQuartzWindow autoreleased with no pool in place - just leaking 2007-08-31 16:18:34.386 inkscape[20759] *** _NSAutoreleaseNoPool(): Object 0x14ffa730 of class GdkQuartzWindow autoreleased with no pool in place - just leaking 2007-08-31 16:18:34.390 inkscape[20759] *** _NSAutoreleaseNoPool(): Object 0x14fb9830 of class GdkQuartzWindow autoreleased with no pool in place - just leaking
(inkscape:20759): Gdk-WARNING **: Unsupported cursor type 14, using default CGBitmapContextGetBitsPerPixel: invalid context cairo.c:91: failed assertion `status > CAIRO_STATUS_SUCCESS && status <= CAIRO_STATUS_LAST_STATUS'
JiHO --- http://jo.irisson.free.fr/

Hi Jiho,
Could you add this info to the Inkscape OSX wiki page, so if others wish to get involved with making an OSX port they have the latest info? (I've had people contact me offlist about this, and I typically just point them at the wiki.)
Thanks, Bryce
On Fri, Aug 31, 2007 at 06:47:52PM +0200, jiho wrote:
hello again,
just replying to myself to add some information. The error below does not seem to be related to Inkscape in any way. I've just reinstalled mac ports from scratch, with native gtk, cairo and cairomm, and the gtk demo gives the same error. The backtrace is similar and also points to Pango. This would be logical since Pango does not seem to have a native port currently: it still installs x11 headers and Xft. So I can't expect it to work... Now, on to see why the hell MacPorts would provide gtk and cairo ports without the ability to use them since Pango is not native...
On 2007-August-31 , at 17:10 , jiho wrote:
(inkscape:20759): Pango-WARNING **: Error loading GDEF table 85
(inkscape:20759): Pango-WARNING **: Error loading GPOS table 85
(inkscape:20759): Pango-WARNING **: Error loading GSUB table 85
(inkscape:20759): Pango-WARNING **: Error loading GDEF table 85
(inkscape:20759): Pango-WARNING **: Error loading GPOS table 85
(inkscape:20759): Pango-WARNING **: Error loading GSUB table 85
(inkscape:20759): Pango-WARNING **: Error loading GDEF table 85
(inkscape:20759): Pango-WARNING **: Error loading GPOS table 85
(inkscape:20759): Pango-WARNING **: Error loading GSUB table 85
(inkscape:20759): Gdk-WARNING **: Unsupported cursor type 14, using default 2007-08-31 16:18:34.382 inkscape[20759] *** _NSAutoreleaseNoPool(): Object 0x14fef7a0 of class GdkQuartzWindow autoreleased with no pool in place - just leaking 2007-08-31 16:18:34.382 inkscape[20759] *** _NSAutoreleaseNoPool(): Object 0x14fee200 of class GdkQuartzWindow autoreleased with no pool in place - just leaking 2007-08-31 16:18:34.386 inkscape[20759] *** _NSAutoreleaseNoPool(): Object 0x14ffa730 of class GdkQuartzWindow autoreleased with no pool in place - just leaking 2007-08-31 16:18:34.390 inkscape[20759] *** _NSAutoreleaseNoPool(): Object 0x14fb9830 of class GdkQuartzWindow autoreleased with no pool in place - just leaking
(inkscape:20759): Gdk-WARNING **: Unsupported cursor type 14, using default CGBitmapContextGetBitsPerPixel: invalid context cairo.c:91: failed assertion `status > CAIRO_STATUS_SUCCESS && status <= CAIRO_STATUS_LAST_STATUS'
JiHO

On 2007-August-31 , at 19:25 , Bryce Harrington wrote:
Could you add this info to the Inkscape OSX wiki page, so if others wish to get involved with making an OSX port they have the latest info? (I've had people contact me offlist about this, and I typically just point them at the wiki.)
Yes no problem, this is planned. But right now I am all excited since I got the gtk-demo to run after tweaking pango. Woohoo! So now I just need to compile all other inkscape dependencies, recompile inkscape... and we'll see. I'll report my success or failure shortly.
JiHO --- http://jo.irisson.free.fr/

Am Freitag, den 31.08.2007, 19:47 +0200 schrieb jiho:
On 2007-August-31 , at 19:25 , Bryce Harrington wrote:
Could you add this info to the Inkscape OSX wiki page, so if others wish to get involved with making an OSX port they have the latest info? (I've had people contact me offlist about this, and I typically just point them at the wiki.)
Yes no problem, this is planned. But right now I am all excited since I got the gtk-demo to run after tweaking pango. Woohoo! So now I just need to compile all other inkscape dependencies, recompile inkscape... and we'll see. I'll report my success or failure shortly.
I looks like gtk now supports Mac OS X Menubars: http://gimpfoo.de/2007/08/30/using-the-mac-os-x-menubar/
And a bigger screenshot: http://tirania.org/blog/archive/2007/Aug-30-2.html
Regards, Tobias

Hello all
On 2007-August-31 , at 19:47 , jiho wrote:
On 2007-August-31 , at 19:25 , Bryce Harrington wrote:
Could you add this info to the Inkscape OSX wiki page, so if others wish to get involved with making an OSX port they have the latest info? (I've had people contact me offlist about this, and I typically just point them at the wiki.)
Yes no problem, this is planned. But right now I am all excited since I got the gtk-demo to run after tweaking pango. Woohoo! So now I just need to compile all other inkscape dependencies, recompile inkscape... and we'll see. I'll report my success or failure shortly.
It seems that "shortly" took me a little while in fact... So, I got Inkscape to compile and run almost fine using the native GTK version in MacPorts quite easily. I did a screencast (this is what took most of the time ;) ) and you can find it here: http://jo.irisson.free.fr/?p=34 The remaining problems: - a very annoying screen flicker (it is conspicuous in the video) but I think it is fixed in the latest version of GTK (remember this is using MacPorts version so these are already quite "old") - crashes when opening various dialogs (I will not report it for now, since it is with an old version) So I'll try to integrate development versions into MacPorts (MacPorts can fetch svn code easily, and treat this as a regular port) and we'll see. But that won't be before a while.
Cheers,
JiHO --- http://jo.irisson.free.fr/

On Tue, 2007-09-11 at 10:20 +0200, jiho wrote:
It seems that "shortly" took me a little while in fact... So, I got Inkscape to compile and run almost fine using the native GTK version in MacPorts quite easily.
This is very cool. I noticed that the flicker had a bug in bugzilla with some recommendations on what to try. I can't seem to find it now though.
Do you think there's a reasonable chance that we could get a OSX native build for 0.46? Is it possible to get the GTK+ OSX folks aligned with this goal?
--Ted

On 2007-September-12 , at 04:44 , Ted Gould wrote:
On Tue, 2007-09-11 at 10:20 +0200, jiho wrote:
It seems that "shortly" took me a little while in fact... So, I got Inkscape to compile and run almost fine using the native GTK version in MacPorts quite easily.
This is very cool. I noticed that the flicker had a bug in bugzilla with some recommendations on what to try. I can't seem to find it now though.
I think it has been fixed and so probably closed.
Do you think there's a reasonable chance that we could get a OSX native build for 0.46? Is it possible to get the GTK+ OSX folks aligned with this goal?
It would be a very interesting goal and reaching it will probably depend on when 0.46 is cut obviously ;) However, if the native application is to be considered as a stable release, as the rest of 0.46 packages, it must be tested beforehand so there must be some native dev builds happening soon.
Other than the flicker, the menus are not very responsive (but maybe the two are related since when the drawing area flickers, it reduces the interactivity of everything) and there are still a lot of crashes, most of them when opening dialogs. It seems that only dockable dialogs make Inkscape crash (Text and font, XML editor, object properties all open fine and they are not docked while Fill and stroke, Document properties, Align and distribute, all crash Inkscape). However, I would need to try the latest version of GTK before reporting anything and I would really like to do it in the comfort of MacPorts rather than re-building a complete dependency tree for Inkscape by hand (not that it would be that inconvenient for me but rather because it would be the method we'll finally adopt and it would be nice to get it working from the start). Another very nice thing to have would be integration with Mac OS X menu bar. Indeed this single change would make a very large difference in how much "mac-like" Inkscape feels. It seems to be very easy: http://developer.imendio.com/projects/gtk-macosx/menubar But this is in C and would need to be done in C++ to be usable by Inkscape. I have no idea of how complicated it would be to translate this C code in C++ (it is a single, not too long file). Any volunteers? Eventually, the last bit would be to recreate our application bundle (the "package" in which we put all Inkscape stuff) without using X11 but I don't think this would be too difficult and I'll be glad to do it once the rest is done.
Any help would be warmly appreciated for all this of course ;)
Cheers,
JiHO --- http://jo.irisson.free.fr/

On 9/12/07, jiho <jo.irisson@...400...> wrote:
On 2007-September-12 , at 04:44 , Ted Gould wrote:
On Tue, 2007-09-11 at 10:20 +0200, jiho wrote:
It seems that "shortly" took me a little while in fact... So, I got Inkscape to compile and run almost fine using the native GTK version in MacPorts quite easily.
This is very cool. I noticed that the flicker had a bug in bugzilla with some recommendations on what to try. I can't seem to find it now though.
I think it has been fixed and so probably closed.
This bug covers it and is still open: http://bugzilla.gnome.org/show_bug.cgi?id=467269
It is still UNCONFIRMED but the comments are encouraging as it is actively being looked at by several testers and a developer, and comments in the last couple of days suggest a fix has been found and is being tested, that makes Inkscape a lot more usable.
This bug was always one that stopped me (and I'd say many others) from doing any further real testing of Inkscape, and my quick efforts at tracking it down always went nowhere. I think once it is fixed there are likely to be a lot more problems uncovered now that it is actually semi-usable, but it is definitely a big step forwards.
My gut feeling is that the best we could hope for a .46 release is having an 'experimental' quartz release alongside the stable X11 release, mainly to spark people's interest.
Cheers Derek

On 2007-September-12 , at 10:15 , Derek Hinchliffe wrote:
On 9/12/07, jiho <jo.irisson@...400...> wrote:
On 2007-September-12 , at 04:44 , Ted Gould wrote:
On Tue, 2007-09-11 at 10:20 +0200, jiho wrote:
It seems that "shortly" took me a little while in fact... So, I got Inkscape to compile and run almost fine using the native GTK version in MacPorts quite easily.
This is very cool. I noticed that the flicker had a bug in bugzilla with some recommendations on what to try. I can't seem to find it now though.
I think it has been fixed and so probably closed.
This bug covers it and is still open: http://bugzilla.gnome.org/show_bug.cgi?id=467269
It is still UNCONFIRMED but the comments are encouraging as it is actively being looked at by several testers and a developer, and comments in the last couple of days suggest a fix has been found and is being tested, that makes Inkscape a lot more usable.
This bug was always one that stopped me (and I'd say many others) from doing any further real testing of Inkscape, and my quick efforts at tracking it down always went nowhere. I think once it is fixed there are likely to be a lot more problems uncovered now that it is actually semi-usable, but it is definitely a big step forwards.
great!
My gut feeling is that the best we could hope for a .46 release is having an 'experimental' quartz release alongside the stable X11 release, mainly to spark people's interest.
I agree with that, this is probably the most reasonable choice.
On a more personal note: did you have the opportunity to compare the version compiled against MacPorts and your personal tests (I believe you used Michael's build script which pulls more recent versions of GTK and Cairo)? How far behind do you think MacPorts lags?
Cheers,
JiHO --- http://jo.irisson.free.fr/

On Wed, 12 Sep 2007 08:45:32 +0200, jiho <jo.irisson@...400...> wrote:
It seems to be very easy: http://developer.imendio.com/projects/gtk-macosx/menubar But this is in C and would need to be done in C++ to be usable by Inkscape. I have no idea of how complicated it would be to translate this C code in C++ (it is a single, not too long file).
It may not require translation -- most (though not all) valid C programs are trivially valid C++.
-mental
participants (6)
-
Bryce Harrington
-
Derek Hinchliffe
-
jiho
-
MenTaLguY
-
Ted Gould
-
Tobias Jakobs