Discussion:
NSAlert::runModal doesn't work on 10.6
(too old to reply)
Andreas Falkenhahn
2016-08-22 13:26:56 UTC
Permalink
I've created an NSAlert dialog as described here:
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Dialog/Tasks/UsingAlerts.html#//apple_ref/doc/uid/20000871-129009-BCIFAAEJ

When I run it using

[alert runModal];

it shows up correctly but pressing a button doesn't do anything on 10.6. The
dialog isn't closed and just stays there. On 10.11, however, everything is
working correctly. Pressing a button closes the dialog and returns the id
of the button that has been pressed.

Since NSAlert is quite an essential class, I don't think that this is a bug
in 10.6 so I'm probably doing something wrong. Does anybody have an idea
what could cause this behaviour on 10.6 and how I can fix this?
--
Best regards,
Andreas Falkenhahn mailto:***@falkenhahn.com

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.na
d***@gmail.com
2016-08-22 13:49:26 UTC
Permalink
Post by Andreas Falkenhahn
Does anybody have an idea
what could cause this behaviour on 10.6 and how I can fix this?
http://bfy.tw/7Kcc
there is a great resource here.
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-
Andreas Falkenhahn
2016-08-22 14:04:15 UTC
Permalink
Post by d***@gmail.com
Post by Andreas Falkenhahn
Does anybody have an idea
what could cause this behaviour on 10.6 and how I can fix this?
http://bfy.tw/7Kcc
there is a great resource here.
You really think I didn't Google before asking? I certainly did, but
so far I haven't found anything that could help me here. If you have
anything more than just a Google search for "NSAlert 10.6", please
elaborate... (or send a link)
--
Best regards,
Andreas Falkenhahn mailto:***@falkenhahn.com

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkiv
じょいすじょん
2016-08-22 15:25:55 UTC
Permalink
Post by Andreas Falkenhahn
Post by d***@gmail.com
Post by Andreas Falkenhahn
Does anybody have an idea
what could cause this behaviour on 10.6 and how I can fix this?
http://bfy.tw/7Kcc
there is a great resource here.
You really think I didn't Google before asking? I certainly did, but
so far I haven't found anything that could help me here. If you have
anything more than just a Google search for "NSAlert 10.6", please
elaborate... (or send a link)
--
Best regards,
However you have not really shown any code at all.
So we do not know if you tested the returnCode from runModal against NSAlertFirstButtonReturn, NSAlertSecondButtonReturn, NSAlertThirdButtonReturn or all or none of these.

Without knowing more than the URL you shared saying you implemented what was in that document it's really hard to know what you might be doing wrong.

You might try the delegate-based sheet methods to run as described in the NSAlert class reference. (be sure to set your delegate and implement the callbacks)
You might try the completion handler sheet method. It's super compact.


For runModal, you do it inline, the delegate gets no callback unless you're using a help button.

// in simple test app.
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
// Insert code here to initialize your application
NSAlert *alert = [NSAlert new];
[alert addButtonWithTitle:@"OK"];
[alert addButtonWithTitle:@"Cancel"];
[alert setInformativeText:@"Informative text here."];
[alert setDelegate:self]; // Does nothing here unless we had a help button, because this is app modal.
NSInteger returnCode = [alert runModal];
NSLog(@"%@ %@ alert=%@ returnCode=%ld", self, NSStringFromSelector(_cmd), alert, returnCode);
if (returnCode == NSAlertFirstButtonReturn) {
NSLog(@"first button return %ld", returnCode);
} else if (returnCode == NSAlertSecondButtonReturn) {
NSLog(@"second button return");
} else if (returnCode == NSAlertThirdButtonReturn) {
NSLog(@"third button return");
} else {
NSLog(@"unknown button return");
}

}

I sure don't have anything that runs 10.6 so I couldn't even test it there, but I see no indication in the NSAlert Class Reference document history that would say this should not work.

You can of course also use a switch-case flow here instead of if-else.
Remember runModal is app-modal, so it doesn't return control to anything about the app until a button is pressed.

Really, you should consider using the delegate based sheet methods, assuming your app as a scripting language tool is document centric by design, wouldn't you want alerts to be more contextual?

