Cocoa fundamentals - the message loop in a dylib

Nibbie
Posts: 3
Joined: 2009.11
Post: #1
Hi,

I have a set of libraries (written in C++) I've developed for Windows, Linux and FreeBSD. I used to use SDL to handle these things but I realized I don't need SDL anything other than creating the window and handling input events so I took over that responsibility as well and created windows, OpenGL context and so on.

On Mac OS X, however, I am kind of baffled. It appears like my libraries/application can work with Carbon, because it exposes its message loop (as far as I can see). However, Cocoa doesn't expose this and I couldn't find where is it exactly.

I have read about NSRunLoop but couldn't give a meaning.

Please note that I do not want timers or things like that. I would like to do something similar to that of SDL:

while (true)
{
if (PollEvents())
{
switch (GetEvent())
{
case MouseEvent: HandleMouseEvent(); break;
case WindowResizeEvent: HandleWindowResize(); break;
default: break;
}
}
else
HandleFrameEvent();
}

Frame event should always be posted (not based on some funky timer) and I should be able to handle other events within the loop.

How can I do this under Cocoa? I fetched SDL code but I couldn't do the exact same thing for some peculiar reason. It may be due to the fact that the way SDL loads NIB is relatively different than my "hack". I have almost no idea about neither Cocoa nor Objective-C. I am trying to minimize language shift but I guess it is inevitable.

That aside, is it possible to implement actual windowing framework within a shared object/dylib? My original design is very simple. It has an entry point (main or WinMain) then it loads, what I call, the platform run-time library, then creates platform window and handles all platform specific things in there (including resource loading, localization, etc). Rest of the stuff (e.g. scene graph, engine, etc. - the actual implementation itself) is in another set of shared libraries. I want to implement this windowing within "platform run-time library for Mac OS X".

Regards,
Jason
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
Well, the dylib is just pointless, but yes, Mac OS X doesn't impose any particular restriction on what you can do in a dylib as opposed to your application.

This: http://www.omnigroup.com/ftp/pub/softwar...gToOSX.pdf is ancient and some of its advice is out of date, but it shows how to create an "inside out" event loop in Cocoa.

I don't really recommend it though. Write your platform abstraction to have event handling the right way out instead.
Quote this message in a reply
Nibbie
Posts: 3
Joined: 2009.11
Post: #3
Thank you for your reply.

My intent is, as I mentioned, quite similar to SDL's one. The architecture of application is also quite trivial. I wanted per-platform executables to just implement the entry point and create windowing environment then push events.

It may look pointless at first, but more than one application will use that UI library. Instead of duplicating code, I thought reusing binary form within a shared objects would be better.

I think I have tried that window creation before. I am having trouble with loading NIB, I guess. But I didn't know how I could handle events, and article appears to give a good example.

Thanks
Jason
Quote this message in a reply
Moderator
Posts: 373
Joined: 2006.08
Post: #4
You can just use .a files instead, then Wink

I agree very, very much with OSC's advice about dylibs....I ignored his advice on this same subject a couple of years ago and suffered lots of pain because of it XD

Man, that brings back memories.... Smile

Worlds at War (Current Project) - http://www.awkward-games.com/forum/
Quote this message in a reply
Nibbie
Posts: 3
Joined: 2009.11
Post: #5
I thought about static linking as well. I don't think it'd cause any burden, but still does not give the right answer (or the answer I expect...).

We (I am, in particular) are used to the message loop concept; there is a UI app, it keeps receiving events as messages or in another form (e.g. SDL_PollEvent). This part is missing in Cocoa, as far as I can see - or it's not documented well/clear enough.

May be I am totally dumb or taken over by Microsoft... but I think Apple documentation is horrible; it really is, for most purposes, underqualified. It's very similar to open source documentation which ends up with loads of text and but says nothing; no real examples.

People don't like MSDN, but it usually gives you, not just one but multiple "language" examples. I agree most of the COM related stuff is not clearly documented but there are some examples on the web or you could ask this in newsgroup.

We did ask this in Apple newsgroups and got no reply (as of right now).

I guess what we want is easy; SDL did it. But SDL can't run on 64-bit on Leopard:
Quote:file /Library/Frameworks/SDL.framework/Versions/Current/SDL
/Library/Frameworks/SDL.framework/Versions/Current/SDL: Mach-O universal binary with 2 architectures
/Library/Frameworks/SDL.framework/Versions/Current/SDL (for architecture i386): Mach-O dynamically linked shared library i386
/Library/Frameworks/SDL.framework/Versions/Current/SDL (for architecture ppc): Mach-O dynamically linked shared library ppc
That aside, compiling SDL was kind of painful as well; it requires some deprecated API.

Again; may be I am stupid or didn't see the article yet, but... is there one single article talking about "the message loop" or its equivalent on Cocoa on Apple developer web site?

If somebody has seen this, I'd be very grateful if you share it.

OneSadCookie, I saw the article, but implementing bits and pieces of it caused trouble. As I mentioned, there is no clear documentation. I tried:
NSDictionary *infoDictionary = [[NSBundle mainBundle] infoDictionary];
Class principalClass =
NSClassFromString([infoDictionary objectForKey:@"NSPrincipalClass"]);
/*NSAssert([principalClass respondsToSelector:@selector(sharedApplication)],
@"Principal class must implement sharedApplication.");*/
NSApplication *applicationObject = [principalClass sharedApplication];

(NSassert didn't compile for some reason, that's why it's commented)
and I end up with a NULL pointer after principalClass. There is nothing on stderr (and I expected as a Unix programmer); may be I should try strace... to see which file is it looking for? I already have main.xib (and it may look for MainMenu.nib).
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #6
A .xib needs to be compiled to something that can be loaded, but that's not what's going on here. Perhaps you have no NSPrincipalClass key in your info.plist.

"The Apple documentation is useless" is a common complaint but I've always found the opposite. You do need a little ground knowledge in Cocoa to find your way around it though. The sample code is uniformly awful. Thankfully it's not often linked from the documentation Wink
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Dylib problem ugriffin 2 4,211 Apr 20, 2011 05:28 PM
Last Post: ugriffin
  how to debug a dylib? sakiel 1 4,125 Aug 16, 2007 07:26 PM
Last Post: OneSadCookie
  How to force the use of static libs when the dylib is present? Malarkey 4 5,787 Oct 12, 2006 04:33 PM
Last Post: Malarkey
  Linking to dylib in xCode Jones 6 5,726 Jun 26, 2006 02:08 PM
Last Post: OneSadCookie
  /sw/lib/libcurl.2.dylib to /usr/lib/??? (terminal...???) BinarySpike 10 6,782 May 2, 2005 10:05 AM
Last Post: BinarySpike