Cocoa mail archive
Re: Writing application without Interface Builder
FROM : Bill Bumgarner
DATE : Sat Jul 22 19:43:03 2006
On Jul 22, 2006, at 6:21 AM, Patrick Hartling wrote:
> Bill Bumgarner wrote:
>> ... lots of conjecture about threading, appkit, & the main menu
>> deleted ...
>
> I apologize for being vague about the threading and all of that. I
> will post
> some code this time, though I hope not to make this message overly
> long as a
> result.
No need to apologize -- It wasn't meant as an accusation or insult,
just that I thought the thread would benefit from starting over with
a problem framed in slightly new terms.
>
>> OK -- it is pretty clear from your post that you don't have an full
>> understanding of the interaction between the AppKit, Threads, and the
>> Main Menu.
>
> I'm sure that you are right. I am new to Cocoa programming, and it
> seems
> like what I want to do is not what people normally try to do with
> Cocoa--and
> not just because I started out by trying to write a lot of the code
> by hand.
> I have since used Interface Builder to set up the main menu, and it
> generally works much better than what I was doing by hand.
To be fair -- it is a remarkably subtle aspect of Cocoa programming.
The docs do provide enough information, but it is
.... deleted a bunch of stuff because it looked correct ....
> When the NSWindow instance is created, I set its content view and
> first
> responder to a subclass of NSView that calls NSLog() for keyboard
> and mouse
> events. All of this is in my helper function openWindow() so that I
> can call
> it from the primordial thread or from one of my spawned threads.
This implies that openWindow() sets up a view hierarchy and brings
the window on screen? ... potentially from a thread?
This could be problematic -- I haven't reviewed the documentation
closely enough to know exactly where the "thread safe" line cuts
through the AppKit.
> Anyway, the main() from above works fine. The window that it opens
> receives
> events correctly, and the main menu behaves. If I change it so that
> the call
> to NSApplicationLoad() is uncommented, the creation of the
> ThreadedWindow is
> uncommented, and the call to openWindow() is commented out, I get
> the window
> processing events correctly in a thread, but there are basically
> two main
> menus. If I change it again so that the call to NSApplicationLoad()
> is after
> the call to [NSApplication sharedApplication], then the main menu
> behaves
> again, but my window spawned from the thread stops receiving events.
NSEvent processing must happen in the main event loop -- in the main
thread.
A thread's runloop can have "events" of its own, but not NSEvents.
>> It isn't clear why you are mixing Carbon and Cocoa. Is your C++
>> framework a Carbon framework? In any case, you can mix Carbon and
>> Cocoa, but it is tricky. There is documentation on the
>> http://developer.apple.com/ site.
>
> I didn't intend to mix Carbon and Cocoa. As I said in my previous
> post, I
> read that NSApplicationLoad() is needed in order to allow Carbon
> code to
> utilize Cocoa. My goal here is not to use Carbon at all.
Ahh.. OK -- yes. NSApplicationLoad() is intended to initialize the
Cocoa stack to implement a Cocoa window within a Carbon App.
>
> Ultimately, this is all an experiment because I want to learn more
> about
> Objective-C, Objective-C+=, and Cocoa and because I want to improve
> the use
> of the C++ software to which I have referred on Mac OS X. I'm quite
> thankful
> to Apple for the availability of X11 for OS X because this particular
> software would not work without it, but I'd like not to be
> dependent on X11
> for OS X usage. If Cocoa doesn't end up working out, I'll most
> likely have
> to go the Carbon route. Cocoa just seems like more fun. :)
Heh -- yeah -- Cocoa is definitely the way to go to minimize the
amount of code required to implement any given UI while also
maximizing the feature set.
b.bum
DATE : Sat Jul 22 19:43:03 2006
On Jul 22, 2006, at 6:21 AM, Patrick Hartling wrote:
> Bill Bumgarner wrote:
>> ... lots of conjecture about threading, appkit, & the main menu
>> deleted ...
>
> I apologize for being vague about the threading and all of that. I
> will post
> some code this time, though I hope not to make this message overly
> long as a
> result.
No need to apologize -- It wasn't meant as an accusation or insult,
just that I thought the thread would benefit from starting over with
a problem framed in slightly new terms.
>
>> OK -- it is pretty clear from your post that you don't have an full
>> understanding of the interaction between the AppKit, Threads, and the
>> Main Menu.
>
> I'm sure that you are right. I am new to Cocoa programming, and it
> seems
> like what I want to do is not what people normally try to do with
> Cocoa--and
> not just because I started out by trying to write a lot of the code
> by hand.
> I have since used Interface Builder to set up the main menu, and it
> generally works much better than what I was doing by hand.
To be fair -- it is a remarkably subtle aspect of Cocoa programming.
The docs do provide enough information, but it is
.... deleted a bunch of stuff because it looked correct ....
> When the NSWindow instance is created, I set its content view and
> first
> responder to a subclass of NSView that calls NSLog() for keyboard
> and mouse
> events. All of this is in my helper function openWindow() so that I
> can call
> it from the primordial thread or from one of my spawned threads.
This implies that openWindow() sets up a view hierarchy and brings
the window on screen? ... potentially from a thread?
This could be problematic -- I haven't reviewed the documentation
closely enough to know exactly where the "thread safe" line cuts
through the AppKit.
> Anyway, the main() from above works fine. The window that it opens
> receives
> events correctly, and the main menu behaves. If I change it so that
> the call
> to NSApplicationLoad() is uncommented, the creation of the
> ThreadedWindow is
> uncommented, and the call to openWindow() is commented out, I get
> the window
> processing events correctly in a thread, but there are basically
> two main
> menus. If I change it again so that the call to NSApplicationLoad()
> is after
> the call to [NSApplication sharedApplication], then the main menu
> behaves
> again, but my window spawned from the thread stops receiving events.
NSEvent processing must happen in the main event loop -- in the main
thread.
A thread's runloop can have "events" of its own, but not NSEvents.
>> It isn't clear why you are mixing Carbon and Cocoa. Is your C++
>> framework a Carbon framework? In any case, you can mix Carbon and
>> Cocoa, but it is tricky. There is documentation on the
>> http://developer.apple.com/ site.
>
> I didn't intend to mix Carbon and Cocoa. As I said in my previous
> post, I
> read that NSApplicationLoad() is needed in order to allow Carbon
> code to
> utilize Cocoa. My goal here is not to use Carbon at all.
Ahh.. OK -- yes. NSApplicationLoad() is intended to initialize the
Cocoa stack to implement a Cocoa window within a Carbon App.
>
> Ultimately, this is all an experiment because I want to learn more
> about
> Objective-C, Objective-C+=, and Cocoa and because I want to improve
> the use
> of the C++ software to which I have referred on Mac OS X. I'm quite
> thankful
> to Apple for the availability of X11 for OS X because this particular
> software would not work without it, but I'd like not to be
> dependent on X11
> for OS X usage. If Cocoa doesn't end up working out, I'll most
> likely have
> to go the Carbon route. Cocoa just seems like more fun. :)
Heh -- yeah -- Cocoa is definitely the way to go to minimize the
amount of code required to implement any given UI while also
maximizing the feature set.
b.bum
