Re: Need for Swift

[Jens Alfke via Cocoa-dev]

> On Oct 11, 2019, at 8:10 PM, Kirk Kerekes via Cocoa-dev 
>  wrote:
> 
> I further infer that the perceived need arose due to the confluence of 
> aggravation over publicity over security bugs and the desire to develop 
> autonomous vehicle software. 

I don’t think so. Language people don’t develop languages for narrow reasons 
like that, and business people don’t respond to such issues by calling for a 
new programming language.

Swift has been in development since 2010, and what drove it, the people who 
originated say, was the need to go past the limits of what could be added to 
Objective-C.

> What they have ended up is a kind of disciplined, compiling Python — not 
> really a bad concept, given the goals.

I see Swift and Python as extremely different languages. Python is very 
dynamic, Swift is very static. Swift is a lot closer to Scala, C#, Go, and Rust.

—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

[Richard Charles via Cocoa-dev]

> On Oct 11, 2019, at 7:07 PM, 조성빈  wrote:
> 
>> 2019. 10. 12. 오전 9:55, Richard Charles via Cocoa-dev 
>>  작성:
>> 
>> None but the biggest of companies can do this.
> 
> That’s not true, web apps aren’t really complex if you get to use the npm 
> ecosystem. There are high quality libraries that do much of the heavy 
> lifting, so writing ones usually are wiring glue code between the libraries.

Multiple versions of an app possibly consisting of a browser base web app along 
with a high performance and convienent native desktop app (possibly native on 
Mac and Windows) and a native mobile app (possibly native on iOS and Android), 
a file based format for offline storage (native on Mac and Windows) and a cloud 
based format for online storage and colloraboration all working seamlessly 
together. Unless I am mistaken Adobe and Microsoft approach this with Creative 
Cloud and Office 360 apps.

None but the biggest of companies can to this.

--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: Need for Swift

[Alex Zavatone via Cocoa-dev]

> On Oct 11, 2019, at 10:09 PM, Kirk Kerekes via Cocoa-dev 
>  wrote:
> 
> I would not want to be at the mercy of a vehicle piloted by C++. 

In the immortal words that I have in an email from John Carmack, “Failure in 
brakes.dll."
___

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

Need for Swift

[Kirk Kerekes via Cocoa-dev]

> On Oct 11, 2019, at 7:55 PM, cocoa-dev-requ...@lists.apple.com wrote:
> 
> Me, I still don?t understand why, given the long history of support at 
> Apple/NeXT for C++ and the maturity of the compilers available, there is any 
> need for Swift. But there it is.

It is my inference that Swift arose out of a perceived need for a language that 
strongly  inhibited bad/lazy/sloppy programming practices, and yet looked 
“normal”. 

I further infer that the perceived need arose due to the confluence of 
aggravation over publicity over security bugs and the desire to develop 
autonomous vehicle software. 

What they have ended up is a kind of disciplined, compiling Python — not really 
a bad concept, given the goals. 

I would not want to be at the mercy of a vehicle piloted by C++.  Or 
Objective-C, for that matter. (And I happily use ObjC every day). 

Kirk Kerekes 
(iPhone)
___

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

[조성빈 via Cocoa-dev]

> 2019. 10. 12. 오전 9:55, Richard Charles via Cocoa-dev 
>  작성:
> 
> 
>> On Oct 11, 2019, at 1:14 PM, Turtle Creek Software via Cocoa-dev 
>>  wrote:
>> 
 I know this is the Cocoa devs list... but why not make a website?
 It would be easier to develop, completely crossplatform, no app store
 complications, you would be in total control of your stack, etc.
>> 
>> QuickBooks has gone that route.  They still grudgingly sell desktop apps,
>> but really push people towards their cloud version.  Besides all the
>> benefits you mention, it's a steady monthly income.  Hence why Microsoft
>> and Adobe are also going that route.  Apple too.
> 
> If I understand this correctly.
> 
> Microsoft Office Web apps (Word, Excel, PowerPoint) are simplified versions 
> of desktops apps that run in a web browser along with a subscription service.
> 
> Apple iWork web apps (Pages, Numbers, Keynote) are feature complete versions 
> of desktop and mobile apps that run in a web browser. Apple has never 
> released the details of how they do this.

Microsoft Office & Apple iWork web apps could be complex due to compatibility 
with the offline ones, and that they have a feature set that only has steadily 
expanded for a ten to twenty years.
They also need to have their app integrated with their other services.

> Adobe Creative Cloud apps (Lightroom and Photoshop) are native apps for 
> desktop and mobile with cloud based storage and a subscription service. They 
> are not cross-platform browser based web apps.
> 
> None but the biggest of companies can do this.

That’s not true, web apps aren’t really complex if you get to use the npm 
ecosystem. There are high quality libraries that do much of the heavy lifting, 
so writing ones usually are wiring glue code between the libraries.

