Re: Gtk-OSX Frameworks (was: Why are developers...)



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 src
if /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



i'm EMAILING FOR THE GREATER GOOD
Join me


> From: jralls 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 <dacobi 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]