• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Call for help: GTK+ for OS X
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Call for help: GTK+ for OS X


  • Subject: Re: Call for help: GTK+ for OS X
  • From: Finlay Dobbie <email@hidden>
  • Date: Sun, 9 Sep 2001 21:49:56 +0100

On Sunday, September 9, 2001, at 09:32 pm, Matthew Cox wrote:

Yeah, count me in. My question. I'm assuming that GTK+ uses a pixel based drawing system. Quartz uses a vector based system. This could get hairy.

I don't really see how. It works fine under XFree86 rootless, which uses quartz :-)
If it works under XF86 then why bother, you might ask. Well, MUCH less overhead (no XF86 needed), less fuss (no faffing around compiling/installing binaries of XF86), tighter integration with OS X (proper windows with Aqua titlebars, probably the ability to launch them as .apps, their own icons in the dock, a window list, etc).

There are just some basic gdk drawing functions, i.e. for drawing lines and rects etc, which need to be implemented for GdkWindows (which would be wrapped to NSWindows) and GdkPixmaps (which would be either wrapped to NSImage or NSView, I guess).

My advice would be to wrap the GTK+ environment to the Cocoa one. That way, creating a GTK+ button would create an NSButton, etc.

No, _THAT_ would get hairy! :-)
I am planning on just using the standard GTK/GDK drawing code to draw into the window's contentView. Using Cocoa widgets would be completely insane from my point of view: you'd need to intertwine the two event models throughout the API. Yuck.
Apparently you can create themes in C, instead of by bitmaps, but I think that this would be a project FAAR into the future.

Are you talking about creating a window by window system, or a complete user environment. IE: When I create a GTK+ window, will I be creating an NSWindow, or will I be creating another type of window in a different environment. A better way of saying this is: When I launch cocoa Gimp, will I be able to see it's windows and Mail's? Or will I have to click on the gimp dock icon to hide everything, then go to a new enviroment?

A GTK+ window will be an NSWindow, yes. There is no other way of creating windows in OS X AFAICT, unless you either use Carbon (which I don't want to, it's too disgusting) or CGS*, which I can't because I don't have the headers (and if I did then I would probably be under NDA and therefore unable to use them in an LGPL project). This will mean that GTK+ windows will be standard OS X windows.

Otherwise there would be little point in a reworking in Cocoa, you'd want to port over the linux-fb (framebuffer) implementation, I think :-)

-- Finlay


  • Prev by Date: Re: Mac OS X 10.1 File Name Extension Guidelines
  • Next by Date: Re: Would Any Developers Use This?
  • Previous by thread: Re: Call for help: GTK+ for OS X
  • Next by thread: Re: IRC-like NSTextView
  • Index(es):
    • Date
    • Thread