App modal sheets are also possible.
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Sheets/Tasks/UsingAppModalDialogs.html



_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent to
Steve Mills
2016-08-22 14:17:46 UTC
Permalink
On Aug 22, 2016, at 09:04 AM, Andreas Falkenhahn <***@falkenhahn.com> wrote:

You really think I didn't Google before asking? I certainly did, but
so far I haven't found anything that could help me here. If you have
anything more than just a Google search for "NSAlert 10.6", please
elaborate... (or send a link)

Exactly. This list is for helping, not being snarky.

Sent from iCloud's ridiculous UI, so, sorry about the formatting
 
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This e
Ken Thomases
2016-08-22 15:30:53 UTC
Permalink
Post by Andreas Falkenhahn
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Dialog/Tasks/UsingAlerts.html#//apple_ref/doc/uid/20000871-129009-BCIFAAEJ
When I run it using
[alert runModal];
it shows up correctly but pressing a button doesn't do anything on 10.6. The
dialog isn't closed and just stays there. On 10.11, however, everything is
working correctly. Pressing a button closes the dialog and returns the id
of the button that has been pressed.
Since NSAlert is quite an essential class, I don't think that this is a bug
in 10.6 so I'm probably doing something wrong. Does anybody have an idea
what could cause this behaviour on 10.6 and how I can fix this?
Tell us more about the context. Is this a normal app or is it unusual in some way? Is this in the same app from your other thread where you're trying to shoehorn Cocoa into a C-based program? Can you reproduce the problem in a new, standard Cocoa app project?

Are any exceptions logged to the console when you press the button on 10.6? Does the button visually respond (depress/highlight) to your click and it's just that it doesn't take effect? Or does it not even respond to the click?

Are you running the alert from the main/original thread or a secondary thread?

Regards,
Ken


_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive
Andreas Falkenhahn
2016-08-22 15:46:28 UTC
Permalink
Post by Ken Thomases
Post by Andreas Falkenhahn
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Dialog/Tasks/UsingAlerts.html#//apple_ref/doc/uid/20000871-129009-BCIFAAEJ
When I run it using
[alert runModal];
it shows up correctly but pressing a button doesn't do anything on 10.6. The
dialog isn't closed and just stays there. On 10.11, however, everything is
working correctly. Pressing a button closes the dialog and returns the id
of the button that has been pressed.
Since NSAlert is quite an essential class, I don't think that this is a bug
in 10.6 so I'm probably doing something wrong. Does anybody have an idea
what could cause this behaviour on 10.6 and how I can fix this?
Tell us more about the context. Is this a normal app or is it
unusual in some way?
It is unusual in the way that it's not calling NSApplicationMain() but tries
to imitate what NSApplicationMain() does. Here goes the code that is executed
to set up the NSApp:

pool = [[NSAutoreleasePool alloc] init];

[MyApplication sharedApplication];

[NSApp setActivationPolicy:NSApplicationActivationPolicyRegular];

appDelegate = [[MyApplicationDelegate alloc] init];

[NSApp setDelegate:appDelegate];
[NSApp run];

In "applicationDidFinishLaunching" I then do this to assume control over
the program again:

[NSApp stop:nil];

NSEvent *event = [NSEvent otherEventWithType:NSApplicationDefined location:NSMakePoint(0, 0) modifierFlags:0 timestamp:0 windowNumber:0 context:nil subtype:0 data1:0 data2:0];

[NSApp postEvent:event atStart:YES];

Posting the dummy event in didFinishLaunching is necessary to make sure that [NSApp run]
returns. Otherwise it doesn't return before a real event comes in (e.g. by clicking
its icon in the dock.)
Post by Ken Thomases
Is this in the same app from your other thread
where you're trying to shoehorn Cocoa into a C-based program? Can
you reproduce the problem in a new, standard Cocoa app project?
Yup, see above ;)
Post by Ken Thomases
Are any exceptions logged to the console when you press the button
on 10.6?
No.
Post by Ken Thomases
Does the button visually respond (depress/highlight) to
your click and it's just that it doesn't take effect? Or does it not even respond to the click?
No, it responds visually when clicking it, see also below. The dialog boxes can
be controlled just fine, they just cannot be dismissed by clicking the buttons.
Post by Ken Thomases
Are you running the alert from the main/original thread or a secondary thread?
Main thread of course.

