Re: Thoughts on Cocoa

> On Oct 11, 2019, at 11:17 PM, Charles Srstka via Cocoa-dev > wrote: > >> On Oct 11, 2019, at 5:29 PM, tblenko--- via Cocoa-dev >> wrote: >> 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

Re: Thoughts on Cocoa

—Jens > On Oct 11, 2019, at 3:32 PM, tblenko--- via Cocoa-dev > wrote: > > 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

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

> On Oct 11, 2019, at 5:29 PM, tblenko--- via Cocoa-dev > wrote: > > Me, I still don’t understand why, given the long history of support at > Apple/NeXT for C++ …what? > and the maturity of the compilers available, there is any need for Swift. But > there it is. Or, there they are. Perhaps

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

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

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

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

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

> 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

Re: Thoughts on Cocoa

> On Oct 10, 2019, at 5:20 PM, Charles Srstka via Cocoa-dev > wrote: > > Yes, they marketed Carbon as a first-class citizen, promoted as “the basis > for all life,” and even rewrote the Finder and Dock—which already had Cocoa > implementations from NeXT—in Carbon just to prove that they were

Re: Thoughts on Cocoa

> On Oct 4, 2019, at 4:51 AM, Jeremy Hughes via Cocoa-dev > wrote: > > Hi Jens, > >> On 3 Oct 2019, at 20:04, Jens Alfke via Cocoa-dev > > wrote: >> >> The people I hear complaining about this are those who, like you, didn't >> move to Cocoa. Carbon was a

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

Re: Thoughts on Cocoa

> Le 5 oct. 2019 à 07:14, Pier Bover via Cocoa-dev > a écrit : > >> But once you get experienced with Cocoa and Objective-C, you can build > applications or rewrite them fairly quickly, IMHO. > Yeah but Objective-C is slowly being phased out. Someone from Apple already > said in a previous

Re: Thoughts on Cocoa

> But once you get experienced with Cocoa and Objective-C, you can build applications or rewrite them fairly quickly, IMHO. Yeah but Objective-C is slowly being phased out. Someone from Apple already said in a previous e-mail newer APIs are only available for Swift. As for Cocoa it seems like it

Re: Thoughts on Cocoa

> > On Oct 4, 2019, at 23:43, Michael Hall via Cocoa-dev > wrote: > > > >> On Oct 4, 2019, at 2:41 PM, Lars C. Hassing via Cocoa-dev >> wrote: >> >> >> On 4 Oct 2019, at 21.00, Jens Alfke wrote: >> >> The people I hear complaining about this are those who, like you, didn't >> move to

Re: Thoughts on Cocoa

> On Oct 4, 2019, at 2:41 PM, Lars C. Hassing via Cocoa-dev > wrote: > > > On 4 Oct 2019, at 21.00, Jens Alfke wrote: > > The people I hear complaining about this are those who, like you, didn't move > to Cocoa. Carbon was a _temporary_ transition API*. It was necessary when Mac > OS X

Re: Thoughts on Cocoa

> On Oct 4, 2019, at 12:41 PM, Lars C. Hassing via Cocoa-dev > wrote: > > "Apple is committed to the HIViews, Carbon events, and nib files for Carbon > implementations of the user interface. >All new controls and other features will be based on HIView. >If you want your application

Re: Thoughts on Cocoa

On 4 Oct 2019, at 21.00, Jens Alfke wrote: The people I hear complaining about this are those who, like you, didn't move to Cocoa. Carbon was a _temporary_ transition API*. It was necessary when Mac OS X shipped in March 2001, but even though it wasn't yet formally deprecated, it was clear it

Re: Thoughts on Cocoa

>> If you’re finding it difficult in the various transitions going on, how about reaching out to another developer or group to get you over those hurdles? If only it were that simple. Cocoa wasn't just a few hurdles. More like a constant slog of small and medium-sized problems, with

Re: Thoughts on Cocoa

> On Oct 4, 2019, at 4:43 AM, Dragan Milić via Cocoa-dev > wrote: > > Apple also strongly and clearly advised all new development should be done in > Yellow Box/Cocoa. Sure it took Apple too quite some time to transition > everything away from Carbon, but it was clear from the beginning that

Re: Thoughts on Cocoa

> On 4 Oct 2019, at 11:43, Dragan Milić via Cocoa-dev > wrote: > >> pet 04.10. 2019., at 11.51, Jeremy Hughes via Cocoa-dev wrote: >> >> It wasn’t clear to us (outside Apple) that Carbon was a temporary API until >> 2007, when Apple suddenly abandoned 64-bit Carbon. > > I don’t agree. Maybe

Re: Thoughts on Cocoa

> pet 04.10. 2019., at 11.51, Jeremy Hughes via Cocoa-dev wrote: > > It wasn’t clear to us (outside Apple) that Carbon was a temporary API until > 2007, when Apple suddenly abandoned 64-bit Carbon. I don’t agree. The first version of macOS predecessor (Rhapsody) shipped only with “Yellow Box”

Re: Thoughts on Cocoa

Hi Jens, > On 3 Oct 2019, at 20:04, Jens Alfke via Cocoa-dev > wrote: > > The people I hear complaining about this are those who, like you, didn't move > to Cocoa. Carbon was a _temporary_ transition API*. It wasn’t clear to us (outside Apple) that Carbon was a temporary API until 2007,

Re: Thoughts on Cocoa