> One alternative for native desktop apps is a Box Integration.
> 
> https://support.apple.com/en-us/HT207876
> 
> --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/pcr910303%40icloud.com
> 
> This email sent to pcr910...@icloud.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

[Richard Charles via Cocoa-dev]

> On Oct 11, 2019, at 1:14 PM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
>>> I know this is the Cocoa devs list... but why not make a website?
>>> It would be easier to develop, completely crossplatform, no app store
>>> complications, you would be in total control of your stack, etc.
> 
> QuickBooks has gone that route.  They still grudgingly sell desktop apps,
> but really push people towards their cloud version.  Besides all the
> benefits you mention, it's a steady monthly income.  Hence why Microsoft
> and Adobe are also going that route.  Apple too.

If I understand this correctly.

Microsoft Office Web apps (Word, Excel, PowerPoint) are simplified versions of 
desktops apps that run in a web browser along with a subscription service.

Apple iWork web apps (Pages, Numbers, Keynote) are feature complete versions of 
desktop and mobile apps that run in a web browser. Apple has never released the 
details of how they do this.

Adobe Creative Cloud apps (Lightroom and Photoshop) are native apps for desktop 
and mobile with cloud based storage and a subscription service. They are not 
cross-platform browser based web apps.

None but the biggest of companies can do this.

One alternative for native desktop apps is a Box Integration.

https://support.apple.com/en-us/HT207876

--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

[Gary L. Wade via Cocoa-dev]

The hard thing to make work best with NSComboBox is what to have its data 
source return when a user enters something not available in the list, so there 
is that decision to make, especially if your list is very sparse. You could 
also just use a pop up button that allows both mouse selection and text 
selection of a menu item when opened.
--
Gary L. Wade
http://www.garywade.com/

> On Oct 11, 2019, at 10:10 AM, Turtle Creek Software  
> wrote:
> 
> NSComboBox was almost perfect, but we needed it to only allow existing items.

___

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

[Richard Charles via Cocoa-dev]

> On Oct 11, 2019, at 4:46 PM, Jens Alfke  wrote:
> 
>> On Oct 11, 2019, at 12:22 PM, Richard Charles  wrote:
>> 
>> A second choice "Cross-platform Cocoa App" would be great for the small 
>> developer who’s focus is on business applications. All whole world doesn’t 
>> revolve around games.
> 
> https://developer.apple.com/xcode/swiftui/
> https://developer.apple.com/mac-catalyst/

What I meant to say was Cross-platform as in Microsoft Windows.

--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

[Jens Alfke via Cocoa-dev]

> On Oct 11, 2019, at 12:22 PM, Richard Charles  wrote:
> 
> A second choice "Cross-platform Cocoa App" would be great for the small 
> developer who’s focus is on business applications. All whole world doesn’t 
> revolve around games.

https://developer.apple.com/xcode/swiftui/
https://developer.apple.com/mac-catalyst/

—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

[tblenko--- via Cocoa-dev]

There’s a (short, I think) chapter missing from this story. I attended a public 
(technical) talk in Town Hall (I think it’s called) at Apple shortly before or 
after I went to work there. It would have been around 2000-2001.

The speaker’s message was that the future of the desktop was Java. A pretty big 
surprise and unwelcome news for those of us who saw Apple as the future of 
Objective-C and the NeXTStep lineage rather than the other way around. As the 
talk went on, it came out that the speaker was the manager of the compiler 
group responsible for Java and Objective-C — and had been going back to early 
NeXT days. So one had to conclude that he was committed to the course he 
described. People tried to ask about Objective-C (vs. Java) and he said that 
Objective-C was done, he clearly didn’t want to talk about that.

This before the public release of Mac OS X 10.0.

Another effort that sank in the deep blue sea.

I think one has to assume that technology strategy at Apple is less disciplined 
by the business side than at companies like IBM, Microsoft, Intel, Oracle, etc. 
And within Apple, there is a certain amount of chaos within Engineering that 
gets exposed from time to time. I think they might feel that’s a good thing. If 
you’re thinking like a business person, you should accept this as a given and 
make your decisions accordingly. If you’re thinking like a person who likes the 
technology, you may or may not reach the same conclusions. But I don’t think 
you’re going to change the way Apple does things.

Me, I still don’t understand why, given the long history of support at 
Apple/NeXT for C++ and the maturity of the compilers available, there is any 
need for Swift. But there it is. Or, there they are. Perhaps this is the way 
the younger generation overtthrows the older? Or not, but I’m pretty sure there 
is no compelling business argument for it.

Tom