UPDATE: It seems to be a general problem with "runModal" because NSOpenPanel and NSSavePanel
show the very same behaviour. The dialogs can be controlled just fine, i.e. the user can
enter a filename, browse through directories, select files *BUT* it's not possible to close
the dialogs by clicking the buttons. The dialogs always stay open and "runModal" never
returns! I'm really wondering what is causing this...
--
Best regards,
Andreas Falkenhahn mailto:***@falkenhahn.com


_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent to geg
Ken Thomases
2016-08-22 15:55:20 UTC
Permalink
Post by Andreas Falkenhahn
Post by Ken Thomases
I've created an NSAlert dialog …
it shows up correctly but pressing a button doesn't do anything on 10.6. The
dialog isn't closed and just stays there. …
Tell us more about the context. Is this a normal app or is it
unusual in some way?
It is unusual in the way that it's not calling NSApplicationMain() but tries
to imitate what NSApplicationMain() does. Here goes the code that is executed
pool = [[NSAutoreleasePool alloc] init];
[MyApplication sharedApplication];
[NSApp setActivationPolicy:NSApplicationActivationPolicyRegular];
appDelegate = [[MyApplicationDelegate alloc] init];
[NSApp setDelegate:appDelegate];
[NSApp run];
In "applicationDidFinishLaunching" I then do this to assume control over
[NSApp stop:nil];
NSEvent *event = [NSEvent otherEventWithType:NSApplicationDefined location:NSMakePoint(0, 0) modifierFlags:0 timestamp:0 windowNumber:0 context:nil subtype:0 data1:0 data2:0];
[NSApp postEvent:event atStart:YES];
Posting the dummy event in didFinishLaunching is necessary to make sure that [NSApp run]
returns. Otherwise it doesn't return before a real event comes in (e.g. by clicking
its icon in the dock.)
Post by Ken Thomases
Is this in the same app from your other thread
where you're trying to shoehorn Cocoa into a C-based program? Can
you reproduce the problem in a new, standard Cocoa app project?
Yup, see above ;)
This is ambiguous. Was the "yup" to my first or second question? If to the second, then what you wrote above is definitely not a standard Cocoa app. I'm trying to help you determine the specific factor that's causing the problem. The question is whether the games you're playing with the app loop are responsible. So, does the problem happen in an app where you don't play those games?

Regards,
Ken


_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.nark
Andreas Falkenhahn
2016-08-22 16:44:58 UTC
Permalink
Post by Ken Thomases
Post by Andreas Falkenhahn
Post by Ken Thomases
Is this in the same app from your other thread
where you're trying to shoehorn Cocoa into a C-based program? Can
you reproduce the problem in a new, standard Cocoa app project?
Yup, see above ;)
This is ambiguous. Was the "yup" to my first or second question?
Oops, sorry, the "yup" addressed your first question.
Post by Ken Thomases
If to the second, then what you wrote above is definitely not a
standard Cocoa app. I'm trying to help you determine the specific
factor that's causing the problem. The question is whether the
games you're playing with the app loop are responsible. So, does
the problem happen in an app where you don't play those games?
I think it's obvious that this must be related to the app loop "games"
because I think we can rule out the possibility that such a fundamental
functionality like "runModal" is broken completely in 10.6 for NSAlert,
NSOpenPanel, NSSavePanel... I'm pretty certain that it will work
correctly when doing things the proper way using NSApplicationMain().

Still, it must be possible to get these to work correctly when setting
up the NSApp in a custom way.

Hence, I've now prepared an absolutely minimal test program that
reproduces the issue, it's only 50 lines so it should be really
self-explaining. The NSAlert code in this test program is a direct
copy&paste from Apple's site.

Here we go:

---------------------------------------------------------------------------
#include <stdio.h>
#include <ctype.h>

#include <Cocoa/Cocoa.h>

@interface MyApplication : NSApplication
@end

@implementation MyApplication
@end

@interface MyApplicationDelegate : NSObject
@end

