Re: Thoughts on Cocoa source code

[조성빈 via Cocoa-dev]

> 2019. 10. 12. 오후 7:52, Jean-Daniel  작성:
> 
> 
>>> Le 12 oct. 2019 à 03:07, 조성빈 via Cocoa-dev  a 
>>> écrit :
>>> 
>>> 
>>> 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.
> 
> I’m not quite sure what your definition of complex is, but on my side, I 
> consider that an app that use hundred (if not thousand) of dependencies that 
> have to be review

To be optimal, all of the npm dependencies should be reviewed... but I’ve never 
seen a codebase that reviews all of its deps.
Mostly, if it is done, it’s usually the direct ones, and to be honest, it 
really doesn’t matter if you want to get things done. 

I’m pretty sure most Cocoa codebases don’t review its cocoapods deps as well.

> and properly managed to avoid conflict

I’ve never seen npm dependencies conflict. 

> and can disappear without notice and break your app,

After the left-pad fiasco, packages with dependents cannot be removed without 
npm’s consent.

> is a complex system.

___

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

[Jean-Daniel via Cocoa-dev]

> Le 12 oct. 2019 à 03:07, 조성빈 via Cocoa-dev  a 
> écrit :
> 
>> 
>> 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.

I’m not quite sure what your definition of complex is, but on my side, I 
consider that an app that use hundred (if not thousand) of dependencies that 
have to be review and properly managed to avoid conflict and can disappear 
without notice and break your app, is a complex system.

___

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

Re: Thoughts on Cocoa source code

[Stephane Sudre via Cocoa-dev]

On Wed, Oct 9, 2019 at 7:19 PM 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.

Cocoa source code is not really hidden if you use the proper tools and
know how to use them and that you should not rely 100% on them.

With Hopper Disassembler, you can see any Obj-C framework source code
in /System/Library/(Private)Frameworks.

Although most of the time you don't need to see the source code, there
are some areas that are poorly covered by the developer documentation
and being able to see the implementation details is very useful. For
instance, if you ever had to write a custom subclass of NSCell or a
subclass of NSControl with multiple cells, the official documentation
was almost totally useless and this was a good opportunity to find out
about the private API Apple was keeping to itself to make the AppKit
controls work.

It's true that having access to the source code can also help finding
issues and suggesting patches. But it's also true that if Apple had
been doing a proper job at checking the warnings and static analysis
outputs of its own IDE, numerous issues could have been fixed without
having needed to be reported by 3rd party developers.

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

https://www.hopperapp.com

http://stevenygard.com/projects/class-dump/

Checking cocotron can also be helpful if you want to see how someone
else implemented most Foundation and AppKit legacy APIs.
___

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

[Jean-Daniel via Cocoa-dev]

> 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

[Jens Alfke via Cocoa-dev]

> 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

[Saagar Jha via Cocoa-dev]

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

[Alan Snyder via Cocoa-dev]

> 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

[Richard Charles via Cocoa-dev]

> 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

[Aandi Inston via Cocoa-dev]

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

[Pier Bover via Cocoa-dev]

> 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

[Richard Charles via Cocoa-dev]

> 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 via Cocoa-dev]

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

[Jens Alfke via Cocoa-dev]

> 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

[Ben Kennedy via Cocoa-dev]

> 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