> On Oct 11, 2019, at 2:54 PM, Charles Srstka via Cocoa-dev 
>  wrote:
> 
>> On Oct 11, 2019, at 12:44 AM, Jens Alfke  wrote:
>> 
>> 
>>> On Oct 10, 2019, at 6:18 PM, Richard Charles via Cocoa-dev 
>>>  wrote:
>>> 
>>> Just a guess but perhaps management had an awakening when they found the 
>>> time and effort expended to write the next even better version of Finder in 
>>> Carbon was substantially more difficult and costly that the prior Cocoa 
>>> version.
>> 
>> The only Cocoa—>Carbon Finder transition I know of was before 10.0 shipped. 
>> The development versions had a NeXT file manager with a Mac UI skin, but 
>> before release that was replaced with a Carbon-ized port of (a subset of) 
>> the MacOS 9 Finder. That Finder lived on for a few years before being 
>> replaced by a new rewritten Cocoa version.
>> 
>> —Jens
> 
> The NeXT/Rhapsody file manager was what I was referring to.
> 
> As for the 10.0 Finder, I’m sure it shared code with the OS 9 finder, but it 
> was an essentially new app based on PowerPlant (which the OS 9 Finder, to the 
> best of my knowledge, was not). It did not feel much like the OS 9 Finder, 
> and it was missing a lot of basic functionality that the OS 9 Finder had had, 
> much of which was gradually reintroduced over the years. The Cocoa rewrite of 
> the Finder did not appear until Snow Leopard was released in 2009. Notably, 
> the Finder was still Carbon when Apple suddenly out of nowhere (again, from 
> the perspective of an outsider) dropped the previously promised 64-bit Carbon 
> support in 2007.
> 
> As for the Dock, there was no OS 9 analogue to that at all, so the only 
> conclusion can be that it was rewritten in Carbon from the ground up, when a 
> Cocoa one had been previously available. This is difficult to explain other 
> than as a statement of confidence in Carbon.
> 
> 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/blenko%40martingalesystems.com
> 
> This email sent to ble...@martingalesystems.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

[Alex Zavatone via Cocoa-dev]

It does the useful thing on 10.15.  I just had to add some scene code to our 
iOS app that had availability indicators around the methods indicating to use 
them on iOS 13 and greater.

Sent from my iPhone

> On Oct 9, 2019, at 1:39 PM, Aandi Inston via Cocoa-dev 
>  wrote:
> 
> " . 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
> 
> 

Re: Thoughts on Cocoa source code

[Jean-Daniel via Cocoa-dev]

> Le 11 oct. 2019 à 16:59, Turtle Creek Software via Cocoa-dev 
>  a écrit :
> 
> I checked the GNUstep project, and it does seem decently clear and
> well-commented. If Apple made it possible to see and step through some of
> the basic Cocoa classes, that would be a good starting point.  The hard
> parts for us were NSView and its subclasses (especially NSTableView &
> associates, NSTabView and NSComboBox in that order).  The whole constraint
> system.  ARC.  Getting nibs to work properly when one little setting was
> wrong.


At least for ARC, it is fully open source.
The runtime part can be found in the objc4 project, and the compiler part come 
from clang, and is open source as well.

And knowing that, you will see that for such complex features, having them open 
source does not bring you many benefit to use them, as it is barely impossible 
to infer what the compiler optimiser pass will output by simply reading the 
source.

___

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

[Charles Srstka via Cocoa-dev]

> On Oct 11, 2019, at 12:44 AM, Jens Alfke  wrote:
> 
> 
>> On Oct 10, 2019, at 6:18 PM, Richard Charles via Cocoa-dev 
>>  wrote:
>> 
>> Just a guess but perhaps management had an awakening when they found the 
>> time and effort expended to write the next even better version of Finder in 
>> Carbon was substantially more difficult and costly that the prior Cocoa 
>> version.
> 
> The only Cocoa—>Carbon Finder transition I know of was before 10.0 shipped. 
> The development versions had a NeXT file manager with a Mac UI skin, but 
> before release that was replaced with a Carbon-ized port of (a subset of) the 
> MacOS 9 Finder. That Finder lived on for a few years before being replaced by 
> a new rewritten Cocoa version.
> 
> —Jens

The NeXT/Rhapsody file manager was what I was referring to.

As for the 10.0 Finder, I’m sure it shared code with the OS 9 finder, but it 
was an essentially new app based on PowerPlant (which the OS 9 Finder, to the 
best of my knowledge, was not). It did not feel much like the OS 9 Finder, and 
it was missing a lot of basic functionality that the OS 9 Finder had had, much 
of which was gradually reintroduced over the years. The Cocoa rewrite of the 
Finder did not appear until Snow Leopard was released in 2009. Notably, the 
Finder was still Carbon when Apple suddenly out of nowhere (again, from the 
perspective of an outsider) dropped the previously promised 64-bit Carbon 
support in 2007.

