Re: Thoughts on Cocoa source code
> Le 10 oct. 2019 à 00:14, Jens Alfke via Cocoa-dev > a écrit : > > > >> On Oct 9, 2019, at 11:39 AM, Aandi Inston wrote: >> >> * But for whatever reason, I'm using the Mac OS 10.14 SDK. So that will get >> a compile-time warning. > > Only if you don't turn on -Werror, which I really, really recommend everyone > do. Calling a method that a class isn't declared as implementing is a fairly > common mistake, and warnings are way too easy to overlook. > > In this situation, you get around the warning/error by declaring the method > yourself in a category on the framework class. > >> * I add a check for actual OS version, so I am very sure not try to call >> [NSApplication doUsefulThing] >> unless the OS is 10.15 or later. >> * But what happens if it runs in 10.15? Does it actually do the useful thing? > > The method will be called, yes. I can't think of any particular reason it > wouldn't work. It may not work if -doUsefulThing rely on some code that performs a « Link SDK version » runtime check and assume the new code path wlll be executed because this method is not supposed to be called from a app linked on an older SDK.. This is rather unlikely, but this is usually safer to update your SDK if you want the last features. ___ Cocoa-dev mailing list (Cocoa-dev@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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on Cocoa source code
> On Oct 9, 2019, at 11:39 AM, Aandi Inston wrote: > > * But for whatever reason, I'm using the Mac OS 10.14 SDK. So that will get a > compile-time warning. Only if you don't turn on -Werror, which I really, really recommend everyone do. Calling a method that a class isn't declared as implementing is a fairly common mistake, and warnings are way too easy to overlook. In this situation, you get around the warning/error by declaring the method yourself in a category on the framework class. > * I add a check for actual OS version, so I am very sure not try to call > [NSApplication doUsefulThing] > unless the OS is 10.15 or later. > * But what happens if it runs in 10.15? Does it actually do the useful thing? The method will be called, yes. I can't think of any particular reason it wouldn't work. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on Cocoa source code
Nothing is statically linked. The version of the SDK you compile with is embedded into your application and Cocoa (and other Apple frameworks) consult this at runtime to determine appropriate behavior. Often this means you don’t get the new behavior, but sometimes Apple will automatically “opt you in” if they feel like it doesn’t break too many applications (for example, macOS Sierra’s window tabbing). Saagar Jha [Snipped to stay under the list limit] ___ Cocoa-dev mailing list (Cocoa-dev@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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on Cocoa source code
> On Oct 9, 2019, at 10:41 AM, Jens Alfke via Cocoa-dev > wrote: > > You don't want to use the _implementation_ details! Those can and do change > completely over time There is a situation where I think it is fine to use the implementation details, and that is to work around a problem in an old release of macOS, which is never going to be changed (with the possible exception of a security patch, I suppose, but that is unlikely to cause any problems). Believe it or not, some bugs are not fixed until the next release, or the one after that, or … ___ Cocoa-dev mailing list (Cocoa-dev@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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on Cocoa source code
> On Oct 9, 2019, at 11:58 AM, Pier Bover wrote: > > For example Imagix is a company that does image transformation in the cloud > and uses macs because of the high performance of CoreImage > (https://photos.imgix.com/racking-mac-pros) It's still more cost effective > for them to use expensive macs vs linux servers because of the performance > increase. Pretty amazing if you think about it. They should be thrilled that Apple announced an optimized version of the 2019 Mac Pro for rack deployment. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on Cocoa source code
" . Cocoa is part of the OS, and changes one very OS release. " This reminds me of a question which pops up for me every few years in development. I can't call to mind the last specific details, but it will happen again. Let's create an imaginary problem: * Apple add a new class behaviour to Cocoa in macOS 10.15. We'll suppose they add [NSApplication doUsefulThing] * But for whatever reason, I'm using the Mac OS 10.14 SDK. So that will get a compile-time warning. Still, I'd really like to do the useful thing anyway, and without changing the SDK for whatever reason. * I add a check for actual OS version, so I am very sure not try to call [NSApplication doUsefulThing] unless the OS is 10.15 or later. * But what happens if it runs in 10.15? Does it actually do the useful thing? Are the Cocoa methods entirely dynamically loaded/provided by the live OS? Or does anything get statically linked, flagged, is the binary's SDK version checked or is there anything else that will prevent this call doing the useful thing? Thanks in advance! On Wed, 9 Oct 2019 at 18:42, Jens Alfke via Cocoa-dev < cocoa-dev@lists.apple.com> wrote: > > > > On Oct 9, 2019, at 10:19 AM, Turtle Creek Software via Cocoa-dev < > cocoa-dev@lists.apple.com> wrote: > > > > Why is Cocoa source code hidden? > > So, take this as opinions of someone who worked at Apple, on [among other > things] Mac OS X apps from 2000-2007. > > (a) It's part of Apple's crown jewels and seen as a competitive advantage. > (b) It calls all sorts of internal APIs of lower-level components like the > WindowServer, and Apple doesn't want to expose those APIs because they're > undocumented, easily misused, hard to support, subject to change at any > moment, etc. > (c) If developers look at the source code they'll be tempted to make use > of undocumented behaviors, private methods, etc. which makes their apps > much more likely to break in future OS versions. (This already does happen, > to an extent, but with source code it would be much more pervasive, given > the dynamic nature of Obj-C and how easy it is to call internal methods or > even patch system classes.) > (d) Internal source code tends to have comments and identifiers that refer > to internal code names, canceled projects, and other stuff that shouldn't > be made public. Sanitizing this is a pain. > (e) Apple obviously works on lots of features that remain secret for > months or years; these would all have to be kept in private branches, > causing all sorts of merging/rebasing headaches. > (d) It takes quite a lot of effort to maintain a large open source > project. It's not just dumping the source to Github. > > > Yeah, the headers are visible, and Apple has > > info online. But sometimes that was not sufficient to understand the > actual > > implementation details. > > You don't want to use the _implementation_ details! Those can and do > change completely over time — I know NSView has been > redesigned/reimplemented at least twice since 2000 — so making use of them > on OS version N could cause your app to break in version N+1. You want to > know the details of the (defined) _behaviors_. That means better > documentation. I agree that Apple could improve here. > > > When debugging, the stack trace inside Cocoa was just a bunch of > > rarely-helpful Assembly. No way to set breakpoints inside Cocoa classes > > That's not true; you can use symbolic breakpoints to break on any > Objective-C method, or any C function that has a visible symbol. > > > I personally learned C++ while using the PowerPlant library from > Metrowerks. > > The difference is that PP is code that you link statically into your app. > It doesn't change versions unless you explicitly update it. Cocoa is part > of the OS, and changes one very OS release. Binary compatibility is super > important to Apple, so Cocoa being a "black box" is actually a feature, not > a bug. > > —Jens > ___ > > Cocoa-dev mailing list (Cocoa-dev@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/aandi%40quite.com > > This email sent to aa...@quite.com > ___ Cocoa-dev mailing list (Cocoa-dev@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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on Cocoa source code
> Perhaps Apple does not want to give away the Crown Jewels. Indeed. There is some stuff in there that AFAIK no one has been able to replicate. For example Imagix is a company that does image transformation in the cloud and uses macs because of the high performance of CoreImage ( https://photos.imgix.com/racking-mac-pros) It's still more cost effective for them to use expensive macs vs linux servers because of the performance increase. Pretty amazing if you think about it. ___ Cocoa-dev mailing list (Cocoa-dev@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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on Cocoa source code
> On Oct 9, 2019, at 11:19 AM, Turtle Creek Software via Cocoa-dev > wrote: > > Why is Cocoa source code hidden? Because Apple does not want to expose Cocoa source source. It is proprietary software. > Many of the frustrations we had with the 64-bit update attempt were caused > by Cocoa's lack of visible source. It was a "black box" that often required > trial-and-error to figure out. Yeah, the headers are visible, and Apple has > info online. But sometimes that was not sufficient to understand the actual > implementation details. > > When debugging, the stack trace inside Cocoa was just a bunch of > rarely-helpful Assembly. No way to set breakpoints inside Cocoa classes, or > step through their C code. More mysteries and headaches. I agree reading assembly is horrid. Did you know that you can set a symbolic breakpoint on code inside the Cocoa frameworks? You can also swizzle a framework method to gain insight into what Apple is doing. You can also examine Cocotron source code for insight into what maybe going on behind the scenes. > I personally learned C++ while using the PowerPlant library from > Metrowerks. Its source files were totally exposed. Seeing comments and code > really helped. When designing or debugging, it was possible to step through > their code and see exactly how it functioned. Cocoa would be so much > easier to use if its source was accessible like that. > > In fact, why isn't Cocoa open source? Apple open-sources Swift and the > Darwin kernel. Surely the GUI can't be any riskier to expose to developers? Perhaps Apple does not want to give away the Crown Jewels. --Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on Cocoa source code
Saagar Jha > On Oct 9, 2019, at 10:19, Turtle Creek Software via Cocoa-dev > wrote: > > Why is Cocoa source code hidden? > > Many of the frustrations we had with the 64-bit update attempt were caused > by Cocoa's lack of visible source. It was a "black box" that often required > trial-and-error to figure out. Yeah, the headers are visible, and Apple has > info online. But sometimes that was not sufficient to understand the actual > implementation details. > > When debugging, the stack trace inside Cocoa was just a bunch of > rarely-helpful Assembly. No way to set breakpoints inside Cocoa classes, or > step through their C code. More mysteries and headaches. You can set symbolic breakpoints inside of Cocoa. And a good disassembler will get you a significant portion of the way there if you’re trying to debug in the internals of a method. > I personally learned C++ while using the PowerPlant library from > Metrowerks. Its source files were totally exposed. Seeing comments and code > really helped. When designing or debugging, it was possible to step through > their code and see exactly how it functioned. Cocoa would be so much > easier to use if its source was accessible like that. > > In fact, why isn't Cocoa open source? Apple open-sources Swift and the > Darwin kernel. Surely the GUI can't be any riskier to expose to developers? > > Our programmers found several PowerPlant bugs over the years. We fixed them > right away in our copy, and reported them so they were fixed in the next > update. Apple could get the same benefit for Cocoa. Seems like a win-win. > > Someone suggested that I send comments to Tim Cook or whomever at Apple. > That seems a good idea, but I'd like to see discussion results, first. > Assemble more viewpoints. > > Casey McDermott > TurtleSoft.com > ___ > > Cocoa-dev mailing list (Cocoa-dev@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/saagar%40saagarjha.com > > This email sent to saa...@saagarjha.com ___ Cocoa-dev mailing list (Cocoa-dev@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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on Cocoa source code
> On Oct 9, 2019, at 10:19 AM, Turtle Creek Software via Cocoa-dev > wrote: > > Why is Cocoa source code hidden? So, take this as opinions of someone who worked at Apple, on [among other things] Mac OS X apps from 2000-2007. (a) It's part of Apple's crown jewels and seen as a competitive advantage. (b) It calls all sorts of internal APIs of lower-level components like the WindowServer, and Apple doesn't want to expose those APIs because they're undocumented, easily misused, hard to support, subject to change at any moment, etc. (c) If developers look at the source code they'll be tempted to make use of undocumented behaviors, private methods, etc. which makes their apps much more likely to break in future OS versions. (This already does happen, to an extent, but with source code it would be much more pervasive, given the dynamic nature of Obj-C and how easy it is to call internal methods or even patch system classes.) (d) Internal source code tends to have comments and identifiers that refer to internal code names, canceled projects, and other stuff that shouldn't be made public. Sanitizing this is a pain. (e) Apple obviously works on lots of features that remain secret for months or years; these would all have to be kept in private branches, causing all sorts of merging/rebasing headaches. (d) It takes quite a lot of effort to maintain a large open source project. It's not just dumping the source to Github. > Yeah, the headers are visible, and Apple has > info online. But sometimes that was not sufficient to understand the actual > implementation details. You don't want to use the _implementation_ details! Those can and do change completely over time — I know NSView has been redesigned/reimplemented at least twice since 2000 — so making use of them on OS version N could cause your app to break in version N+1. You want to know the details of the (defined) _behaviors_. That means better documentation. I agree that Apple could improve here. > When debugging, the stack trace inside Cocoa was just a bunch of > rarely-helpful Assembly. No way to set breakpoints inside Cocoa classes That's not true; you can use symbolic breakpoints to break on any Objective-C method, or any C function that has a visible symbol. > I personally learned C++ while using the PowerPlant library from Metrowerks. The difference is that PP is code that you link statically into your app. It doesn't change versions unless you explicitly update it. Cocoa is part of the OS, and changes one very OS release. Binary compatibility is super important to Apple, so Cocoa being a "black box" is actually a feature, not a bug. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Thoughts on Cocoa source code
> On 09 Oct 2019, at 1:19 pm, Turtle Creek Software via Cocoa-dev > wrote: > > In fact, why isn't Cocoa open source? Apple open-sources Swift and the > Darwin kernel. Surely the GUI can't be any riskier to expose to developers? This is a business strategy question, not a Cocoa development question. Besides, nobody on this list will have an authoritative or succinct answer. -ben ___ Cocoa-dev mailing list (Cocoa-dev@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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Thoughts on Cocoa source code
Why is Cocoa source code hidden? Many of the frustrations we had with the 64-bit update attempt were caused by Cocoa's lack of visible source. It was a "black box" that often required trial-and-error to figure out. Yeah, the headers are visible, and Apple has info online. But sometimes that was not sufficient to understand the actual implementation details. When debugging, the stack trace inside Cocoa was just a bunch of rarely-helpful Assembly. No way to set breakpoints inside Cocoa classes, or step through their C code. More mysteries and headaches. I personally learned C++ while using the PowerPlant library from Metrowerks. Its source files were totally exposed. Seeing comments and code really helped. When designing or debugging, it was possible to step through their code and see exactly how it functioned. Cocoa would be so much easier to use if its source was accessible like that. In fact, why isn't Cocoa open source? Apple open-sources Swift and the Darwin kernel. Surely the GUI can't be any riskier to expose to developers? Our programmers found several PowerPlant bugs over the years. We fixed them right away in our copy, and reported them so they were fixed in the next update. Apple could get the same benefit for Cocoa. Seems like a win-win. Someone suggested that I send comments to Tim Cook or whomever at Apple. That seems a good idea, but I'd like to see discussion results, first. Assemble more viewpoints. Casey McDermott TurtleSoft.com ___ Cocoa-dev mailing list (Cocoa-dev@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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Alerts in Xcode 11
Just try it with the window code commented out.
In any case, where you do have your code with the window, I would expect that
you would make the window key and visible not manually adjust its layer and on
dismiss, simply resign.
Alex Zavatone
Sent from my iPhone
> On Sep 30, 2019, at 4:48 PM, Doug Hardie via Cocoa-dev
> wrote:
>
> Not sure how to do that. It's not in any view controller as it is used in
> virtually all of the various view controllers. That's why I wanted it as a
> function.
>
> -- Doug
>
>> On 30 September 2019, at 14:44, David Duncan wrote:
>>
>> What happens if you present it over your normal view controller hierarchy
>> instead of using another window?
>>
>> Has your application adopted UIWindowScene?
>>
>>> On Sep 30, 2019, at 5:36 PM, Doug Hardie via Cocoa-dev
>>> wrote:
>>>
>>> I have some code that presents an alert to the user with information they
>>> need, and an OK button to clear it. It works fine in the previous Xcode
>>> versions. However, after upgrading to 11, it now displays the alert and
>>> then immediately clears it. This happens both in the simulator and on a
>>> real device. I have played around with the code and can't figure out how
>>> to make it leave the alert on the screen. This is in Swift. It is a
>>> function that is called from numerous places in the app.
>>>
>>> func NotificationAlert (_ msg1: String, _ msg2: String) {
>>> let ErrorAlert = UIAlertController(title: msg1, message: msg2,
>>> preferredStyle: .alert)
>>> let dismiss = UIAlertAction(title: "Ok", style: .default, handler: nil)
>>> ErrorAlert.addAction(dismiss)
>>> ErrorAlert.presentInOwnWindow(animated: true, completion: nil)
>>> }
>>>
>>> extension UIAlertController {
>>> func presentInOwnWindow(animated: Bool, completion: (() -> Void)?) {
>>> let alertWindow = UIWindow(frame: UIScreen.main.bounds)
>>> alertWindow.rootViewController = UIViewController()
>>> alertWindow.windowLevel = UIWindow.Level.alert + 1;
>>> alertWindow.makeKeyAndVisible()
>>> alertWindow.rootViewController?.present(self, animated: animated,
>>> completion: completion)
>>> }
>>> }
>>>
>>>
>>> -- Doug
>>>
>>> ___
>>>
>>> Cocoa-dev mailing list (Cocoa-dev@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/david.duncan%40apple.com
>>>
>>> This email sent to david.dun...@apple.com
>>
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@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/zav%40mac.com
>
> This email sent to z...@mac.com
___
Cocoa-dev mailing list (Cocoa-dev@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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Alerts in Xcode 11
I'm by no means an expert but if I understand what you're trying to do, I think
the approach I would take is to make an extension on UIViewController:
extension UIViewController {
func notificationAlert(_ msg1: String, _ msg2: String) {
// create the UIAlertAlertController
// and then do as David Duncan said and do:
self.present(, animated: completion: …)
}
}
Now all your UIViewController subclasses can call that method (and because it's
a method, they have access to self which is a subclass of UIViewController).
HTH,
Dave
> On Sep 30, 2019, at 11:27 PM, Doug Hardie via Cocoa-dev
> wrote:
>
> I tried that and swift complains that self is not defined. This is not in a
> view controller but a stand alone function used in many view controllers.
> Generally it is used during a segue, but I added one in a view controller to
> a button action, not part of a segue and it dismissed the alert also.
>
> -- Doug
>
>> On 30 September 2019, at 19:48, David Duncan wrote:
>>
>> Instead of creating a new window and a root view controller in order to
>> present your alert, just use (assuming self is a UIViewController)
>> self.present(, animated: completion: …)
>>
>>> On Sep 30, 2019, at 5:48 PM, Doug Hardie wrote:
>>>
>>> Not sure how to do that. It's not in any view controller as it is used in
>>> virtually all of the various view controllers. That's why I wanted it as a
>>> function.
>>>
>>> -- Doug
>>>
On 30 September 2019, at 14:44, David Duncan
wrote:
What happens if you present it over your normal view controller hierarchy
instead of using another window?
Has your application adopted UIWindowScene?
> On Sep 30, 2019, at 5:36 PM, Doug Hardie via Cocoa-dev
> wrote:
>
> I have some code that presents an alert to the user with information they
> need, and an OK button to clear it. It works fine in the previous Xcode
> versions. However, after upgrading to 11, it now displays the alert and
> then immediately clears it. This happens both in the simulator and on a
> real device. I have played around with the code and can't figure out how
> to make it leave the alert on the screen. This is in Swift. It is a
> function that is called from numerous places in the app.
>
> func NotificationAlert (_ msg1: String, _ msg2: String) {
> let ErrorAlert = UIAlertController(title: msg1, message: msg2,
> preferredStyle: .alert)
> let dismiss = UIAlertAction(title: "Ok", style: .default, handler: nil)
> ErrorAlert.addAction(dismiss)
> ErrorAlert.presentInOwnWindow(animated: true, completion: nil)
> }
>
> extension UIAlertController {
> func presentInOwnWindow(animated: Bool, completion: (() -> Void)?) {
>let alertWindow = UIWindow(frame: UIScreen.main.bounds)
>alertWindow.rootViewController = UIViewController()
>alertWindow.windowLevel = UIWindow.Level.alert + 1;
>alertWindow.makeKeyAndVisible()
>alertWindow.rootViewController?.present(self, animated: animated,
> completion: completion)
> }
> }
>
>
> -- Doug
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@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/david.duncan%40apple.com
>
> This email sent to david.dun...@apple.com
>>>
>>
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@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/davelist%40mac.com
>
> This email sent to davel...@mac.com
___
Cocoa-dev mailing list (Cocoa-dev@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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
