Reverse Engineering

[richmond62]

https://68kmla.org/bb/index.php?threads ... ard.38456/

Fix some of the mistakes SuperCard and LiveCode made in extending HyperCard's design

I would be interested to know what the 'mistakes' are.

closures aren't there yet

what is meant by 'closures'?

[tperry2x]

I think Uli probably means function closures.
Function closures, in a very simplied context, are like global variables in xTalk - but in C#

As far as mistakes of Supercard, the IDE needs redesigning somewhat - rather than having a disjointed edit and browse mode. If it could resemble the way OXT/OXT lite works - that would be cool.

My biggest wish is to see a Linux and Windows version too (as well as Intel x64 and Arm MacOS support), but that's a huge ask I think.

[FourthWorld]

As far as mistakes of Supercard, the IDE needs redesigning somewhat - rather than having a disjointed edit and browse mode. If it could resemble the way OXT/OXT lite works - that would be cool.

How long did you work with SuperCard?

Runtime editing has been there since SuperCard 1.0 first premiered in June of '89.

SuperEdit is very handy, a solution to many questions that come up with other xTalks for those times when you want to focus on layout and structure without feeling like you're sticking your fingers between fan blades, unencumbered my any running scripts.

But it's optional. Aside from a handful of resource management tasks (which in HC also required a separate program, ResEdit), you can pick whether you want to do layout and structural tasks in either SC's Runtime Editor or SuperEdit.

In fact, something I've always admired about SC"a Runtime Editor is that it's available in three configurations: by default its tools are accessed by a full menu set, but if you need the menu bar for you own app you can choose to have the RTE present itself in a single hierarchical menu, or with no menu but a vertical NeXT-like palette instead.

At some point in development with any xTalk, the nature of the work shifts from making your app inside of an IDE environment, to working in your app's environment and needing tools inside of that.

SC's uniquely configurable RTE embraces that shift boldly and cleanly.

My biggest wish is to see a Linux and Windows version too (as well as Intel x64 and Arm MacOS support), but that's a huge ask I think.

Linux was never a concern with that project, despite my attempts to get Mark Lucas excited about it.

As for Windows, oh the stories I could tell about Allegiant's ill-fated voyage to that port. Suffice to say that at this point it ain't ever happening.

[richmond62]

At some point in development with any xTalk, the nature of the work shifts from making your app inside of an IDE environment, to working in your app's environment and needing tools inside of that.

Possibly, some of the time.

Certainly over 23 years of working with MC/RR/LC/OXT I have always found whatever I require staying within the IDE.

Yes; certainly, with HyperCard, I did use ResEdit.

[OpenXTalkPaul]

Interesting read through, Uli's comments in that thread I think reveals some of the things he thinks were done 'wrong'. I agree with much of what he had to say. I bolded some for emphasis:

uliwitness
Jul 17, 2021
#20

So one approach I'm considering is having a GUI to create new "object templates" that define initial values for properties and a script. There would be script commands to create such "class objects" just like the "create" command, but it would make classes more concrete.

That sounds like Extension Builder Widgets

MetaCard (now LiveCode) does something vaguely similar, where certain parts of a stack are just objects on a card nobody will ever visit. Like, icons are just graphic objects in the current stack. Often people use bitmap graphic objects on a card in a second stack in the same stack file. On one hand I like the simplicity and flexibility of this, you can just use any graphic you can make with MetaCard and use it as an icon. On the other hand, it feels kind of janky to have a stack that is only there to hide icons and other resources from the user of a stack.

Hence why I haven't pulled the trigger on any one solution, because I might want to have icons and templates in a special section of the stack (like the resource fork was in HyperCard) with a special picker UI.

Some of the comments makes me think he should just come on over to our place and work on OXT with us, because he's talking about adding a lot of things that are already in OXT.

I will eventually add some sort of extension mechanism, and I will likely add some built-in commands for compatibility with common XCMDs like "palette", "addcolor" etc.

"Built-in commands for compatibility with common XCMDs" sounds a lot like the OXT engine and also HyperSim.

Stacksmith's current format actually is XML. Kind of like HTML, though structurally more like HyperCard's original file format. I'll likely keep this format, as it works well as "source code" for checking into version control and for archiving as you say. That said, performance for database-like use cases and distribution as a standalone will probably mean I'll also add a binary format one day.

That's pretty much exactly what I've been saying I'd like to have for a long time now, a GUI answer to 'script-only' stacks.

Regarding inheritance, I'm thinking about ways to allow inheriting more behaviors, but I doubt it will use classes. HyperTalk seems to be more of a prototype-based language (particularly with user properties like SuperCard and LiveCode have them), so it'll probably be more like the existing "start using" mechanism, but for more objects than just stacks.

Sounds a lot like 'Extension Widgets' to me

My biggest wish is to see a Linux and Windows version too (as well as Intel x64 and Arm MacOS support), but that's a huge ask I think.

Windows version is probably the bigger ask. Sound like he didn't compile AppleSilicon for the same reason I haven't tried to compile any of OXT for Apple Silicon (I don't have one).

Regarding M1, it should just compile, but I don't have one, so I didn't spend time on it yet, that's all.

[micmac]

At some point in development with any xTalk, the nature of the work shifts from making your app inside of an IDE environment, to working in your app's environment and needing tools inside of that.

SC's uniquely configurable RTE embraces that shift boldly and cleanly.

This was why I started the thread about "App and Data"
https://openxtalk.org/forum/viewtopic.php?t=1276

Mic