As for the Dock, there was no OS 9 analogue to that at all, so the only 
conclusion can be that it was rewritten in Carbon from the ground up, when a 
Cocoa one had been previously available. This is difficult to explain other 
than as a statement of confidence in Carbon.

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

[Richard Charles via Cocoa-dev]

> On Oct 11, 2019, at 11:21 AM, Jens Alfke via Cocoa-dev 
>  wrote:
> 
> What you can do is give them feedback about your specific experience, as 
> you're doing, and I hope that someone at Apple is reading this thread and 
> taking notice.

When creating a new project in Xcode one of the choices is Cross-platform. 
Under this tab the only choice available is "Cross-platform Game".

A second choice "Cross-platform Cocoa App" would be great for the small 
developer who’s focus is on business applications. All whole world doesn’t 
revolve around games.

--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

[Turtle Creek Software via Cocoa-dev]

>> I know this is the Cocoa devs list... but why not make a website?
>> It would be easier to develop, completely crossplatform, no app store
complications, you would be in total control of your stack, etc.

QuickBooks has gone that route.  They still grudgingly sell desktop apps,
but really push people towards their cloud version.  Besides all the
benefits you mention, it's a steady monthly income.  Hence why Microsoft
and Adobe are also going that route.  Apple too.

But, we're a small company, and it would involve hosting other people's
vital data.  Risk of outages, security breaches, compliance and privacy
issues. It would require much more skill to maintain. In a way we are
gambling on a huge breach happening to Intuit some day. Then suddenly we
look really, really good.

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: Thoughts on Cocoa source code

[Jens Alfke via Cocoa-dev]

> On Oct 11, 2019, at 6:18 AM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> Our time is best
> spent solving business-related problems.  Along the way we have learned
> many programming and human-interface skills, but the less time we need to
> spend on that, the better.

Totally reasonable. The ironic thing is that Cocoa is actually a lot easier to 
program in than Carbon (even with PowerPlant, I'd say.) But of course, any API 
you don't know is by definition harder to use than one you already know.

> If a programming environment requires zombies, disassemblers and other BS
> just to make it work, that is a big problem.

Cocoa doesn't. I've never needed to disassemble framework code since I left 
Apple. There are probably some situations when dealing with weird bugs or 
misbehaviors where it would be useful to do so, but it's not typical.

> I suspect that Cocoa source code is ancient C that is badly in need of a
> refactoring.

It's almost all Objective-C, actually. The C code is down in CoreFoundation. 
And that code gets refactored / rewritten as necessary, I'm sure — I know about 
major rewrites of NSView, NSTableView and NSTextView that occurred while I was 
still at Apple, and I'm sure there have been more since. It was very 
well-written code back then, and I'll bet it still is.

They've also done two complete redesigns — first UIKit, and now SwiftUI. You 
learn a lot when you rewrite something. SwiftUI in particular benefits from 
some big paradigm shifts (ugh) that have been happening in the field, like 
reactive programming.

> There probably are some parts of Cocoa that are extremely proprietary- but
> even then, plain old patents are better than hiding the code, as a way to
> protect the jewels. 

Not all this stuff is patentable, and patents are very expensive to file. Not 
having readily available source code to refer to raises the bar to entry.

I hope I won't offend you if I point out that as you are (as you freely admit) 
a small business that doesn't focus on CS or software engineering, you're not 
really in a position to give engineering or business advice to Apple. Apple has 
some of the best business and software people in the world, which is not to say 
that they don't make mistakes sometimes, but they generally have pretty good 
reasons for the way they do things. What you can do is give them feedback about 
your specific experience, as you're doing, and I hope that someone at Apple is 
reading this thread and taking notice.

—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

[Pier Bover via Cocoa-dev]

>
> Builders are mobile, and would love access to the accounting file in the
> office.   Those apps will each do just one thing (e.g. enter a purchase or
> check an estimate).


I know this is the Cocoa devs list... but why not make a website?

It would be easier to develop, completely crossplatform, no app store
complications, you would be in total control of your stack, etc.

On Fri, Oct 11, 2019 at 12:10 PM Turtle Creek Software via Cocoa-dev <
cocoa-dev@lists.apple.com> wrote:

> After we finish the Windows update, the plan is to write small phone/pad
> apps that will talk to it.  Builders are mobile, and would love access to
> the accounting file in the office.   Those apps will each do just one thing
> (e.g. enter a purchase or check an estimate). Swift and the current Cocoa
> will work great for those.  No need for any C++.  One screen or maybe a
> couple.  Not much interface. I don't know quite what the network technology
> will be yet, but phone-to-desktop will have advantages over pure
> cloud-based apps.  Cocoa and iOS seem strong at passing data over the
> Internet.  We'll do iOS first, then subcontract matching Android apps
> later.
>
> Desktop business apps are more complicated, and that's where Cocoa failed
> for us.  Cocoa probably is difficult for any code base that does something
> complex, and wants to be cross-platform for the model layer.  It would be
> insane for us to write payroll code in two different languages.  Not just
> the programmer time, it's also a lot of extra testing and debugging. Twice
> the maintenance, forever.
>
> At the beginning we assumed that the hard part would be learning
> Objective-C, and finding a way to link C++ to it.  Those were surprisingly
> easy.  Basic architecture also was easy.  Powerplant was pretty much just
> V, but we evolved into MVC very early on. There already are RecordViewer
> classes that act very much like a NSViewController, so we just link them.
>
> After 3 or 4 months the app was already starting to look and work like the
> current version. Then we discovered NSOutlineView and MFC's CTreeView, and
> designed a single-window setup that was much better than our current
> many-windows approach.  At that point we were extremely optimistic.
>
> Then began the long slog to get everything to actually work right.
> NSComboBox was almost perfect, but we needed it to only allow existing
> items. Apple docs said it was possible but we never got it to work, even
> with suggestions from this list. So it required a text field, popup and
> table view, with complex interactions between them.  Meanwhile CComboBox in
> MFC did it right with just a single parameter.  Our data entry tables have
> complicated interactions between cells. Trying to get them to work in a
> NSTableView burned up almost a year.  We finally gave up and changed the
> interface entirely.  Constraints were a constant hassle.  Looking ahead to
> how much detail still needs a rewrite was the last straw.  There are still
> about 40 windows currently made in MW Constructor that will each need a nib
> and controller.  At one week apiece for those, the horizon receded too far.
>
> Casey McDermott
> TurtleSoft.com
>
> On Fri, Oct 11, 2019 at 11:35 AM Gary L. Wade <
> garyw...@desisoftsystems.com>
> wrote:
>
> > Clarification: For long-time Mac and now available in SwiftUI, you can
> > even write “no” code to do some things with bindings.
> > --
> > Gary L. Wade
> > http://www.garywade.com/
> >
> > > On Oct 11, 2019, at 8:31 AM, Gary L. Wade <
> garyw...@desisoftsystems.com>
> > wrote:
> > >
> > > For Mac and SwiftUI, you can even write “no” code to do some things
> with
> > bindings.
> >
> >
> ___
>
> 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/pierbover11%40gmail.com
>
> This email sent to pierbove...@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 Cocoa source code

[Turtle Creek Software via Cocoa-dev]

After we finish the Windows update, the plan is to write small phone/pad
apps that will talk to it.  Builders are mobile, and would love access to
the accounting file in the office.   Those apps will each do just one thing
(e.g. enter a purchase or check an estimate). Swift and the current Cocoa
will work great for those.  No need for any C++.  One screen or maybe a
couple.  Not much interface. I don't know quite what the network technology
will be yet, but phone-to-desktop will have advantages over pure
cloud-based apps.  Cocoa and iOS seem strong at passing data over the
Internet.  We'll do iOS first, then subcontract matching Android apps later.

Desktop business apps are more complicated, and that's where Cocoa failed
for us.  Cocoa probably is difficult for any code base that does something
complex, and wants to be cross-platform for the model layer.  It would be
insane for us to write payroll code in two different languages.  Not just
the programmer time, it's also a lot of extra testing and debugging. Twice
the maintenance, forever.

At the beginning we assumed that the hard part would be learning
Objective-C, and finding a way to link C++ to it.  Those were surprisingly
easy.  Basic architecture also was easy.  Powerplant was pretty much just
V, but we evolved into MVC very early on. There already are RecordViewer
classes that act very much like a NSViewController, so we just link them.

After 3 or 4 months the app was already starting to look and work like the
current version. Then we discovered NSOutlineView and MFC's CTreeView, and
designed a single-window setup that was much better than our current
many-windows approach.  At that point we were extremely optimistic.

Then began the long slog to get everything to actually work right.
NSComboBox was almost perfect, but we needed it to only allow existing
items. Apple docs said it was possible but we never got it to work, even
with suggestions from this list. So it required a text field, popup and
table view, with complex interactions between them.  Meanwhile CComboBox in
MFC did it right with just a single parameter.  Our data entry tables have
complicated interactions between cells. Trying to get them to work in a
NSTableView burned up almost a year.  We finally gave up and changed the
interface entirely.  Constraints were a constant hassle.  Looking ahead to
how much detail still needs a rewrite was the last straw.  There are still
about 40 windows currently made in MW Constructor that will each need a nib
and controller.  At one week apiece for those, the horizon receded too far.

Casey McDermott
TurtleSoft.com

On Fri, Oct 11, 2019 at 11:35 AM Gary L. Wade 
wrote:

> Clarification: For long-time Mac and now available in SwiftUI, you can
> even write “no” code to do some things with bindings.
> --
> Gary L. Wade
> http://www.garywade.com/
>
> > On Oct 11, 2019, at 8:31 AM, Gary L. Wade 
> wrote:
> >
> > For Mac and SwiftUI, you can even write “no” code to do some things with
> bindings.
>
>
___

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: How to compile for macOS 10.11 ?

[Jens Alfke via Cocoa-dev]

> On Oct 11, 2019, at 1:36 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> But a customer tells me that it does not work under El Capitan on their 
> machine.
> It displays the message "This screen saver requires OS X 10.14".

If the alert is that specific, it sounds like your bundle has an Info.plist key 
specifying that it requires 10.14.
Otherwise you'd get a more generic alert about "failed to load" or "fatal 
exception" or something…

—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

[Gary L. Wade via Cocoa-dev]

Clarification: For long-time Mac and now available in SwiftUI, you can even 
write “no” code to do some things with bindings.
--
Gary L. Wade
http://www.garywade.com/

> On Oct 11, 2019, at 8:31 AM, Gary L. Wade  
> wrote:
> 
> For Mac and SwiftUI, you can even write “no” code to do some things with 
> bindings.

___

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

[Gary L. Wade via Cocoa-dev]

I’m one of the few on the list who has experienced every growing pain you’ve 
mentioned from 680x0 Macintosh now up to SwiftUI, and not only supporting a US 
English environment but even RTL UI (Arabic and Hebrew scripts) mixed with LTR 
languages across every current platform, and I will admit it’s hard.

The way I found Cocoa development to be easier was to change my way of 
thinking. In almost every case, it was better to completely separate the 
business logic from the UI handling logic. In other frameworks, the paradigm is 
to subclass a view; in Cocoa, everything is built to be as MVC as possible. Of 
course, there are exceptions, but if you find yourself wanting to subclass a 
view, think hard and look around—it might be better to compose a view of other 
views or there is a better, more Cocoa way of doing it. For Mac and SwiftUI, 
you can even write “no” code to do some things with bindings.

It’s possible to do a progressive port, but in many cases, you might find it 
easier to re-model (pun intended) your design.

True, the classes you mentioned are difficult, but I’ve seen many of their 
difficulties in thinking of them as a 1-1 replacement for comparable 
affordances in other frameworks or platforms.

Definitely use your tech support incidents, and if you find something not 
behaving as defined or not defined well, submit feedback to Apple and feel free 
to post those here. There’s also a site where you can voluntarily add your 
feedback requests to Apple, but I don’t recall it right now.
--
Gary L. Wade
http://www.garywade.com/

> On Oct 11, 2019, at 8:00 AM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> I checked the GNUstep project, and it does seem decently clear and
> well-commented. If Apple made it possible to see and step through some of
> the basic Cocoa classes, that would be a good starting point.  The hard
> parts for us were NSView and its subclasses (especially NSTableView &
> associates, NSTabView and NSComboBox in that order).  The whole constraint
> system.  ARC.  Getting nibs to work properly when one little setting was
> wrong.
> 
> In general, we weren't curious at all about the inner implementations of
> Cocoa.  The problems that held us back were in getting it to work for our
> app. Something is drawing solid black.  Why?
> 
> Rather than crown jewels, I think the best analogy for Cocoa should be an
> excavator or a backhoe. Some people run one full-time, but some pick it up
> from the rental place, and just want to get some stuff done over a
> weekend.  What's the best way to make it productive, quickly?  The
> long-time operators on this list know all the tricks, but Cocoa should also
> allow the rest of us to build apps relatively quickly. In our case, that
> means less than 3 years.
> 
> Casey McDermott
> TurtleSoft.com
> 
>> On Fri, Oct 11, 2019 at 9:47 AM Saagar Jha  wrote:
>> 
>> I’m sure much of the Cocoa code is quite old, but it’s mostly all
>> Objective-C. If you’re curious how it might work, but don’t want to use a
>> disassembler, the GNUstep project has a somewhat decent (though
>> incomplete) reimplementation  that
>> you can look at.
>> 
>> Saagar Jha
>> 
>> On Oct 11, 2019, at 06:18, Turtle Creek Software via Cocoa-dev <
>> cocoa-dev@lists.apple.com> wrote:
>> 
>> If you combine otool, classdump and Hopper Disassembler, you can find
>> 
>> how some Cocoa methods are working in any Obj-C executable pretty easily.
>> 
>> Here's the thing.  We started out as construction folks who learned Excel.
>> Then HyperTalk.  Then C++. As a business, our main strength is knowing the
>> construction business, and how to talk to folks in it. Our time is best
>> spent solving business-related problems.  Along the way we have learned
>> many programming and human-interface skills, but the less time we need to
>> spend on that, the better.
>> 
>> If a programming environment requires zombies, disassemblers and other BS
>> just to make it work, that is a big problem. It's too much extra overhead.
>> Our company can't afford it.
>> 
>> I'd agree that the documentation for Cocoa is deficient.
>> 
>> CodeWarrior included a huge Inside PowerPlant book, modeled on our
>> well-worn copies of Inside Macintosh. But we rarely used it.  Having
>> clearly-written source code and good comments is probably the best form of
>> documentation. Being able to step through it easily and see it in action is
>> a huge plus.
>> 
>> I suspect that Cocoa source code is ancient C that is badly in need of a
>> refactoring. Making it open, understandable and self-documenting would be a
>> great way to improve it.  Based on our refactoring experiences, it would
>> end up being faster, safer and less buggy.
>> 
>> There probably are some parts of Cocoa that are extremely proprietary- but
>> even then, plain old patents are better than hiding the code, as a way to
>> protect the jewels. Competitors can always disassemble, as you suggest.
>> 
>> Speaking of 

Re: Thoughts on Cocoa source code

[Turtle Creek Software via Cocoa-dev]

I checked the GNUstep project, and it does seem decently clear and
well-commented. If Apple made it possible to see and step through some of
the basic Cocoa classes, that would be a good starting point.  The hard
parts for us were NSView and its subclasses (especially NSTableView &
associates, NSTabView and NSComboBox in that order).  The whole constraint
system.  ARC.  Getting nibs to work properly when one little setting was
wrong.

In general, we weren't curious at all about the inner implementations of
Cocoa.  The problems that held us back were in getting it to work for our
app. Something is drawing solid black.  Why?

Rather than crown jewels, I think the best analogy for Cocoa should be an
excavator or a backhoe. Some people run one full-time, but some pick it up
from the rental place, and just want to get some stuff done over a
weekend.  What's the best way to make it productive, quickly?  The
long-time operators on this list know all the tricks, but Cocoa should also
allow the rest of us to build apps relatively quickly. In our case, that
means less than 3 years.

Casey McDermott
TurtleSoft.com

On Fri, Oct 11, 2019 at 9:47 AM Saagar Jha  wrote:

> I’m sure much of the Cocoa code is quite old, but it’s mostly all
> Objective-C. If you’re curious how it might work, but don’t want to use a
> disassembler, the GNUstep project has a somewhat decent (though
> incomplete) reimplementation  that
> you can look at.
>
> Saagar Jha
>
> On Oct 11, 2019, at 06:18, Turtle Creek Software via Cocoa-dev <
> cocoa-dev@lists.apple.com> wrote:
>
> If you combine otool, classdump and Hopper Disassembler, you can find
>
> how some Cocoa methods are working in any Obj-C executable pretty easily.
>
> Here's the thing.  We started out as construction folks who learned Excel.
> Then HyperTalk.  Then C++. As a business, our main strength is knowing the
> construction business, and how to talk to folks in it. Our time is best
> spent solving business-related problems.  Along the way we have learned
> many programming and human-interface skills, but the less time we need to
> spend on that, the better.
>
> If a programming environment requires zombies, disassemblers and other BS
> just to make it work, that is a big problem. It's too much extra overhead.
> Our company can't afford it.
>
> I'd agree that the documentation for Cocoa is deficient.
>
> CodeWarrior included a huge Inside PowerPlant book, modeled on our
> well-worn copies of Inside Macintosh. But we rarely used it.  Having
> clearly-written source code and good comments is probably the best form of
> documentation. Being able to step through it easily and see it in action is
> a huge plus.
>
> I suspect that Cocoa source code is ancient C that is badly in need of a
> refactoring. Making it open, understandable and self-documenting would be a
> great way to improve it.  Based on our refactoring experiences, it would
> end up being faster, safer and less buggy.
>
> There probably are some parts of Cocoa that are extremely proprietary- but
> even then, plain old patents are better than hiding the code, as a way to
> protect the jewels. Competitors can always disassemble, as you suggest.
>
> Speaking of early-Aughties history. We hired some subs to write the Windows
> version of our app. They took a short-cut and used QuickTime DLLs, though a
> lot still needed native MFC.  Metrowerks offered to buy it from us so they
> could make PowerPlant cross-platform.  Sadly, before we finished
> negotiations, Motorola did a re-org and our contact disappeared.  MW soon
> sold off their Intel compiler, just in time for Mac to switch chips. The
> rest is history.
>
> 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

[Saagar Jha via Cocoa-dev]

I’m sure much of the Cocoa code is quite old, but it’s mostly all Objective-C. 
If you’re curious how it might work, but don’t want to use a disassembler, the 
GNUstep project has a somewhat decent (though incomplete) reimplementation 
 that you can look at.

Saagar Jha

> On Oct 11, 2019, at 06:18, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
>>> If you combine otool, classdump and Hopper Disassembler, you can find
> how some Cocoa methods are working in any Obj-C executable pretty easily.
> 
> Here's the thing.  We started out as construction folks who learned Excel.
> Then HyperTalk.  Then C++. As a business, our main strength is knowing the
> construction business, and how to talk to folks in it. Our time is best
> spent solving business-related problems.  Along the way we have learned
> many programming and human-interface skills, but the less time we need to
> spend on that, the better.
> 
> If a programming environment requires zombies, disassemblers and other BS
> just to make it work, that is a big problem. It's too much extra overhead.
> Our company can't afford it.
> 
> I'd agree that the documentation for Cocoa is deficient.
> 
> CodeWarrior included a huge Inside PowerPlant book, modeled on our
> well-worn copies of Inside Macintosh. But we rarely used it.  Having
> clearly-written source code and good comments is probably the best form of
> documentation. Being able to step through it easily and see it in action is
> a huge plus.
> 
> I suspect that Cocoa source code is ancient C that is badly in need of a
> refactoring. Making it open, understandable and self-documenting would be a
> great way to improve it.  Based on our refactoring experiences, it would
> end up being faster, safer and less buggy.
> 
> There probably are some parts of Cocoa that are extremely proprietary- but
> even then, plain old patents are better than hiding the code, as a way to
> protect the jewels. Competitors can always disassemble, as you suggest.
> 
> Speaking of early-Aughties history. We hired some subs to write the Windows
> version of our app. They took a short-cut and used QuickTime DLLs, though a
> lot still needed native MFC.  Metrowerks offered to buy it from us so they
> could make PowerPlant cross-platform.  Sadly, before we finished
> negotiations, Motorola did a re-org and our contact disappeared.  MW soon
> sold off their Intel compiler, just in time for Mac to switch chips. The
> rest is history.
> 
> 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

[Turtle Creek Software via Cocoa-dev]

>> If you combine otool, classdump and Hopper Disassembler, you can find
how some Cocoa methods are working in any Obj-C executable pretty easily.

Here's the thing.  We started out as construction folks who learned Excel.
Then HyperTalk.  Then C++. As a business, our main strength is knowing the
construction business, and how to talk to folks in it. Our time is best
spent solving business-related problems.  Along the way we have learned
many programming and human-interface skills, but the less time we need to
spend on that, the better.

If a programming environment requires zombies, disassemblers and other BS
just to make it work, that is a big problem. It's too much extra overhead.
Our company can't afford it.

I'd agree that the documentation for Cocoa is deficient.

CodeWarrior included a huge Inside PowerPlant book, modeled on our
well-worn copies of Inside Macintosh. But we rarely used it.  Having
clearly-written source code and good comments is probably the best form of
documentation. Being able to step through it easily and see it in action is
a huge plus.

I suspect that Cocoa source code is ancient C that is badly in need of a
refactoring. Making it open, understandable and self-documenting would be a
great way to improve it.  Based on our refactoring experiences, it would
end up being faster, safer and less buggy.

There probably are some parts of Cocoa that are extremely proprietary- but
even then, plain old patents are better than hiding the code, as a way to
protect the jewels. Competitors can always disassemble, as you suggest.

Speaking of early-Aughties history. We hired some subs to write the Windows
version of our app. They took a short-cut and used QuickTime DLLs, though a
lot still needed native MFC.  Metrowerks offered to buy it from us so they
could make PowerPlant cross-platform.  Sadly, before we finished
negotiations, Motorola did a re-org and our contact disappeared.  MW soon
sold off their Intel compiler, just in time for Mac to switch chips. The
rest is history.

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

How to compile for macOS 10.11 ?

[Gabriel Zachmann via Cocoa-dev]

I have some code that works fine in macOS 10.14.
The only warnings I get during compilation are related to the GUI (about 
clipping and constraints and the like).

Now I would like to compile this for 10.11 (El Capitan).
Problem is, I only have one Macbook running 10.14

In Xcode, I switched the deployment target in the Project Info to 10.11 , and 
dito in the target's deployment target.
(why doesn't the target's deployment target follow the project's deployment 
target?)

There are just two places in the source code that I am guarding with
if ( @available(macOS 10.13, *) )

But a customer tells me that it does not work under El Capitan on their machine.
It displays the message "This screen saver requires OS X 10.14".

Am I missing something?
I would appreciate all kinds of hints.

If you would like to test drive my code:  
https://www.dropbox.com/s/t9sm2py7jhetyl3/ArtSaver.saver-Capitan.zip?dl=0

Thanks a lot in advance.

Best regards, Gabriel




smime.p7s
Description: S/MIME cryptographic signature
___

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