Re: Thoughts on Cocoa source code

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

Re: Thoughts on Cocoa source code

> 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

Re: Thoughts on Cocoa source code

> 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

Re: Thoughts on Cocoa source code

> 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

Re: Thoughts on Cocoa source code

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

Re: Thoughts on Cocoa source code

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

Re: Thoughts on Cocoa source code

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

Re: Thoughts on Cocoa source code

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

Re: Thoughts on Cocoa source code

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

Re: Thoughts on Cocoa source code

> 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

Re: Thoughts on Cocoa source code

> 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

Re: Thoughts on Cocoa source code

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

Re: Thoughts on Cocoa source code

> 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

Re: Thoughts on Cocoa source code

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

Re: Thoughts on Cocoa source code

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

Re: Thoughts on Cocoa source code

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

Re: Thoughts on Cocoa source code

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

Re: Thoughts on Cocoa source code

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,

Re: Thoughts on Cocoa source code

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.

Re: Thoughts on Cocoa source code

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

Re: Thoughts on Cocoa source code

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

Re: Thoughts on Cocoa source code

> Le 10 oct. 2019 à 00:14, Jens Alfke via Cocoa-dev > a écrit : > > > >> On Oct 9, 2019, at 11:39 AM, Aandi Inston wrote: >> >> * But for whatever reason, I'm using the Mac OS 10.14 SDK. So that will get >> a compile-time warning. > > Only if you don't turn on -Werror, which I really,

Re: Thoughts on Cocoa source code

> On Oct 9, 2019, at 11:39 AM, Aandi Inston wrote: > > * But for whatever reason, I'm using the Mac OS 10.14 SDK. So that will get a > compile-time warning. Only if you don't turn on -Werror, which I really, really recommend everyone do. Calling a method that a class isn't declared as

Re: Thoughts on Cocoa source code

Nothing is statically linked. The version of the SDK you compile with is embedded into your application and Cocoa (and other Apple frameworks) consult this at runtime to determine appropriate behavior. Often this means you don’t get the new behavior, but sometimes Apple will automatically “opt

Re: Thoughts on Cocoa source code

> On Oct 9, 2019, at 10:41 AM, Jens Alfke via Cocoa-dev > wrote: > > You don't want to use the _implementation_ details! Those can and do change > completely over time There is a situation where I think it is fine to use the implementation details, and that is to work around a problem in

Re: Thoughts on Cocoa source code

> On Oct 9, 2019, at 11:58 AM, Pier Bover wrote: > > For example Imagix is a company that does image transformation in the cloud > and uses macs because of the high performance of CoreImage > (https://photos.imgix.com/racking-mac-pros) It's still more cost effective > for them to use

Re: Thoughts on Cocoa source code

" . Cocoa is part of the OS, and changes one very OS release. " This reminds me of a question which pops up for me every few years in development. I can't call to mind the last specific details, but it will happen again. Let's create an imaginary problem: * Apple add a new class behaviour to

Re: Thoughts on Cocoa source code

> Perhaps Apple does not want to give away the Crown Jewels. Indeed. There is some stuff in there that AFAIK no one has been able to replicate. For example Imagix is a company that does image transformation in the cloud and uses macs because of the high performance of CoreImage (

Re: Thoughts on Cocoa source code

> On Oct 9, 2019, at 11:19 AM, Turtle Creek Software via Cocoa-dev > wrote: > > Why is Cocoa source code hidden? Because Apple does not want to expose Cocoa source source. It is proprietary software. > Many of the frustrations we had with the 64-bit update attempt were caused > by Cocoa's

Re: Thoughts on Cocoa source code

Saagar Jha > On Oct 9, 2019, at 10:19, Turtle Creek Software via Cocoa-dev > wrote: > > Why is Cocoa source code hidden? > > Many of the frustrations we had with the 64-bit update attempt were caused > by Cocoa's lack of visible source. It was a "black box" that often required >

Re: Thoughts on Cocoa source code

> On Oct 9, 2019, at 10:19 AM, Turtle Creek Software via Cocoa-dev > wrote: > > Why is Cocoa source code hidden? So, take this as opinions of someone who worked at Apple, on [among other things] Mac OS X apps from 2000-2007. (a) It's part of Apple's crown jewels and seen as a competitive

Re: Thoughts on Cocoa source code

> On 09 Oct 2019, at 1:19 pm, Turtle Creek Software via Cocoa-dev > wrote: > > In fact, why isn't Cocoa open source? Apple open-sources Swift and the > Darwin kernel. Surely the GUI can't be any riskier to expose to developers? This is a business strategy question, not a Cocoa development