I stirred up some conflict on this list. It may be because of readership differences. If you work for Apple or a big corp, then technical answers is what you can offer or desire. The big picture is someone else's worry. When programming tools change, it's just job security. For a small

Re: Thoughts on Cocoa

> On Oct 2, 2019, at 10:14 AM, Turtle Creek Software via Cocoa-dev > wrote: > > For > anyone smaller, it's hard to justify the constant need to rewrite code just > to stay in the same place. Return on investment is just not there. Seems > like each new update is more difficult. The people I

Re: Thoughts on Cocoa

If... ... the new platform-specific APIs are just that: platform-specific; ... there’s a way to integrate Swift code in Objective-C apps (and, I presume, Objective-C++ too); ... the most common complaint is about keeping code cross-platform; Then what is the problem with new,

Re: Thoughts on Cocoa

> čet 03.10.2019., at 10.53, Matthew Kozak via Cocoa-dev wrote: > > Well, actually: > http://www.eat-more-burgers.com/blog/drugstore-burger > (couldn't resist). > > Maybe more like going to a drug's manufacturing plant to complain about your > PBM (pharmacy benefits manager), but yeah. Touché!

Re: Thoughts on Cocoa

via Cocoa-dev Sent: Thursday, October 3, 2019 4:43 AM To: Cocoa-dev Subject: Re: Thoughts on Cocoa > čet 03.10.2019., at 00.49, John Randolph via Cocoa-dev wrote: > > Speaking as a former moderator of this list, this thread is off-topic for > Cocoa-dev. This list is for TECHNICA

Re: Thoughts on Cocoa

> čet 03.10.2019., at 00.49, John Randolph via Cocoa-dev wrote: > > Speaking as a former moderator of this list, this thread is off-topic for > Cocoa-dev. This list is for TECHNICAL discussion and help. > Kindly take it to reddit or wherever else the denizens of > comp.sys.mac.advocacy ended

Re: Thoughts on Cocoa

Speaking as a former moderator of this list, this thread is off-topic for Cocoa-dev. This list is for TECHNICAL discussion and help. Kindly take it to reddit or wherever else the denizens of comp.sys.mac.advocacy ended up. -jcr ___ Cocoa-dev

Re: Thoughts on Cocoa

Well, hey, we here use Cocoa and are prepared for 64-bit as of the next couple of weeks. But that’s about basic changes in chip architecture and is understandable. I was more worried about any hints of leaving Obj-C behind, and I’m glad to hear that the Obj-C interface will continue to be

Re: Thoughts on Cocoa

You guys have had *YEARS* to get your code bases updated to more modern APIs and architectures. All this whining is bullshit. You've deferred and delayed those updates and despite constant warnings that 32-bit was being deprecated, you haven't updated. As a user of some apps, I'm pissed. As a

Re: Thoughts on Cocoa

On Wed, 02 Oct 2019 15:19:43 -0400, you wrote: >Don’t worry, ObjC UI is not being deprecated. There are new APIs in >Catalina that are Swift-only, but that does not and will not prevent you >from continuing to write ObjC applications that simply don’t use those >APIs. Apple may not (yet) be

Re: Thoughts on Cocoa

On Oct 2, 2019, at 1:15 PM, Sam Ryan via Cocoa-dev wrote: > > It has felt like the support is not there the > last few years, with much of the documentation "archived" and the new > documentation focused on Swift. While the text in the doc window shows me the Swift version I can always click

Re: Thoughts on Cocoa

It is good to know there is still solid support for Objective-C UI, thank you for the information John. It has felt like the support is not there the last few years, with much of the documentation "archived" and the new documentation focused on Swift. Presently, it is hard to justify native

Re: Thoughts on Cocoa

On 2 Oct 2019, at 15:03, Jeff Evans via Cocoa-dev wrote: Here’s another small developer’s perspective: Practica Musica has been around since 1987 in one form or another (originally in 68000 assembler!). We’ve sold a lot of Macs for Apple. The upcoming version 7 is still C++ with Objective-C

Re: Thoughts on Cocoa

Here’s another small developer’s perspective: Practica Musica has been around since 1987 in one form or another (originally in 68000 assembler!). We’ve sold a lot of Macs for Apple. The upcoming version 7 is still C++ with Objective-C where necessary for the UI. We refuse to use Swift,

Re: Thoughts on Cocoa

> On Oct 2, 2019, at 10:43 AM, Richard Charles via Cocoa-dev > wrote: > > >> On Oct 2, 2019, at 11:14 AM, Turtle Creek Software via Cocoa-dev >> wrote: >> >> Sadly, we just decided to abandon the Cocoa update for our app. > > Great historical overview from a small developers

Re: Thoughts on Cocoa

I much prefer the Microsoft approach here. I guess the lesson to be learned is to depend as less as possible on Apple or either be forced to go through all the frequent SDK and language changes. I'm planning on working on a desktop project and looking for solution to use Cocoa/Swift as less as

Re: Thoughts on Cocoa

agreed. i'm a small one person company with about ten of thousand customers, half mac half windows. wrote for mac first, carbon C++ ported to windows by porting CoreFoundation, then simulating Carbon APIs for everything else it's taken me YEARS to try to switch to Cocoa, and i'm still not

Re: Thoughts on Cocoa

> On Oct 2, 2019, at 11:14 AM, Turtle Creek Software via Cocoa-dev > wrote: > > Sadly, we just decided to abandon the Cocoa update for our app. Great historical overview from a small developers perspective. Perhaps you should send this email to Tim Cook. It might some attention. Just a