Re: Thoughts on Cocoa source code
Re: Thoughts on Cocoa source code
- Subject: Re: Thoughts on Cocoa source code
- From: Turtle Creek Software via Cocoa-dev <email@hidden>
- Date: Fri, 11 Oct 2019 13:09:58 -0400
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 <email@hidden>
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 <email@hidden>
> wrote:
> >
> > For Mac and SwiftUI, you can even write “no” code to do some things with
> bindings.
>
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden