Migrating X11-based library to Cocoa
Migrating X11-based library to Cocoa
- Subject: Migrating X11-based library to Cocoa
- From: Patrick Hartling <email@hidden>
- Date: Sun, 05 Feb 2006 17:14:51 -0600
I am a developer on an open source C++ library for virtual reality
application development, and I would like to improve the usability of this
software on Mac OS X. Presently, the code base runs on Mac OS X by
leveraging X11 for OS X so that we can use the same code that has run on
Linux, IRIX, FreeBSD, etc. for years. To make the software more approachable
to OS X users, I think it would be very beneficial to drop the X11
requirement. I would also like to have this library delivered as a framework
to VR application developers using OS X.
This weekend, I have finally had the opportunity to start digging into Cocoa
to see just exactly what I can accomplish. I am finding that it is a little
difficult to get started due to the constraints of how this library is
designed and what seem to be the expectations for using Cocoa. I have gone
through a few Cocoa tutorials, and I have the second edition of Aaron
Hillegass' Cocoa programming book. These are great resources, but I *think*
the approach that I need to take is different from the usual Cocoa
application development model. However, I could be wrong about that, and my
hope is to get some guidance here.
The very first hurdle that I have to clear is that the primordial thread is
used differently than in a traditional application. Programmers writing
applications based on this library do write a main() function, but it is not
used for anything except creating an instance of the library's microkernel
and then handing the microkernel an "application object" to execute. (The
application object derives from a base C++ class, the interface methods of
which are invoked by the microkernel in a spawned thread.) After that, the
primordial thread blocks waiting for the microkernel to shut down. All
windowing is managed by the library, and because the primordial thread is
effectively dormant, I think that means that I have to do manual run loop
management in the threads where windows would be handling events.
Moreover, the presence of windows at all when the application is run is
entirely dependent upon the run-time configuration of the library. While the
point, of course, would be to display 3D graphics using OpenGL, the library
is flexible enough to be run without any windows open. The average user
would not do this, and my point is simply to clarify that there is no
concept of a main application window.
What I have tried to do this weekend was experiment with writing some
Objective-C++ code that would create an NSWindow and process keyboard and
mouse events received by that window. Then, I would see what it would take
to get that to work in a spawned NSThread with no event processing happening
in the primordial thread. The basic goal I have is to mimic the window
handling of the C++ virtual reality library with as little code as possible
so that I can learn the ins and outs of Cocoa, Objective-C, and
Objective-C++. Then, I can dive into the really challenging parts of the work.
I have made a little bit of progress on this, but before I go any further,
is what I have described above even feasible? As I said, my plan is to turn
this software library into a framework and to have OS X users of the library
building application bundles. To fit with the overarching goals of this
library, however, I do want to try to keep the main() function as it is on
all other platforms--meaning that there is no need to invoke a function that
runs an event loop in the primordial thread. If it comes right down to it,
though, I can deal with #ifdef's in main() to account for the use of Cocoa.
The really long-term goal of this software library is to eliminate the need
for programmers to write a main() function at all and instead concentrate on
their pluggable application object code. Hence, details such as calling
NSApplicationMain() in main() would still end up being hidden--just not in
the near term.
Thank you in advance for any and all advice.
-Patrick
--
Patrick L. Hartling | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9 | http://www.infiscape.com/
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden