We set the main window controller as both delegate and data source for the
outline view. shouldSelectItem in the delegate handles clicks. For right
clicks, we had to add code in the view. It was pretty straightforward.
Apple has a sample project, but it's outdated and not very useful.
Casey
>> Apple has absolutely zero need to deliver a cross-OS-platform
Totally agreed. The issue isn't Apple vs Microsoft, it's iOS vs macOS.
>> If you're so absolutely set on cross-platform, leave the cross-platform
work to those who do that
We had a good 30-year run selling on both Mac & Windows:
Someone here suggested that I use an Apple DTS incident to ask about
Cocoa's future, so I filed one Nov 19th. Still no reply. Ditto for a dev
forum post, and an email to Aaron Hillegass.
Meanwhile, we've been thinking about what to say to Apple that might help
make our future app development
After a few days using the Apple developer forums, I would highly recommend
them. They get more traffic, and folks there seem to tolerate a much wider
range of opinions and discussions. In a forum you can just not click on
stuff you find boring, so maybe the format itself is less in-your-face
I have been poking around on developer.apple.com, trying to get the big
picture on the future of Cocoa for Mac. Ditto for the future of big apps.
Nothing explicit is said about it, but none of the public-facing pages
mention either Cocoa or Objective-C. It's all SwiftUI and Swift. Searches
still
Oops, I just noticed the search box for apple-dev.groups.io. It already
works pretty well.
I think this list should migrate there.
Casey McDermott
TurtleSoft.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin
I'd like to thank everyone who responded to my recent lengthy posts. We
really were in crisis for a bit, and writing it out helped. Hopefully some
of the thoughts helped other members. Many of the responses were helpful
for us. Right now I'm digesting it all, and trying to figure what to say
in
>> Maybe another list for meta or post-mortem discussions could be created ?
Reddit is a decent place for communities like this. You can have it in
your feed, or view threads when you feel like it. Here is what is already
applicable:
r/apple (mostly consumers, 1.2 million members)
r/cpp (C++
t does seem like a useful prognostication. Thanks for the
links!
Casey McDermott
TurtleSoft.com
On Thu, Nov 14, 2019 at 11:39 AM Gary L. Wade
wrote:
> On Nov 14, 2019, at 8:29 AM, Turtle Creek Software via Cocoa-dev <
> cocoa-dev@lists.apple.com> wrote:
>
> I think this gets
>> The longer you wait, the closer the train is to the edge of the cliff.
Correct. But what we have learned from many years with Apple is that some
of those cliffs disappear before you get close, or they just turn into
bumps. Waiting til 2014 rather than 2004 meant using much better versions
of
Yes, we use derez for the Windows app (still running in MS DOS!) It
flattens resources, but doesn't make them easy to parse or maintain.
Casey McDermott
TurtleSoft.com
On Thu, Nov 14, 2019 at 10:02 AM Glenn L. Austin
wrote:
> > On Nov 14, 2019, at 6:11 AM, Turtle Creek Software via Coc
>> >> Convert resources from ResEdit
>> DUDE. This is what, 20 years overdue?
Dude. Why would we change them before it was necessary? Don't fix it if
it ain't broke. There were better things to work on in the past 20 years.
We wrote code to go through each type of resource and convert them
14:38, Gary L. Wade via Cocoa-dev <
> cocoa-dev@lists.apple.com> wrote:
>
> If it takes you that long, then you need to hire new developers rather
> than wasting your time posting complaints on an email list.
> --
> Gary L. Wade
> http://www.garywade.com/
>
> On Nov 13, 20
I made a rather bold statement about Cocoa being doomed. Here's some
background on where it came from.
Apple and Microsoft are both working on next-generation app development
platforms, with the goal of having one dev library for desktop, tablet,
phone and anything else. Meanwhile, Mozilla also
-kosher would presumably avoid all that.
Casey McDermott
TurtleSoft.com
On Tue, Nov 12, 2019 at 3:00 PM Richard Charles
wrote:
>
> > On Nov 11, 2019, at 6:05 PM, Turtle Creek Software via Cocoa-dev <
> cocoa-dev@lists.apple.com> wrote:
> >
> > Unfortunately, software
I didn't mean to start a language war, because it's not about C++ vs
Objective-C or Swift. It's about whatever lets us create software that
runs on Macintosh and pays for the development cost. Right now, it only
makes sense to write an entire app in Objective-C or Swift if it's OK to
limit sales
>> Obj-C++ *is* a superset of C++, so I’m not sure what you’re wishing for.
In source files Obj-C++ works great. No complaints there. But headers and
method declarations are Obj-C, which is C plus its own additions.
That means no use of const. All pointers instead of & references. Both of
This is the last bit of post-mortem from our failure with Cocoa. Thanks for
the patience of everyone who just wants to give or get tech answers here.
I was originally going to post about how modern C++ has far surpassed
Objective-C. Then suggest that Cocoa would work better if Obj-C were a
>> One of the problems the Mac has is OLD crap software build on legacy
APIs, seeing the black & white Watch Icon makes me want to vomit.
>> I’m thankful Apple is prepared to force laggards, who want to keep Mac
software back in the last century, quit the platform.
Yep, they are very effective at
Moving as much as
possible from nibs to code solved a lot of problems.
Casey McDermott
TurtleSoft.com
On Thu, Oct 24, 2019 at 10:47 AM Richard Charles
wrote:
>
> > On Oct 24, 2019, at 7:04 AM, Turtle Creek Software via Cocoa-dev <
> cocoa-dev@lists.apple.com> wrote:
>
> >
TurtleSoft has shipped software built with 3 different programming tools:
Excel, HyperCard and CodeWarrior C++/PowerPlant. We started but abandoned
projects using 4 others: FileMaker, Omnis, Serius Developer and Think
Pascal/C++/TCL. There were another 6 app-development tools that we bought
and
>> For context: I work on a database library[1] implemented in C++ that
provides exactly such a C API
Diving down into C sounds like a reasonable option for a database library.
It does not sound good for a specialty app that does construction
estimating and accounting. Libraries just show
++ and can't be both. It turned out to be an enormous
barrier that caused all sorts of pains.
Casey McDermott
TurtleSoft.com
On Tue, Oct 15, 2019 at 12:20 PM Jens Alfke wrote:
>
> > On Oct 15, 2019, at 6:59 AM, Turtle Creek Software via Cocoa-dev <
> cocoa-dev@lists.a
This discussion about Swift vs Objective-C is interesting, but I think it
omits something important. Both those languages only build apps for Apple
products.
It's not such a big deal for iOS. iPhones are dominant enough that people
can write just for that. Phone/pad apps are also relatively
>> 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
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
n 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 execu
>> 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
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
>> 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
14 AM, Turtle Creek Software via Cocoa-dev <
> cocoa-dev@lists.apple.com> 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 mo
Sadly, we just decided to abandon the Cocoa update for our app. It's not
easy to walk away from 3 years of work, but better 3 years lost than 5.
Time will be better spent on our Windows version.
TurtleSoft started Mac-only with Excel templates in 1987. The first
prototype of our current
We used an object database called NeoAccess for our 32-bit C++ app. It had
reference counting for objects retrieved from the database. Setting the
ref count manually was extremely easy to screw up. It was hard to debug
off-by-ones on the ref count. So we made those calls private, and replaced
>> Is that view controller voiding its own self reference?
No.
>> Is it possible to switch out the view controller that i disappearing
with another one and see if that also disappears?
We've already wasted 2 weeks trying to debug this. It's time to move on.
We won't finish in time for
McDermott
On Tue, Sep 3, 2019 at 4:24 PM Jean-Daniel wrote:
>
> > Le 3 sept. 2019 à 02:33, Turtle Creek Software via Cocoa-dev <
> cocoa-dev@lists.apple.com> a écrit :
> >
> > Thanks for all the suggestions for the problems we had with a controller
> > being
&g
Thanks for all the suggestions for the problems we had with a controller
being
deallocated unexpectedly under ARC. Unfortunately, none of them fixed it.
We do need to get back to regular app programming, so it will just stay a
mystery.
I was hoping we were doing something obviously dumb, but I
There is an option in Build Settings, Apple Clang, to Compile Sources As.
That converts everything at once.
Previously I didn't notice Obj-C++ at the bottom. The C++ classes do build
and run OK with that selected.
Using the hybrid forward declaration that Uli suggests, I converted one of
our C++
We are happy with the lifetime management in our C++ classes.
And C++ keeps improving. ARC doesn't go there and that is fine.
We tried QT early on, but decided against it.
Casey McDermott
TurtleSoft.com
On Tue, Aug 27, 2019 at 2:35 PM Jens Alfke wrote:
>
>
> On Aug 26, 2019, at 6:22 PM,
>> Again, why does cross-platform code need to have references to
platform-specific view/controller types?
There are links between each Cocoa control class and its matching C++
control (which also owns a native MFC control).
Also links between the view and our C++ controller, to load window
at 2:47 PM Jens Alfke wrote:
>
>
> On Aug 25, 2019, at 5:49 PM, Turtle Creek Software via Cocoa-dev <
> cocoa-dev@lists.apple.com> wrote:
>
> No use of NSBridgingRetain or Release at all. Is that necessary under ARC?
>
>
> Those functions are only for casting C
>> @property (weak) GSOutlineWindowController *mainWindowController;
>>self.mainWindowController = [[GSOutlineWindowController alloc]
initWithWindowNibName : @"GSOutlineWindowController"];
[self.mainWindowController showWindow : self];
Sadly, nothing changes after the syntax changes.
> Message: 2
> Date: Sun, 25 Aug 2019 20:43:54 +0200
> From: Uli Kusterer
> To: cocoa-dev@lists.apple.com
> Subject: Re: ARC
> Message-ID: <3c9673ab-990e-f019-1ff2-0722d2d9e...@gmx.net>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 8/24/2019 1:44
In GSAppDelegate.h
GSOutlineWindowController *mainWindowController;
In GSAppDelegate.mm
- (void) showOutlineWindow
{
if (mainWindowController == NULL)
mainWindowController = [[GSOutlineWindowController alloc]
initWithWindowNibName : @"GSOutlineWindowController"];
Our app delegate class is not deallocated. The window controller is
deallocated
despite the member reference there. If we keep the second strong reference
to the controller,
then the outline view is deallocated instead. Nothing references the view
except being in the .xib file for the window
Sorry, it's a Mac app, written in Objective-C and C++.
We checked the Memory Graph and nothing seemed amiss.
On Fri, Aug 23, 2019 at 6:51 PM Alex Zavatone wrote:
> Casey, it it’s an iOS app, read up on strong and weak and use the
> storyboard to breat your first screen.
>
> Assuming it’s an iOS
45 matches
Mail list logo
