Re: [Gtk2hs-users] Gtk2hs and Mac OS X integration

[Ross M. <rmm-haskell@z.odi.ac>]

Responses inline ->

Axel Simon wrote:
> 
> On Nov 16, 2008, at 22:15, Ross Mellgren wrote:
> 
>> I do have it all set up and wouldn't mind doing this, though I have a 
>> few architecture-ish questions:
>>
>> 1) What's the best way to put it in the build so it doesn't break 
>> non-mac versions (especially important, I think, because I don't have 
>> any non-macs to use this on right now)
> 
> Hm, I would suggest to create functions that are defined as no-ops for 
> non-mac builds. I don't quite know how to compile Gtk2Hs against the mac 
> os port of Gtk+. I guess we need to add a test in configure to find out 
> if we build against this special version of Gtk+, then define the 
> appropriate flag in the config-gtk2hs.h header file.

Compiling against the GTK+ Mac build the first time was confusing and 
exciting. I ended up having to manually build and install pkgconfig (I 
am allergic to fink / macports), then setting PKGCONFIG_PATH to this 
inside my .bash_profile:

export PKG_CONFIG_PATH=\
/usr/local/lib/pkgconfig:\
/Library/Frameworks/Cairo.framework/Resources/dev/lib/pkgconfig:\
/Library/Frameworks/GLib.framework/Resources/dev/lib/pkgconfig:\
/Library/Frameworks/Gtk.framework/Resources/dev/lib/pkgconfig

So usual-ish autoconf has-function-in-header test, then #if 
defined/#else/#endif to build real definitions if it exists, or nops 
otherwise?

>> 2) Where in the module hierarchy should it go? Graphics.UI.Gtk.Mac
> 
> Are these functions all related to the menu bar? If so, they could go 
> directly in the Menu modules. If not, they might find a place in 
> Graphics.UI.Gtk.General because there are only very few functions IIRC 
> which I think doesn't justify a new directory.

It looks like there's more than menu stuff there and I think it be worth 
it's own module. Here's the 2-minute summary of what is part of that, so 
you can decide:

There are four headers included with the ige-mac segment:

ige-mac-bundle.h)
    Looks like a gobject for using the NSBundle-style APIs (in case you 
don't know mac too well: bundles = directories that operate as a single 
file and have special treatment, e.g. .app bundles for apps, etc)

ige-mac-dock.h)
    gobject to manage the dock icon

ige-mac-menu.h)
    functions to manage synchronization of the mac menu bar to the GTK 
ones, and some event handling stuff I can presume is related to the menu 
but I'm not sure

> 
>> and finally are there any special caveats I should know about? You've 
>> seen the depth that I've gone in gtk2hs, that is to say just tweaking 
>> existing signatures and export lists.
> 
> I don't think so. Tweaking the configure script is probably the 
> trickiest part. If you're unfamiliar with autoconf, then note that the 
> config-gtk2hs.h file is generated automatically. You need to define a 
> flag using some sort of macro.

I've written autoconf before but it's been a while, so I'll have to 
de-rust it.

>> Also, the mac port of gtk2hs, or of GTK+?
> 
> I don't understand this question. There's no Mac port of Gtk2Hs...

Yeah, that's what I thought which is why I asked ;-)

Thanks for the advice,

-Ross

> Cheers,
> Axel.
> 
>> Thanks,
>>
>> -Ross
>>
>> Axel Simon wrote:
>>> On Nov 16, 2008, at 20:45, Ross Mellgren wrote:
>>>> Hi all,
>>>>
>>>> Reading up on the GTK+ Quartz port, it seems there are special
>>>> additional functions for making the integration to the mac tighter (in
>>>> particular making the menu bar be the one at the top of the screen,
>>>> instead of per-window).
>>>>
>>>> On the page
>>>> http://developer.imendio.com/projects/gtk-macosx/integration, it
>>>> mentions using functions like ige_mac_menu_set_menu_bar(...). I did a
>>>> quick find/grep on gtk2hs and couldn't find this referred to.
>>>>
>>>> Is there currently any binding for making the mac integration tighter
>>>> like this, or would I have to wire in some new bindings?
>>>>
>>> No, unfortunately not. The mac os port has also been idle for over a 
>>> year now after the guy finished his Master thesis. In principle there 
>>> would be no problem to bind these few functions that set the menu bar 
>>> on OS X, albeit I haven't gone through the trouble of trying the 
>>> Gtk-Mac OS port at all yet. If you've set it all up, I think adding 
>>> the few extra functions would be trivial, and I'd be happy to help 
>>> you writing those.
>>> Cheers,
>>> Axel.
>