Re: Thoughts on ARC
Swift may be the solution, but it's built on a weak foundation. It makes cross-platform development almost impossible. The TIOBE index shows Swift declining (and Objective-C increasing). So, maybe it isn't. I don't yet have a lot of experience with Swift, but I would already argue that Swift is not the solution. Swift is cool and has some really neat features that make for good presentations and blog posts (where the real-world issues and constraints associated with interfacing to other systems, particularly older ones that do not use HTTP, can be minimized or eliminated entirely); however, to use it to do anything other than building a desktop or IOS GUI application seems to result in code with messy syntax and what seem to me to be hacks in order to bridge between NS* and CG* code. (Lots of casts and strange machinations for massaging pointers.) I'm in the process of converting an application written in C++ using an older version of Qt because the Qt code relies on Carbon (which has been removed from Catalina). The new code is in Swift. I've written and maintained code that uses UNIX-style C sockets for many years, but finding a native approach for plain sockets in Swift was very difficult. There appears to be good support for async HTTP communication, but not much for socket-based TCP. I found some examples on the web that were built around Grand Dispatch, but that feels clunky in a command-line application. Further, the many versions of Swift complicate the examples; if the example code was written in Swift 2 or Swift 3, it may require non-trivial modification to work in Swift 5 without compiler errors and warnings. I've settled on using a library from IBM called BlueSocket with a thin wrapper around it, and that seems to be working for me for now. However, even using the command line tools (swift package) for creating and managing an XCode project with external library dependencies has been for me a challenge. XCode and the packaging framework seem to be fighting over control of the project's structure, and going back and forth between them (and regenerating the XCode project each time) is tedious. But then maybe I'm just not using the tools corre ctly. Also, as you've said Swift makes cross-platform development nearly impossible because, even though Swift itself is available on other platforms, the pre-built components that prevent the developer from having to reinvent every wheel from scratch are not. This app I am rewriting _was_ cross-platform when it was built with Qt, but it will no longer be when we rework it for Swift. (And we are motivated to use Apple's "approved" language and tools in order to be eligible for developer support in the event that we need it. Our experience has been that they will not help, even with an Apple Developer subscription, if the app is in pure C/C++ or Java or anything but Swift or Objective-C.) It could simply be that Swift is the wrong tool for my current task. However, I'm not sure what would be. This could be done in Java or Python or Javascript with Node or any number of other mature, cross-platform options, but those aren't really welcome as first-class citizens in the Mac app space (or at least result in solutions that potentially require a lot of manual intervention on the part of the user). It could also be done in pure C, but that seems like a step backwards. I'm not down on Swift; as I said, I think it has some really neat features and constructs, and I'm sure that making a desktop or IOS GUI application is its sweet spot. I just wish there was a solid option for those applications (or application components) that are outside that sweet spot. Rob Walsh ___ 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 ARC
> On Sep 30, 2019, at 8:16 AM, Robert Walsh via Cocoa-dev > wrote: > > however, to use it to do anything other than building a desktop or IOS GUI > application seems to result in code with messy syntax and what seem to me to > be hacks in order to bridge between NS* and CG* code. (Lots of casts and > strange machinations for massaging pointers.) This is true when calling C code from any language that isn't based on C :) Bridging between different languages is not a simple thing (I've done a lot of it…) Take a look at how you call C code from Rust, Go, Java,Python, etc.; it's at least as complex. > Also, as you've said Swift makes cross-platform development nearly impossible > because, even though Swift itself is available on other platforms, the > pre-built components that prevent the developer from having to reinvent every > wheel from scratch are not. This is true, but getting less so. There's pretty good support for server-side Swift now, apparently. Both of these are complaints about the immaturity of the Swift libraries, not about the language itself, and the good thing is that libraries are much easier/faster to build than languages. —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
Alerts in Xcode 11
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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Alerts in Xcode 11
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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Alerts in Xcode 11
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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Thoughts on ARC
> Le 30 sept. 2019 à 17:16, Robert Walsh via Cocoa-dev > a écrit : > > > Swift may be the solution, but it's built on a weak foundation. It makes > cross-platform development almost impossible. The TIOBE index shows Swift > declining (and Objective-C increasing). So, maybe it isn't. > > I don't yet have a lot of experience with Swift, but I would already argue > that Swift is not the solution. Swift is cool and has some really neat > features that make for good presentations and blog posts (where the > real-world issues and constraints associated with interfacing to other > systems, particularly older ones that do not use HTTP, can be minimized or > eliminated entirely); however, to use it to do anything other than building a > desktop or IOS GUI application seems to result in code with messy syntax and > what seem to me to be hacks in order to bridge between NS* and CG* code. > (Lots of casts and strange machinations for massaging pointers.) I'm in the > process of converting an application written in C++ using an older version of > Qt because the Qt code relies on Carbon (which has been removed from > Catalina). The new code is in Swift. I've written and maintained code that > uses UNIX-style C sockets for many years, but finding a native approach for > plain sockets in Swift was very > difficult. There appears to be good support for async HTTP communication, > but not much for socket-based TCP. SwiftNIO is protocol agnostic, and let you manipulate any data stream as you like. Moreover, it is cross platform (unlike the lower level Network Framework, which is far superior to using unix socket IMHO, but can’t be use for cross platform dev). ___ 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 ARC
I have recently looked at utilising Swift to update an old Carbon based application. I stopped pursuing this path Swiftly, in part because of lack of good support for sockets and generally problematic use of CG* code. I tried a completely new approach - Electron. I have found Electron to be surprisingly quick to prototype, easy to bridge to c++, and is cross platform (non mobile at least). I would not have recommended a non-native approach until recently, but for what it is worth, I've come to realise this is one of the better options available these days. YMMV. Sam On Tue, 1 Oct 2019, 06:09 Jens Alfke via Cocoa-dev, < cocoa-dev@lists.apple.com> wrote: > > > > On Sep 30, 2019, at 8:16 AM, Robert Walsh via Cocoa-dev < > cocoa-dev@lists.apple.com> wrote: > > > > however, to use it to do anything other than building a desktop or IOS > GUI application seems to result in code with messy syntax and what seem to > me to be hacks in order to bridge between NS* and CG* code. (Lots of casts > and strange machinations for massaging pointers.) > > This is true when calling C code from any language that isn't based on C > :) Bridging between different languages is not a simple thing (I've done a > lot of it…) Take a look at how you call C code from Rust, Go, Java,Python, > etc.; it's at least as complex. > > > Also, as you've said Swift makes cross-platform development nearly > impossible because, even though Swift itself is available on other > platforms, the pre-built components that prevent the developer from having > to reinvent every wheel from scratch are not. > > This is true, but getting less so. There's pretty good support for > server-side Swift now, apparently. > > Both of these are complaints about the immaturity of the Swift libraries, > not about the language itself, and the good thing is that libraries are > much easier/faster to build than languages. > > —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/thesquib%40gmail.com > > This email sent to thesq...@gmail.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 ARC
> On Sep 30, 2019, at 4:57 PM, Sam Ryan wrote: > > I tried a completely new approach - Electron. I have found Electron to be > surprisingly quick to prototype, easy to bridge to c++, and is cross platform > (non mobile at least). I would not have recommended a non-native approach > until recently, but for what it is worth, I've come to realise this is one of > the better options available these days. YMMV. If you don't mind coding in JavaScript, don't care about Mac UI guidelines, and aren't shy about shipping a 200MB+ app that has an entire freakin' web browser embedded in it… (Sorry for the grumpiness. I'm just sick of all the "Mac apps" that are just Electron-based web pages, e.g. Slack.) —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 ARC
No apology necessary, I'm pained by the same problems as you mentioned! On Tue, 1 Oct 2019 at 14:00, Jens Alfke wrote: > > > On Sep 30, 2019, at 4:57 PM, Sam Ryan wrote: > > I tried a completely new approach - Electron. I have found Electron to be > surprisingly quick to prototype, easy to bridge to c++, and is cross > platform (non mobile at least). I would not have recommended a non-native > approach until recently, but for what it is worth, I've come to realise > this is one of the better options available these days. YMMV. > > > If you don't mind coding in JavaScript, don't care about Mac UI > guidelines, and aren't shy about shipping a 200MB+ app that has an entire > freakin' web browser embedded in it… > > (Sorry for the grumpiness. I'm just sick of all the "Mac apps" that are > just Electron-based web pages, e.g. Slack.) > > —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: Alerts in Xcode 11
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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Alerts in Xcode 11
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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