@implementation MyApplicationDelegate
- (void)applicationDidFinishLaunching:(NSNotification *)notification
{
[NSApp stop:nil];

NSEvent *event = [NSEvent otherEventWithType:NSApplicationDefined location:NSMakePoint(0, 0) modifierFlags:0 timestamp:0 windowNumber:0 context:nil subtype:0 data1:0 data2:0];

[NSApp postEvent:event atStart:YES];
}
@end

int main(int argc, char *argv[])
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

[MyApplication sharedApplication];

[NSApp setActivationPolicy:NSApplicationActivationPolicyRegular];

id appDelegate = [[MyApplicationDelegate alloc] init];

[NSApp setDelegate:appDelegate];

[NSApp run];

NSAlert *alert = [[NSAlert alloc] init];
[alert addButtonWithTitle:@"OK"];
[alert addButtonWithTitle:@"Cancel"];
[alert setMessageText:@"Delete the record?"];
[alert setInformativeText:@"Deleted records cannot be restored."];
[alert setAlertStyle:NSWarningAlertStyle];

[alert runModal];
[alert release];

[pool release];

return 0;
}
---------------------------------------------------------------------------

Works correctly on 10.11, but doesn't work on 10.6.
--
Best regards,
Andreas Falkenhahn mailto:***@falkenhahn.com


_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent t
Graham Cox
2016-08-22 23:17:09 UTC
Permalink
Post by Andreas Falkenhahn
It is unusual in the way that it's not calling NSApplicationMain() but tries
to imitate what NSApplicationMain() does. Here goes the code that is executed
There’s your problem.

You’re not running a proper NSRunLoop, so the alert panel is going to be non-operational. When a modal alert is shown, the run loop is set to a run mode that reflects this, which changes the way events are routed and processed. Modal panels are really an illusion that the application creates by managing its NSRunLoop in this way.

You are going to have to fix your architecture to run the app in a far more conventional way.

I know what you said about a cross-platform model forcing your hand, but I don’t believe that your solution is the right one. I believe you can run the app in a standard way and still support this model. I know this because I had to do exactly the same thing when Mac OS X first came out, to adapt my app framework for the classic Mac OS (“MacZoop”) to run on OS X. That framework had a WaitNextEvent() style architecture, but with care I was able to adapt it to the modern approach without breaking that model, but still being something that played nice with preemptive mutitasking, non-centralized event despatch, and so on. Of course that was 15 years ago, and the details are now hazy, but the essence of it was to turn the thinking about fetching events on its head: WaitNextEvent is not something you poll, but something that goes to sleep until there’s something for your app to do. From the client’s perspective, there’s no difference!

I suggest you reinstate a standard runloop within NSApplication, stop playing games with it, and simply use its -nextEventMacthingMask: method to stand in for WaitNextEvent(). All your various problems will be solved at once.

Or use Carbon, not Cocoa, but good luck with that.

—Graham






_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This emai
Andreas Falkenhahn
2016-08-23 14:52:43 UTC
Permalink
Post by Graham Cox
Post by Andreas Falkenhahn
It is unusual in the way that it's not calling NSApplicationMain() but tries
to imitate what NSApplicationMain() does. Here goes the code that is executed
There’s your problem.
You’re not running a proper NSRunLoop, so the alert panel is going
to be non-operational. When a modal alert is shown, the run loop is
set to a run mode that reflects this, which changes the way events
are routed and processed. Modal panels are really an illusion that
the application creates by managing its NSRunLoop in this way.
You are going to have to fix your architecture to run the app in a far more conventional way.
I know what you said about a cross-platform model forcing your
hand, but I don’t believe that your solution is the right one. I
believe you can run the app in a standard way and still support this
model. I know this because I had to do exactly the same thing when
Mac OS X first came out, to adapt my app framework for the classic
Mac OS (“MacZoop”) to run on OS X. That framework had a
WaitNextEvent() style architecture, but with care I was able to
adapt it to the modern approach without breaking that model, but
still being something that played nice with preemptive mutitasking,
non-centralized event despatch, and so on. Of course that was 15
years ago, and the details are now hazy, but the essence of it was
WaitNextEvent is not something you poll, but something that goes to
sleep until there’s something for your app to do. From the client’s
perspective, there’s no difference!
I suggest you reinstate a standard runloop within NSApplication,
stop playing games with it, and simply use its
-nextEventMacthingMask: method to stand in for WaitNextEvent(). All
your various problems will be solved at once.
I really can't use NSApplicationMain() because AFAICS it also expects
to load a NIB file from the app bundle which simply doesn't exist for
my app because I'm not using Xcode at all and everything is set up
programmatically. Please understand that people interested in cross-
platform development tend to keep all dependencies on proprietary
technologies like NIB and proprietary programs like Xcode to an absolute
minimum if possible. Just give me a proper makefile instead and I'm
happy.

