On Nov 10, 2009, at 4:46 PM, Shawn Bakhtiar wrote:
For building an application... I couldn't agree more, about the framework vs. jhbuild and autotools. You definitely want the latter. I like XCode's editor. when looking at source code (the colors man the colors). It also has a lot of nice features such as collapsible sections, an intuitive way of knowing if you {} are correct, as well as a jump to function feature that list all functions in the current file in a drop down menu. However, you can use the editor, and build in shell (jhbuild shell). In any case, gdb is a much better debugger to boot.But yeah.. just try to build mysql with it, or even use it in a build. Good luck!!Also using the ige-mac-bundler, users now simple drag and drop the latest package (application) to their application folder, and they are done, especially if you adhere to the XDG file system.I don't know what all the complaint is about... I have been using the jhbuild scripts with little to no problems. I have had a few dependency issues but nothing that can not be figured out with a little reading of the script itself and attention to what I am doing. In any case, anything that is missing, simple download to source directory, and build inside the jhbuild shell, your done!Like I said, I'm not too good with the back-end stuff, but it looks like I will be getting my own Snow Leopard today, I can re-run the jhbuild stuff from scratch, and see if I can't get a framework out. Would this help?
That would be great! I've been trying to build it on Snow Leopard, butI i'm stuck now with jhbuild meta-gtk-osx-core failing to build ige-mac-integration: *** Building ige-mac-integration *** [10/11] make make all-recursive Making all in srcif /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. - I. -I.. -I.. -Wall -Wunused -Wchar-subscripts -Wmissing-declarations - Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wcast-align - std=c99 -Wno-sign-compare -Wno-pointer-sign -Werror -I/Users/dacobi/ gtk/inst/include -I/Users/dacobi/gtk/inst/include/gtk-2.0 -I/Users/ dacobi/gtk/inst/lib/gtk-2.0/include -I/Users/dacobi/gtk/inst/include/ atk-1.0 -I/Users/dacobi/gtk/inst/include/cairo -I/Users/dacobi/gtk/ inst/include/pango-1.0 -I/Users/dacobi/gtk/inst/include/glib-2.0 -I/ Users/dacobi/gtk/inst/lib/glib-2.0/include -I/Users/dacobi/gtk/inst/ include/pixman-1 -I/Users/dacobi/gtk/inst/include/freetype2 -I/Users/ dacobi/gtk/inst/include/libpng12 -xobjective-c -g -O2 -MT libigemacintegration_la-ige-mac-menu.lo -MD -MP -MF ".deps/ libigemacintegration_la-ige-mac-menu.Tpo" -c -o libigemacintegration_la-ige-mac-menu.lo `test -f 'ige-mac-menu.c' || echo './'`ige-mac-menu.c; \ then mv -f ".deps/libigemacintegration_la-ige-mac-menu.Tpo" ".deps/ libigemacintegration_la-ige-mac-menu.Plo"; else rm -f ".deps/ libigemacintegration_la-ige-mac-menu.Tpo"; exit 1; fi libtool: compile: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -Wall - Wunused -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes - Wnested-externs -Wpointer-arith -Wcast-align -std=c99 -Wno-sign- compare -Wno-pointer-sign -Werror -I/Users/dacobi/gtk/inst/include -I/ Users/dacobi/gtk/inst/include/gtk-2.0 -I/Users/dacobi/gtk/inst/lib/ gtk-2.0/include -I/Users/dacobi/gtk/inst/include/atk-1.0 -I/Users/ dacobi/gtk/inst/include/cairo -I/Users/dacobi/gtk/inst/include/ pango-1.0 -I/Users/dacobi/gtk/inst/include/glib-2.0 -I/Users/dacobi/ gtk/inst/lib/glib-2.0/include -I/Users/dacobi/gtk/inst/include/ pixman-1 -I/Users/dacobi/gtk/inst/include/freetype2 -I/Users/dacobi/ gtk/inst/include/libpng12 -xobjective-c -g -O2 -MT libigemacintegration_la-ige-mac-menu.lo -MD -MP -MF .deps/ libigemacintegration_la-ige-mac-menu.Tpo -c ige-mac-menu.c -fno- common -DPIC -o .libs/libigemacintegration_la-ige-mac-menu.o
cc1obj: warnings being treated as errors ige-mac-menu.c: In function ‘menu_flash_off_cb’:ige-mac-menu.c:77: warning: implicit declaration of function ‘FlashMenuBar’
ige-mac-menu.c:77: warning: nested extern declaration of ‘FlashMenuBar’ ige-mac-menu.c: In function ‘carbon_menu_free’:ige-mac-menu.c:139: warning: implicit declaration of function ‘DisposeMenu’
ige-mac-menu.c:139: warning: nested extern declaration of ‘DisposeMenu’ ige-mac-menu.c: In function ‘carbon_menu_item_free’:ige-mac-menu.c:182: warning: implicit declaration of function ‘DeleteMenuItem’ ige-mac-menu.c:182: warning: nested extern declaration of ‘DeleteMenuItem’
ige-mac-menu.c: In function ‘carbon_menu_item_get_checked’:ige-mac-menu.c:294: warning: implicit declaration of function ‘GetMenuItemProperty’ ige-mac-menu.c:294: warning: nested extern declaration of ‘GetMenuItemProperty’
ige-mac-menu.c: In function ‘carbon_menu_item_update_state’:ige-mac-menu.c:337: warning: implicit declaration of function ‘ChangeMenuItemAttributes’ ige-mac-menu.c:337: warning: nested extern declaration of ‘ChangeMenuItemAttributes’
ige-mac-menu.c: In function ‘carbon_menu_item_update_active’:ige-mac-menu.c:347: warning: implicit declaration of function ‘CheckMenuItem’ ige-mac-menu.c:347: warning: nested extern declaration of ‘CheckMenuItem’
ige-mac-menu.c: In function ‘carbon_menu_item_update_submenu’:ige-mac-menu.c:361: warning: implicit declaration of function ‘SetMenuItemHierarchicalMenu’ ige-mac-menu.c:361: warning: nested extern declaration of ‘SetMenuItemHierarchicalMenu’ ige-mac-menu.c:367: warning: implicit declaration of function ‘CreateNewMenu’ ige-mac-menu.c:367: warning: nested extern declaration of ‘CreateNewMenu’ ige-mac-menu.c:373: warning: implicit declaration of function ‘SetMenuTitleWithCFString’ ige-mac-menu.c:373: warning: nested extern declaration of ‘SetMenuTitleWithCFString’
ige-mac-menu.c: In function ‘carbon_menu_item_update_label’:ige-mac-menu.c:394: warning: implicit declaration of function ‘SetMenuItemTextWithCFString’ ige-mac-menu.c:394: warning: nested extern declaration of ‘SetMenuItemTextWithCFString’
ige-mac-menu.c: In function ‘carbon_menu_item_update_accelerator’:ige-mac-menu.c:417: warning: implicit declaration of function ‘SetMenuItemModifiers’ ige-mac-menu.c:417: warning: nested extern declaration of ‘SetMenuItemModifiers’ ige-mac-menu.c:423: warning: implicit declaration of function ‘SetMenuItemCommandKey’ ige-mac-menu.c:423: warning: nested extern declaration of ‘SetMenuItemCommandKey’
ige-mac-menu.c: In function ‘carbon_menu_item_create’:ige-mac-menu.c:588: warning: implicit declaration of function ‘InsertMenuItemTextWithCFString’ ige-mac-menu.c:588: warning: nested extern declaration of ‘InsertMenuItemTextWithCFString’ ige-mac-menu.c:592: warning: implicit declaration of function ‘SetMenuItemProperty’ ige-mac-menu.c:592: warning: nested extern declaration of ‘SetMenuItemProperty’
ige-mac-menu.c: In function ‘nsevent_handle_menu_key’:ige-mac-menu.c:724: warning: implicit declaration of function ‘IsMenuKeyEvent’ ige-mac-menu.c:724: warning: nested extern declaration of ‘IsMenuKeyEvent’ ige-mac-menu.c:727: warning: implicit declaration of function ‘GetMenuItemCommandID’ ige-mac-menu.c:727: warning: nested extern declaration of ‘GetMenuItemCommandID’ ige-mac-menu.c:740: warning: implicit declaration of function ‘GetMenuID’
ige-mac-menu.c:740: warning: nested extern declaration of ‘GetMenuID’ige-mac-menu.c:742: warning: implicit declaration of function ‘GetMenuEventTarget’ ige-mac-menu.c:742: warning: nested extern declaration of ‘GetMenuEventTarget’ ige-mac-menu.c:742: warning: passing argument 2 of ‘SendEventToEventTarget’ makes pointer from integer without a cast
ige-mac-menu.c: In function ‘sync_menu_shell’:ige-mac-menu.c:921: warning: implicit declaration of function ‘GetMenuAttributes’ ige-mac-menu.c:921: warning: nested extern declaration of ‘GetMenuAttributes’ ige-mac-menu.c:927: warning: implicit declaration of function ‘ChangeMenuAttributes’ ige-mac-menu.c:927: warning: nested extern declaration of ‘ChangeMenuAttributes’
ige-mac-menu.c: In function ‘parent_set_emission_hook_remove’:ige-mac-menu.c:988: warning: implicit declaration of function ‘ClearMenuBar’
ige-mac-menu.c:988: warning: nested extern declaration of ‘ClearMenuBar’ige-mac-menu.c:989: warning: implicit declaration of function ‘DeleteMenu’
ige-mac-menu.c:989: warning: nested extern declaration of ‘DeleteMenu’ ige-mac-menu.c: In function ‘window_focus’:ige-mac-menu.c:1001: warning: implicit declaration of function ‘SetRootMenu’
ige-mac-menu.c:1001: warning: nested extern declaration of ‘SetRootMenu’ ige-mac-menu.c: In function ‘ige_mac_menu_set_quit_menu_item’:ige-mac-menu.c:1068: warning: implicit declaration of function ‘GetIndMenuItemWithCommandID’ ige-mac-menu.c:1068: warning: nested extern declaration of ‘GetIndMenuItemWithCommandID’ ige-mac-menu.c:1071: warning: implicit declaration of function ‘SetMenuItemCommandID’ ige-mac-menu.c:1071: warning: nested extern declaration of ‘SetMenuItemCommandID’
make[2]: *** [libigemacintegration_la-ige-mac-menu.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2*** Error during phase build of ige-mac-integration: ########## Error running make *** [10/11]
Anyone? /Jacob
EMAILING FOR THE GREATER GOOD Join me > From: jra...@ceridwen.us > Subject: Re: Gtk-OSX Frameworks (was: Why are developers...) > Date: Tue, 10 Nov 2009 07:10:09 -0800 > To: gtk-devel-list@gnome.org > > > On Nov 10, 2009, at 4:16 AM, Paul Davis wrote: >> > On Mon, Nov 9, 2009 at 1:10 PM, Jack Skellington <dac...@gmail.com>> > wrote: > >> >> Also if a native Gtk+ OS X framework were available people who are > >> maintaining Gtk+ apps would have the option to extend their user base> >> to OS X quite quickly. > >> > All it requires to use it is to build the GTK stack yourself using the > > instructions provided (i wish the instructions had not been moved away > > from gnome.org, but they are still easy to find). I should put "all" > > in quotes because if you choose to follow bleeding edge GTK then you > > will find that maintaining your built version can be quite a lot of > > work in the face of breakages and changes in many different parts of > > the stack. This is not true (or at least, it is MUCH less true) if you > > use a recent release version (there are instructions on how to do that> > included in the gtk osx build info). > > > > I do not believe that using a pre-built GTK OS X framework is > > desirable for users or developers. Include GTK as part of your app> > bundle. Its not hard to do and gives you complete control over which> > version of GTK is used by your app. We do this for Ardour (and now > > Mixbus) (screenshots at http://ardour.org/ and> > http://mixbus.harrisonconsoles.com/). Users download a single app, and> > run it. No framework installation or maintainance. > > I haven't built and made available updated frameworks because the> approach Richard used to create the first one (still hanging around on gtk-osx.org > , as previously noted elsewhere) didn't produce a result that I think > I can support. I have in mind a modification of ige-mac-bundler which> I think will provide better results, but other tasks have higher > priority at the moment. > > Some others, including me, have done some work on the gtk-osx- > frameworks, and the network graph at github shows that my tree (http://github.com/jralls/gtk-osx-framework> ) is current with all of them . Do be aware that there are 3 branches,> of which master is probably the only one which will get you close > enough to use. > > I also agree with Paul here: The Apple Framework idiom doesn't make> sense for cross-platform development. It uses special #include syntax > and special linking. It doesn't play well with pkg-config. Yes, those> are solvable problems, but why? The regular gnu autotools work very > well indeed on OSX, and one needs to use it anyway for building on> Linux. Why deal with another build chain just for the dubious benefit> of using XCode instead of emacs or vim? > > Add to that that it's hard to build a non-trivial application using > only gtk+. You're going to need a bunch of other libraries, either > from gnome, gnu, or freedesktop. They're not going to be in > Frameworks, so you're going to have to integrate them the autotools > way, so what do you gain from having gtk+ in a set of frameworks? > > There is one exception to which I'm quite sympathetic: PyGtk. At> present building a downloadable PyGtk app bundle is a royal pain, and> a PyGtk framework *might* be part of the solution. > > Regards, > John Ralls > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list