SuperCard 4.8 is here!

[Scott]

We are pleased to announce the release and immediate availability of SuperCard 4.8. This major upgrade adds dozens of new features, language additions, and interface tweaks.

In celebration of this long anticipated event, we're offering introductory pricing of 20% off both new licenses and upgrades! But don't wait too long… this offer expires May 31st.

For more information about SuperCard 4.8 please visit:

https://supercard.us/introducing-supercard-48.html

[james.coffey]

Is it 64 bit?

[Mike Yenco]

Congratulations! I know how much time you and Mark spent on this fantastic upgrade and overcoming so many hurdles that Apple erected along the way. Awesome to finally see this made available! All of my latest apps (Archive 8, Finance 8, and iKeeper 5) were created with SuperCard 4.8 and would not have been possible without all of your hard work and perseverance on this new version. I hope SuperCard 4.8 does really well and provides you with the necessary support to continue along the next path well into the future.

[catkeeper]

No, there are no 64-bit Carbon apps. Although when he introduced it Steve swore up and down that Carbon would remain a first-class citizen on the Mac platform in perpetuity (which is how he got us all to sign on and port our apps to it). Unfortunately though he was lying through his teeth.

So one miracle at a time...

-Mark

On Wednesday, May 23, 2018 at 2:40:33 PM UTC-4, james.coffey wrote:

Is it 64 bit?

[Alec Hole]

Congratulations!

[John Johnston]

Hi Scott,
Congratulations.

A no brainer with 20% off :-)

Cheers

John

> --
> You received this message because you are subscribed to the Google Groups "SuperCard Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to supercard-tal...@googlegroups.com.
> To post to this group, send email to superca...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/supercard-talk/72774534-c09d-4aa6-a2f6-bb299e491f05%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Bytehoven]

It sounds like a great improvement. Congratulations.

However, I cannot find anywhere in the documentation or on the website what are the minimum OS requirements. I'm still running El Capitan 10.11.6 and would like to know if SuperCard 4.8 will be compatible with my computer before I upgrade.

Thanks,

Chris Yavelow

[Scott]

Hey Chris...

You might want to sit down for this...   (c;

SYSTEM REQUIREMENTS: Universal Binary supports any Apple Macintosh running Mac OS 10.4 or higher. 

As is the SuperCard tradition, we have gone out of our way to maintain as much backward compatibility as possible, while keeping the upgrade process to newer versions painless.

[Anderson]

Congrats Scott and Mark!

The folks who have supported this upgrade through Beta testing deserve a thank you for those efforts. By the way, a lot of the 4.8 features like anti-aliased draw graphics work really well in OS Tiger. 

[codegreen]

LOL - yes, thanks to everyone who helped!

Of course you'd think if *I* can make plain old vanilla QuickDraw happily produce nice antialiased graphics even on such humble iron, *Apple* should've been able to too. But no...

I guess I just wanted it more.

;-)

-Mark

[Vince]

Well, it appears I have drawn the 'short straw" here… No easy way to tell you this, Mark, but…. Steve is dead.

lol ;)

Vince

[codegreen]

Yeah, so I've heard. Which sadly means I'm never gonna get to punch him in the face.

Unless of course there's an Apple Store in Hell, in which case he's goin' down...

;-)

-Mark

[Russell Martin]

So what happens to SuperCard (or any other Carbon apps) when Apple drops support for 32 bit apps?

[codegreen]

They stop working in those OS versions (duh), and you'll either have to choose which you need more at any given moment or else run them in some sort of virtualization environment (which nowadays is surprisingly fast, reliable, and in some cases even free).

Personally that would be a no-brainer (at least until the new Mac Pros come out, and have a year or two to drop to a reasonable price used) as I currently run decked-out mid-2010 cheese-graters (they're just as fast for what I use them for, FAR more flexible, and INSANELY cheap!) and only boot the dreaded High Sierra for testing SC in it. Otherwise to me it's just a HUUUUGE pain in the keister, and the machines that require it are of no practical value (to the point where if you gave me one it'd be up on eBay an hour later). But it probably won't be TOO long until Apple discontinues support for them too, at which point if they're not making something modular and relatively affordable they'll completely lose lots of 'pro-sumers' like us until they can figure out how to make machines worth buying again and an OS that doesn't cause migraines.

FWIW a LOT of work has already been done toward porting SC to Cocoa. Much of that is already in 4.8, which wherever possible has been migrating away from legacy Carbon APIs for most everything except chunk parsing and actually drawing on the screen (where mixing Carbon and Cocoa doesn't work reliably).

Unfortunately we can't just migrate directly to 64-bit Cocoa though unless we totally give up on the idea of SC5 being able to open existing projects, because they include legacy proprietary Apple data formats (such as PICT) that Apple couldn't be bothered even to provide shims for in 64-bit. So first I needed to cobble together a 'stepping-stone' version of SE in a weird hybrid of several legacy iterations of 32-bit Cocoa (which can suck in 4.x projects, edit them, and spit them out again in a new Cocoa-friendly bundled 5.0 project format).

However in the process to my dismay I discovered that in my dotage I apparently now need occasional sleep (sometimes as much as three or four hours a day! ;-) and so spending twelve hours a day working on the Carbon update and another twelve on the Cocoa port just wasn't working out, and I had to pick one or the other.

So here we are. If I were a salesman I would tell you what you obviously want to hear (i.e., that there will definitely be a 64-bit Cocoa version of SuperCard available before Apple pulls the plug on Carbon). But I'm not, so I'll just tell you the truth: I believe it's doable and I'm working on it, but between here and that land of milk and honey thar be dragons. So it'll be done when it's done, and I've had far too much bitter experience already with both Carbon AND Cocoa to promise more than that.

-Mark

[Alec Hole]

Mark-- your efforts are hugely appreciated. Can I just say, you deserve a lot more sleep!  

If I only had three hours sleep a night I probably wouldn't be able to switch my computer on, let alone write any working code ;-)

All the best,

Alec

[codegreen]

[Russell Martin]

On Thursday, May 24, 2018 at 11:25:35 AM UTC-6, codegreen wrote:

They stop working in those OS versions (duh), 

So, yes, my question was not well phrased because I meant to be asking what the path forward is, which you get to later in your reply...

FWIW a LOT of work has already been done toward porting SC to Cocoa. 

Carbon will be dead and Cocoa will be the only option at some point. Got it. Glad to hear that there might be a Cocoa-ized version of SC at some future date.

I could swear that I read something during the beta phase that indicated that you might be working on features to make it easier to submit SC apps to the Mac App Store? Am I just imagining this? If not, what is happening or has happened on that front? Thanks. :-)

[Scott]

We had a full working tool that took care of everything including the signing and packaging. Apple rendered it useless on 1/1/18 by no longer accepting 32 bit apps to the MAS.

[John Johnston]

> On 24 May 2018, at 18:25, 'codegreen' via SuperCard Discussion <superca...@googlegroups.com> wrote:
>
> So here we are. If I were a salesman I would tell you what you obviously want to hear (i.e., that there will definitely be a 64-bit Cocoa version of SuperCard available before Apple pulls the plug on Carbon). But I'm not, so I'll just tell you the truth: I believe it's doable and I'm working on it, but between here and that land of milk and honey thar be dragons. So it'll be done when it's done, and I've had far too much bitter experience already with both Carbon AND Cocoa to promise more than that.

And this is why one should take no more that a couple of seconds before deciding to upgrade. Great answer thanks.

Cheers

John

[ckuehne134]

>
> So here we are. If I were a salesman I would tell you what you obviously want to hear (i.e., that there will definitely be a 64-bit Cocoa version of SuperCard available before Apple pulls the plug on Carbon). But I'm not, so I'll just tell you the truth: I believe it's doable and I'm working on it, but between here and that land of milk and honey thar be dragons. So it'll be done when it's done, and I've had far too much bitter experience already with both Carbon AND Cocoa to promise more than that.
>

So, to be clear, if we intend on updating to macOS 10.14 around September, then this version of SuperCard will not launch, and it would only be useful for about five months? And in that case, will the 64-bit version be a free update? I’m only asking because I’m not sure how many people will want to pay again for an app that will only work for them for five months. If you do plan on charging for it, I completely understand, it’s just something I would want to know before I pay for this current version. Thank you for all of your time and effort into this 4.8 release!

[Mike Yenco]

I don't think that Apple has officially said yet.  Perhaps at their next WWDC (June 4) they will make some announcement in their keynote.  Dropping 32-bit support definitely is coming at some point. Given that they are no longer accepting new 32-bit apps on the Mac App Store as of January 2018 and updated 32-bit apps to existing apps on the Mac App Store as of June 2018 I would think sooner rather than later, but we'll have to wait and see what Apple says.

[Scott]

Mike is right. While Apple has clearly gone out of their way to rattle the cages of developers, the only thing I have heard so far from "Apple" is that 10.14 will not run 32bit apps "without compromise". What does that even mean? Guessing they wuffed up that phrase in the same meeting that decided to use the word "courage" when removing headphone jacks from devices defined as being "part iPod".

It would be nice if Apple had more respect for their customers who may have dozens of little apps and utils that will never see a 64bit upgrade, and be a little clearer on this. I have quite a few I honestly can't live without. If 10.14 really cuts them off at the knees I won't be keen on upgrading. And if 10.14 surprises me by bringing something really compelling to the table (guessing not), I'll just have to run a virtual environment to support them.

But to better answer your question (instead of just ranting), there are a lot of IFs here, and if all of them turn out to be death for 32bit later this year, and you are of the sort to upgrade to the latest and greatest as soon as Apple debuts it, this upgrade may not be for you.

[codegreen]

Today out of curiosity I tried installing three popular virtualization apps in 10.13, and then setting up OS X 10.12.6 and SuperCard 4.8 in them.

First I installed Oracle VirtualBox 5.2. FWICT currently VirtualBox's principal virtue on the Mac Platform is that it's free. And like so much free software, sadly installation was a major pain in the ass. It took me four hours to get it up and running, another to figure out how to set the screen resolution, then less than one more to decide to delete it.

Raw script execution speed averaged between about fifty and ninety percent of native, but anything that drew to the screen (especially time-sensitive things like fades) became balky and jittery at best. Basically if you're not comfortable in the Terminal the odds you'll even get VB running Sierra are slim, and that you'll ever figure out how to change the screen resolution essentially nil. Supposedly setting up 10.13 is easier, but unfortunately the Sierra 10.12.4+ installers don't work in VB so you have to either track down or build an ISO image of a 10.12.0 - 10.12.3 installer (which you can no longer download from the App Store), run that, and then DL and run the 10.12.6 updater inside the box (and all of them are tortuously slow). So basically it's free and it works, but even with multiple cores and gobs of free RAM you probably won't like it much (assuming you can get it running at all).

Parallels has long been the virtualization leader on the Mac platform, and the night-and-day difference between installing it and VirtualBox immediately shows why. But although the guest OS renders much more smoothly and integration with the host is much tighter, the raw frame rate is actually significantly slower. However scripts that don't draw anything (and just chew on data) essentially run at or near native speed. 

Installing OS X on Parallels 13 is something of a hassle (since they clearly expect you'll be using this to host Windows on a Mac or vice-versa). To fine-tune things properly you'll need to download and install an additional Tools package (as with VMWare, but at least theirs is free). For the Mac versions of both, you currently can only adjust the guest's screen resolution via the Terminal (and god help you figuring out how).

The biggest surprise to me was VMWare Fusion 10. Given its long-standing dominance of this market (and the fact that until recently VMWare appeared to have all but abandoned it) I expected Parallels to dominate the competition, but in my experience this wasn't the case at all. Fusion's installation was a snap (especially since it alone of the three let me install a guest OS from a Mac Recovery partition on the host), screen redraws were buttery-smooth, screen redraw rate (though still only half of native) averaged slightly higher than in Parallels, and raw script execution took hardly any noticeable performance hit (some memory-intensive scripts even ran slightly FASTER than they did natively in 10.13!).

Unfortunately neither VMWare nor Parallels (YET) supports the nifty new mode that lets Windows apps integrate directly into the window layering for OS X guests, so hosted Mac apps all still live in one window with its own Desktop and Menu Bar. But with acceptable refresh rates even for 1080p size windows, near-real time script execution, bi-directional Clipboard and Drag-n-Drop, auto-capture of the Magic Mouse and keyboard, and the ability to suspend or resume a guest session in just seconds, both Fusion and Parallels seemed totally acceptable working environments (at least for hosting SuperCard anyway). Both average in the range of $70 - $80, and have full-featured free trial versions.

So it may never matter when it comes to SC, but FWIW it's nice to know there are viable and affordable alternatives to having to just go Cold Turkey on our stashes of beloved 32-bit apps when Apple gets tired of living up to its promise to support them...

HTH,

-Mark

[Bytehoven]

Thanks Scott,

Maintaining backward compatibility is an excellent policy. Looking forward to it. I just upgraded.

I asked because I've been burned by a couple apps whose upgrades required Sierra. That said, my 10.33-year-old Mac Pro with its myriad hardware modifications will probably be forced into retirement before the end of this year.

Keep up the great work!

Thanks again,

Chris

[Scott]

On Wednesday, May 30, 2018 at 8:55:27 AM UTC-7, Bytehoven wrote:

my 10.33-year-old Mac Pro with its myriad hardware modifications will probably be forced into retirement before the end of this year.

LOL. I just bought an ol' Mac Pro (4,1). Knowing I didn't really have a viable replacement on hand should our Snow Leopard server take a dump, and coming to the realization we won't see a real computer from Apple again for less than 10 grand, it seemed a no brainer.

[Mike Yenco]

I agree... up to a point. I am a bit concerned about the impact of maintaining such compatibility over such a large number of macOS upgrades though. One has to wonder how many hours, days, weeks, or months Mark might have spent fixing something to maintain that support for older versions, or conversely, how many hours, days, weeks, or months Mark had to toil over the code in order to resolve issues with something newer ONLY because easier and faster fixes would have required dropping some of that older support. Don't get me wrong, that range of support is extremely impressive and a true testament to Mark's incredible skills, but I have to ask where we might be today if that length of backward compatibility was maybe shortened a bit. If Mark were free of most, if not all, of the shackles of backward compatibility, would updates happen at a faster pace? Would we be further along in the migration to Cocoa SuperCard? Would we be at 64-bit support already? Would Mark be able to use the latest version of Xcode to take advantage of anything that Apple has put there to make things easier for developers?

Part of me wants to say, hey... we are "developers" using SuperCard... we are not just end users of some normal commercial single-use product.  Sure it would be work for "us", but could we not open our existing projects in SuperCard 4.8 and open some new tool that maybe isn't backward compatible with SuperCard 4.8 but shares the same spirit and some of the same syntax as SuperCard, learn about those changes and manually port over our projects if that frees Mark up from another year or two of trying to provide a migration path and instead let's him focus on embracing the latest and greatest that macOS has to offer? I see that Apple has changed parts of Swift syntax without hesitation... developers just have to learn the new way of doing things and adapt.

Or maybe there is some other middle ground. I don't know.  It just seems to me that at some level that long backward compatibility and holding on to certain features of SuperCard might be more of a liability than an asset. I'd like to see a LOT more people excited about creating amazing new apps with no compromises in the latest and greatest versions of macOS.  Some energy and enthusiasm to attract more new people to SuperCard (or some new tool in the spirit of SuperCard) as a tool-of-choice for app development and a way for that tool to grow and change at a faster pace. More apps created with this made available on the App Store.

[Terence Heaford]

I for one would have preferred to go from 4.73 directly to 5(Cocoa/64bit?). I am waiting to see the lay of the land/timing from Apples perspective with regard to the dumping of 32bit before I consider upgrading SC.

I only have one computer and that is running High Sierra. I did go back to Sierra after initial disappointment but have now settled on High Sierra (still prefer Sierra). I am not interested in running SC in a virtual machine as 4.8 is slow enough.

I know Mark has been hard at work to get 4.8 to this state but for me there is insufficient to warrant my investing in the upgrade at the moment.
The performance of 4.8 when compared to 4.73 does appear inferior and this may be because of a mixture of Cocoa/Carbon code as Mark migrates areas of SC.

The time consuming stumbling block would appear to be WASTE. I assume removing the text engine and incorporating Cocoa is quite an exercise.

I will not give up on SC, as it is, in my opinion, better than LiveCode for Mac users (renting software is not for me), it’s just a shame it has taken so long to bite the modernise bullet.

I do agree with Mike that a sensible policy with regard to backward compatibility should be maintained. Where to draw the line is the difficult one but not modernising at a fast enough rate to attract new users and keep cutting edge users on board has to be a factor. Whether Mark & Scott have judged this correctly only time will tell.

With regard to Xcode 9.4, the latest version, you can compile externals that use the Cocoa frameworks, so a lot of things could be incorporated directly into SC or as an external. It’s the Cocoa user interface objects where the difficulty lies.

For example I just recompiled my THGraphics external (NSBezierPath) without problem. It’s not being able to have NSView to display things where the problem lies. Until SC dumps Carbon this will probably not change.
So in this example I have to return an image of the graphic to SC.

All the best

Terry

[parttimeprogrammer]

To me just the keyboard shortcuts in SuperEdit are worth the upgrade cost spread over several years. Let alone the plethora of new features. Thanks Mark!!

[Bill Bowling]

Thank you for time and effort for 4.81! 

Although my situation does not require an upgrade I'm pleased to have spent the money to make it worth while to the developers who have who are committed to SuperCard.

My only question is, do my date time handlers need to updated? I recall there was discussion or comments from beta that there were changes and scripts my need to changed to accommodate how SuperCard handles date and time.

Best Regards,

Bill

[codegreen]

LOL - it's nice to see I'm not the only SuperEdit junkie left here! To me it's the single best thing about SuperCard, but sadly few users even seem aware of its myriad benefits.

I always especially loved the ability to navigate around projects in SE using just the keyboard, but as they got bigger locating things started to become a bit of a wompus hunt. I find the new ability to also instantly tile (and restore) or optimize the open windows via a keyboard shortcut a godsend when I'm visually searching for something in (or just trying to get an overview of) a complex project.

And the guidelines are pretty cool too... ;-)

Thanks for noticing!

-Mark

[Mike Yenco]

Hi Bill,

As far as I can recall you shouldn't need to update your date and time handlers unless you were using the international format in SuperCard 4.7.  In 4.8 that needs to actually be changed to the international date, the international time, or the international date & the international time.

[codegreen]

On Thursday, May 31, 2018 at 12:43:23 PM UTC-4, Bill Bowling wrote:

Thank you for time and effort for 4.81! 

Although my situation does not require an upgrade I'm pleased to have spent the money to make it worth while to the developers who have who are committed to SuperCard.

Hi Bill,

Thanks, we appreciate your support!

I think you'll find (once you get used to them) that just the language-related enhancements alone are worth the upgrade price (allowing you to write MUCH more compact and expressive code).

As noted there's also a bunch of stuff related to date and number format localization that either now 'just works' again (after being AWOL since Apple broke the legacy Carbon APIs underlying the old implementations) or offers enhanced capabilities.

So whether you need to update your date and time handlers depends on what they do, where they're running, and what behavior you were expecting...

Can you explain a bit more about that (or post some code)?

-Mark

[Mike Yenco]

I love SuperEdit. I've always favored that for any design and layout interface work so I can jump right to a particular point in a project without having to go through a bunch of other interface to get there or risk clicking a control and having it run and cause problems because I'm not done scripting it yet (although a bit annoying not to be able to change the starting default state of certain controls in the interface from within SuperEdit like checkboxes or radio buttons). I also love SuperEdit for scripting work (it is so awesome to have multiple script windows open to compare against each other or to follow all the places where I reference some global to make sure I'm using the correct name across everything and can keep track of what I'm expecting to see placed into it from one script to the next)... and again, being able to just jump to some particular script in ANY part of my project without having to run through other parts just to get there.  SuperEdit gained even more importance for me when I started working on apps for the Mac App Store (which can't be self modifying). The easiest way to ensure the projects are working properly is to set their cantModify to true.  This pretty much rules out using SuperCard to change things unless I temporarily change that back, but then I'm altering the initial states of various controls and such and would either have to write a bunch of cleanup code to handle that or manually change things back (what a hassle).  Far easier to open the project in SuperEdit, work on it there, select Run to test something out, and then if anything breaks or I need to make some change just quitting to drop right back into SuperEdit to fix things.  The improvements to SuperEdit in 4.8 are all awesome (although I'm not sure I necessarily use every one of its myriad benefits)...  sometimes it is the simple things though... like being able to finally use the trackpad to scroll through the available fonts in 4.8 font selection dialog with a swipe rather than having to actually click on a scroll bar arrow or click and drag.  Especially when I have a bunch of font changes to make over a large number of objects and I'm going to be using this dialog many times in a row.

[codegreen]

On Thursday, May 31, 2018 at 2:08:46 PM UTC-4, Mike Yenco wrote:

The improvements to SuperEdit in 4.8 are all awesome (although I'm not sure I necessarily use every one of its myriad benefits)...  sometimes it is the simple things though... like being able to finally use the trackpad to scroll through the available fonts in 4.8 font selection dialog with a swipe rather than having to actually click on a scroll bar arrow or click and drag.  Especially when I have a bunch of font changes to make over a large number of objects and I'm going to be using this dialog many times in a row.

Dunno if you noticed but now you can also type a string of letters (NOT numbers) in that dialog, and rather than (as in previous releases) overwriting the contents of the editable size field instead SE will now select the first available font whose name begins with it.

HTH,

-Mark

[Mike Yenco]

As with most things, I noticed that feature was there immediately AFTER I had just gone through a bunch of objects that needed a font change.

[codegreen]

On Thursday, May 31, 2018 at 2:08:46 PM UTC-4, Mike Yenco wrote:

although a bit annoying not to be able to change the starting default state of certain controls in the interface from within SuperEdit like checkboxes or radio buttons

Generally when a control's min/current/max values aren't editable in SE, it's because either (as with checkboxes) they're never actually consulted when building the control, because (as with radio btns) their meaning depends on the state of another control flag or flags not accessible in the dialog, or because (as with bevel btns) the corresponding Toolbox control is notoriously high-strung and it's easy to hopelessly hose it (and even crash the host app) by setting those values incorrectly.

In the case of checkboxes and radio btns their hilited state is actually determined by the internal ishilited bit of the spot's flags, which for historical reasons there's never been a way to set directly in SE.

So basically it should be fairly straightforward (although non-trivial) to add a checkbox for this bit in the dialogs of controls to which it's relevant (or at least to those two common types anyway) and to enable/disable the value fields of radio btns based in part on the flag's setting (radio btns only consult their values when the ishilited flag bit is set and they also represent a multi-btn group).

If this sounds useful to you, please file a feature request.

-Mark 

[codegreen]

Hi Terry,

FWIW many factors contributed to the decision to pursue a final Carbon release instead of going directly to Cocoa, but a handful ended up tipping the scale: 

- The feature set of 4.7 was already seriously degrading (particularly in non-English locales) as Apple progressively broke underlying Carbon services

- At the time Apple seemed to have forgotten about its threat to kill Carbon

- I never dreamt it would take so long! But the tale grew in the telling, and Apple kept breaking more stuff... =:-O

- To be honest I don't much like programming in Cocoa/Obj-C, and absolutely ABHOR recent versions of Xcode (which to be too kind were obviously designed by people who didn't 'get' Macs, and cause blood-tinged steam to vent steadily from my nose and ears when I'm forced to use them). As someone who first learned to code in assembly language (on punch cards!), opaque data types make me ill. Yeah I get it, but I'll never learn to like it (not without the private headers anyway...).

- Until a putative Cocoa version is at least nearly done (which might never happen, I could get hit by a bus…) users couldn't benefit from (or help TEST) any of the new Cocoa based features or Cocoa fixes for these underlying Carbon regressions (or at least not in the context of an already feature-complete and fully usable release)

- As you're doubtless aware Cocoa isn't really optimized for humans to actually write UI code (which is a major pain where the sun don't shine) but rather to let them just draw their UI and have Interface Builder essentially write the code. But of course that only works when you already know what your UI should look like before you compile the program! Thus porting SC's project parsing and rendering code to Cocoa was a nasty uphill slog (and though admittedly not rocket science, I seriously doubt I could've managed it given any acceptable investment of time and tooth enamel without Uli's generous expert help and guidance). Most Cocoa books and docs barely touch on manually creating the required objects and most Cocoa programmers would hardly know where to begin. Call me a wimp, but (as with the Intel port) I wanted to break those twin nightmares out into a separate 'controlled environment' by porting SuperEdit first.

So between building an Ultimate Carbon Version of SC (with lots of the old Carbon guts replaced by modern Cocoa or Core Foundation APIs) and porting the project parsing and rendering code separately in SE, in effect by the time I officially 'started' on SC's Cocoa port I'd already be at least halfway done (and have a much clearer idea of where I was going). And better yet users would already be getting much of the benefit. Or instead we could've spent this time gradually losing many features and benefits of 4.7, and MAYBE a Cocoa version could've been ready if I'd worked on that exclusively (and somehow avoided just throwing up my hands in frustration and despair at the sheer magnitude and difficulty of the task) but I doubt it...

Some drawbacks of that approach are obvious, others less so. For example almost everything SC does is slower in Cocoa than in Carbon except where it can somehow be hardware-accelerated and/or parallelized. But since of course drawing is both where that mostly happens AND the biggest area where mixing the two frameworks doesn't really work, essentially everything in 4.8 that's been switched from Carbon to Cocoa also (despite aggressive optimization) runs noticeably slower as a result. And you might as well get used to it, 'cuz there's plenty more where that came from! At least in a native Cocoa app though you get a bunch of nice async eye candy to take your mind off it... ;-)

Anyway once you commit to make an app that doesn't support all the latest kit, suddenly backward compatibility hops a few rungs higher on your must-have list. As a result the landfills and back pages of eBay are chock-full of free or insanely cheap Macs that this version of SC will hum happily along on efficiently doing tons of useful stuff for you in a broad range of locales practically ad infinitum (which sadly is much less true of 4.7 due to ongoing erosion of its almost purely Carbon foundations). Plus there's a boatload of new cosmetic and convenience features that I would really find it tough to live without. And sadly given Apple's current direction it runs great on every version of OS X I'm ever likely to use voluntarily.

But if that doesn't mesh with your roadmap, I get it (really). In the end I just couldn't please everyone here - it's roughly a million lines of code all told and there's just one of me, so you do the math. And by all means wait for a full Cocoa version if you're not excited about all the cool new stuff in 4.8, and are confident SuperCard can survive until then without your support...

In the meantime at least you now have the option of a maxed-out Carbon release to tide you over while you dream of Cocoa heaven (which BTW for reasons too involved to litigate here I bet you will NOT like nearly as much as you seem to expect... ;-). That's less than ideal of course. Remember though that if they actually gave a damn Apple could probably keep OS X 32-bit support in perpetuity for much less than they spend just on coffee stirrers, and that at least over the near term it undoubtedly costs them far more to rip it out than to leave it in. But then you wouldn't have to toss your faithful old Mac in the trash every few years and replace it with something more annoying and less usable that can't be upgraded, repaired, or even easily recycled. However as long as they charge for hardware but not the OS, I guess that's how the game must be played...

-Mark

On Wednesday, May 30, 2018 at 3:11:07 PM UTC-4, theaford wrote:

[codegreen]

Wow, not sure why that came though lookin' so mugly! =:-O

It seemed perfectly normal when I clicked Post...

Sorry about that!

-Mark

[Mike Yenco]

Hi Mark,

Thanks. It could be useful (eventually), but right now it is pretty much a moot point.  Archive 8, Finance 8, and iKeeper 5 got into the Mac App Store just in time (at least to provide existing users with updates at long last, doesn't seem to be attracting much in the way of new sales [yet].). Today was the last day that Apple are supposedly accepting 32-bit app updates (and thankfully I didn't get any feedback from the existing users on my apps to suggest I needed to rush to get any +.1 updates to those out the door). That sort of puts everything into limbo for me.  I mean, I could work on adding new features or bug fixes (if anyone does find and report bugs) but as far as I know any such updates will be promptly rejected for not being 64-bit. As for the existing projects, well, I already did manually go into SuperCard, remove the cantModify, changed them to the initial state I wanted, saved, and put the cantModify back and only had minimal manual cleanup collateral changing of stuff to do.  Even with all that, it was mostly just for the visual for me so when I open the projects in SuperEdit I have that frame of reference right there for how this initial state of checkboxes and radio buttons are set without having to go dig through a script to see what the default preferences were set to.

If at some point we get to 64-bit and it requires me to recreate the interface for some reason or if the existing interface feels stale by then and needs to be created with a newer look, then, yeah, at that point I'll try to remember to file a feature request... of course, by then, who's to say if it will still be "fairly straightforward" or even anything remotely the same going on under-the-hood and there will probably be far more pressing concerns.

[codegreen]

It'll still be pretty straightforward (actually even more so) to do in Cocoa, but just as a practical matter if it's not in the Carbon version I started the port with (and that ship has long since sailed) and it's not in the feature request database, experience suggests that the odds it will end up in the final release are slim.

Just sayin'...

[Mike Yenco]

Ok, a feature request has just been submitted. Not a top priority to be sure, but it is there for consideration when it is even more straightforward in Cocoa.  Thanks Mark.