And it absolutely is possible to create apps without going the orthodox
route using NIBs and NSApplicationMain(). Just look at the Cocoa backends
of popular cross-platform toolkits like wxWidgets, SDL, GLFW... AFAICS,
none of them ever calls into NSApplicationMain(). Instead, they all seem
to use custom app set up code and custom event loops.

I'd just wish that Apple would provide some more information to developers
who wish to avoid the conventional way because currently there's a lot
of guesswork involved and of course there's always the risk that apps
using such custom code won't be compatible with future OS X versions.
That's why some official documentation on alternatives to NSApplicationMain()
would be really nice because then they would be really safe to use.

That being said, I've now figured out what was the cause of the hang
on 10.6. Calling [NSApp stop] was the culprit here. Instead of [NSApp run]
I just have to call [NSApp finishLaunching] and everything is good.
Post by Graham Cox
Or use Carbon, not Cocoa, but good luck with that.
I have been using Carbon for the last 12 years and I'd love to be able
to continue using it because I prefer clean, old school C APIs but, alas,
we all know that it was cancelled quite unexpectedly. In fact, when I started
to write a Carbon backend some 12 years ago the official word was still that
one could use whatever one preferred, Carbon or Cocoa. As a C programmer I
took to Carbon of course only to learn after a few months that there would
be no 64-bit support for Carbon, but that's another story I guess. I still
maintain the Carbon backend for the PowerPC branch of my app, though ;)
--
Best regards,
Andreas Falkenhahn mailto:***@falkenhahn.com


_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent to ***@ml-in
Scott Ribe
2016-08-23 15:45:41 UTC
Permalink
Post by Andreas Falkenhahn
I really can't use NSApplicationMain() because AFAICS it also expects
to load a NIB file from the app bundle
The nib to load at startup is specified in the plist, I bet if you leave that entry out, it won't try...
--
Scott Ribe
***@elevated-dev.com
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(303) 722-0567 voice






_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This
Andreas Falkenhahn
2016-08-23 17:21:33 UTC
Permalink
Post by Scott Ribe
Post by Andreas Falkenhahn
I really can't use NSApplicationMain() because AFAICS it also expects
to load a NIB file from the app bundle
The nib to load at startup is specified in the plist, I bet if you
leave that entry out, it won't try...
If this isn't documented anywhere, it's still the same old guesswork game
and there is no guarantee that such a set up won't fail spectacularly
in future versions (or older versions)...

Apple really should be much more verbose as to what alternative options
there are for people who need more fine-tuned control over application
setup and main loop, then the command line fetishists could finally do
it right ;-)
--
Best regards,
Andreas Falkenhahn mailto:***@falkenhahn.com

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive.ne
d***@gmail.com
2016-08-23 17:30:27 UTC
Permalink
It may load it any way.
You don't have to have a nib unless your plist says you will.

Sent from my iPhone
Post by Scott Ribe
Post by Andreas Falkenhahn
I really can't use NSApplicationMain() because AFAICS it also expects
to load a NIB file from the app bundle
The nib to load at startup is specified in the plist, I bet if you leave that entry out, it won't try...
--
Scott Ribe
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(303) 722-0567 voice
_______________________________________________
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
https://lists.apple.com/mailman/options/cocoa-dev/dangerwillrobinsondanger%40gmail.com
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent to g
Andreas Falkenhahn
2016-08-23 17:56:07 UTC
Permalink
Post by d***@gmail.com
You don't have to have a nib unless your plist says you will.
Is that your personal opinion or is this documented anywhere?

Apple's documentation of NSApplicationMain() clearly states that
this function "loads the main nib file from the application's main
bundle." Consequently, this means that the behaviour of NSApplicationMain()
without a main nib file in the app bundle is undefined. It may work
now but it can break at any time because the documentation doesn't
say that the nib file is optional. So it could happen that with the
next OS X update all hell will break loose if NSApplicationMain()
suddenly chooses to fail if there is no nib. Such a choice would
be fully valid since the documentation clearly says that it expects
a main nib in the app bundle...

I'm just exaggerating here to point out the dilemma that we have
because these things aren't documented and it's all just assumptions.
Hence, using NSApplicationMain() without a nib is no better than
ditching NSApplicationMain() altogether and setting up things in
a custom way. Both are undocumented and just based on assumptions.
Thus, both may fail at any time in the future.
--
Best regards,
Andreas Falkenhahn mailto:***@falkenhahn.com

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.
d***@gmail.com
2016-08-23 23:31:32 UTC
Permalink
Post by Andreas Falkenhahn
Is that your personal opinion or is this documented anywhere?
There's not anything to the contrary I've seen.
Look no further than LSUIElement.
There is an info plist key that says you have no UI, and guess what it works even if you included one.
There are methods for launching/activating without UI.
App templates have evolved over the years.
There wasn't always a wired up app delegate in the nib by default. It just happens to be a good starting pattern most of the time.
You don't need an app delegate.
You don't need a window.
You are not required to have any of the default menus.
You don't have to provide any icon (the system will provide a default based on the .app bundle UTI).
You only really have to have an Info plist but that can be embedded in the binary, so even the app bundle is not required.
All this adds up to its not required. It's strongly encouraged and supported because it's a great set of design patterns that facilitate good development and consistent experience within the ecosystem.

There are always folks from other language and platform backgrounds who show up wanting to avoid nibs. And they can. But some things are going to be incredibly hard without it.

You do need to hang on to that main runloop created by NSApplicationMain() if you want any AppKit views to work right.
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net
corbin dunn
2016-08-24 17:37:23 UTC
Permalink
Post by d***@gmail.com
Post by Andreas Falkenhahn
Is that your personal opinion or is this documented anywhere?
There's not anything to the contrary I've seen.
Andreas is right. For you to call NSApplicationMain means you have to have a main nib (or storyboard). But to be clear… NSApplicationMain just initializes NSApp (the instance, which is based on NSPrincipalClass), and then calls [NSApp run]. The main run loop is in [NSApp run]. You probably can call [NSApp run] without actually creating a NIB.

corbin
Post by d***@gmail.com
Look no further than LSUIElement.
There is an info plist key that says you have no UI, and guess what it works even if you included one.
There are methods for launching/activating without UI.
App templates have evolved over the years.
There wasn't always a wired up app delegate in the nib by default. It just happens to be a good starting pattern most of the time.
You don't need an app delegate.
You don't need a window.
You are not required to have any of the default menus.
You don't have to provide any icon (the system will provide a default based on the .app bundle UTI).
You only really have to have an Info plist but that can be embedded in the binary, so even the app bundle is not required.
All this adds up to its not required. It's strongly encouraged and supported because it's a great set of design patterns that facilitate good development and consistent experience within the ecosystem.
There are always folks from other language and platform backgrounds who show up wanting to avoid nibs. And they can. But some things are going to be incredibly hard without it.
You do need to hang on to that main runloop created by NSApplicationMain() if you want any AppKit views to work right.
_______________________________________________
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive.ne

Graham Cox
2016-08-23 22:45:37 UTC
Permalink
Post by Andreas Falkenhahn
I really can't use NSApplicationMain() because AFAICS it also expects
to load a NIB file from the app bundle which simply doesn't exist for
my app because I'm not using Xcode at all and everything is set up
programmatically.
Even your main menu bar?

The main nib need only contain the very barest minimum, for example the skeleton of the main menu bar. It doesn’t need to have a window (and indeed for document-based apps typically does not).

So even if you *must* have a nib (which isn’t proven one way or the other), the nib can be minimal.

—Graham



_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent
Continue reading on narkive:
Loading...