What I'm adding, and what I'm planning next...

[overclockedmind]

I'm the one that taught you that to add a button, give it a mouseUp event to quit, switch gears and "run" it, that the expected result was "total-bye-bye."

It could well be that the answer is in the screenshots of polls, or where the poll is now. I'd take that into consideration.

[tperry2x]

It could well be that the answer is in the screenshots of polls, or where the poll is now. I'd take that into consideration.

(screenshot taken)

polls-as-of-07-01-24.png (77.43 KiB) Viewed 3622 times

I'd concur. We are at a point where the engine needs attention IMHO.

[richmond62]

Well, that's all very well and jolly, but short of kidnapping the 'team' from Edinburgh and twisting their arms, or coming across a person who can do 2 things:

1. Slim the LC 963 Engine of all its redundancies, reduplications, cruft, and so forth.

2. Build engines for all the current OXT targets + MacOS ARM.

Or:

3. Do a major exercise in shifting all the IDE stuff 'over' to run on either another or a brand new engine.

We are stuck.

As I have suggested before . . . if we can have a version 1.0 we can start pitching it to punters and see if we can collect enough donations to hire someone to do 1,2 & 3 or combinations thereof.

There also should be some sort of thought put into a fund raiser that does NOT make us look like "some other people" who cannot keep promises: or, to put things another way: there should be no 'rewards' (beyond getting 1, 2 & 3 done) and no 'stretch marks' (err, stretch goal things) that will, almost inevitably, prove unobtainable inside any meaningful timeframe.

[tperry2x]

Well, that's all very well and jolly, but short of kidnapping the 'team' from Edinburgh and twisting their arms, or coming across a person who can...We are stuck

As much as I now have a mental picture of you traveling to Edinburgh, to throw a cloth bag over someone's head and drag them away (I'm joking of course, for anyone who might take that seriously), there are practical implications on how we might 'acquire' some talent in this area.

How much do LC pay their developer in charge of the ARM engine changes?
Aside from probably a better working environment, we can't match their yearly wage I'd bet. It's not as simple as that, as we then can't afford to keep them on year after year.

So, logically, any 'poaching' of talent - if you want to call it that, under someone's free will of wanting to contribute to the project, would have to come to us as an anonymous contribution. There are plenty of ways someone could do this, even if it were a text file uploaded via a decentralised tor link, so nobody could trace where the contribution came from - this would not even need to contain replacement code (see further down)

We wouldn't know their identity - so we'd not be withholding anything.

Of course, this probably leaves a bad taste in anyone's mouth at Livecode (and is totally hypocritical of me to say this, as I've been the one championing that people don't nick other people's code). I realise that, so before anyone takes offence - to clarify, what I'm actually suggesting is that we need to know just how involved adding an arm engine really is. And we really need to know this from the horse's-mouth so-to-speak: Was it just a case of updating a few libraries to add support, or do the changes run into the thousand+ lines of code?

Currently we have no clue.
Just a list - look at line x to y of file z, for example.

At least if we know if it was a quick process or not, we could then NOT COPY, STEAL, or otherwise in any capacity INFRINGE on LC's work, as the process for converting from intel to ARM is documented on Apple's website. It should be a matter of following these xCode changes - but we need to know if there were any specific gotchas.

If we know what we are changing, then we can make these changes in our own way, and not copy LCs work in any capacity.

THAT is what I'm suggesting, just to be clear, and that should not ruffle anyone's feathers?

And correct me if I am wrong, but from what I can make out, we'd need GYP to be functioning to be able to rebuild the engine? Surely this is the first port of call before we can look at engine changes - as GYP is the tool that in-turn builds the engine??

[richmond62]

And correct me if I am wrong

Very funny: I wouldn't know where to begin.

[tperry2x]

And correct me if I am wrong

Very funny: I wouldn't know where to begin.

Go for it, I'm sure someone will

[richmond62]

people don't nick other people's code

I do agree: one should NOT nick anyone's code: but one can 'nick' something insofar as one can copy someone's software package's functionality.

I have just sent the Document Foundation a quick 10 quid as they have mimicked the functionality of MicroSoft Office so successfully I don't have to pay quite a lot more to use that suite of tools. AND, I'm 100% sure the Document Foundation did NOT nick any of Microsoft's code, but they most certainly DID 'nick' (as in imitate) their functionality, and to a large extent, their interface.

Once, a long time ago, err, perhaps in about 1988, I visited a strange enclave of Spain totally surrounded by French territory, and went into a booze shop (lots of them there as no duty had to be paid on booze there) to see bottle of 'Johnny Wanker' whisky, and 'Garden's' gin. Now the manufacturers of those, no doubt 'fantastically revolting' drinks, were NOT doing anything legally wrong (perhaps you'd need to drink a couple of glasses of their muck before the moral angle would become clear), what they WERE doing was imitating 'Johnny Walker' and 'Gordon's' to the point just before where they would get in the shit, and hoping that most customers (French, Occitan, Catalan, Castilian: all suffering from both an alcoholic drouth and bad English spelling) would be fooled.

So: NO, we should NOT nick LC's MacOS ARM engine and reverse engineer it: plain Bad, Bad, Bad.

But we could, possibly, open it up with a text editor and do a compare-and-contrast exercise with the MacOS Intel engine: BUT, wait a mo': some "nasty little mind" (no, surely not?) at LC central had a thought (he thocht a qhile, scarted his dowp, belched and said "ah'll nae fash wi 'at" - except, of course, despite working inwith Scotland they are so Anglified [what a great vocable inventit by war makar, Robert Burns] they cannot even speak Scots) and made the engine a 'Fat' number for MacOS Intel & ARM all rolled into one, so that the likes of me cannot untangle the two.

Of course what we could do, is run off a MacOS ARM standalone for a one-card-one-button stack, and a MacOS Intel standalone for the same and THEN do some sort of compare-and-contrast . . . and, IFF it were to come about that the difference were nothing but a wee line of code, we could make a patcher to patch our MacOS Intel standalones so that they would function on MacOS ARM without Rosetta.

Just how aukward this would be I cannot tell: but I am tempted to use a sockpuppet email to download the latest and 'greatest' of the version 9 series of LC to see, and once I have builded 2 standalones . . .
-

Screenshot 2024-01-07 at 20.02.04.png (161.11 KiB) Viewed 3596 times

[tperry2x]

At least then, with this 'spot the difference' method, it might be clearer. Yes, after all - that's how many patches come about.
However, you mentioned something earlier I'd like to pick up on:

3. Do a major exercise in shifting all the IDE stuff 'over' to run on either another or a brand new engine.

The reason I was messing about with 10.4.10 was purely to test build targets for my zig code. (Compiled on my linux computer) and illustrates how you can easily make a PPC mac or even an arm mac version if all you have is an intel linux computer to hand.

(see the end of this post if anyone is bothered)
https://www.openxtalk.org/forum/viewtop ... 5544#p5544

The point of that? Because if we want to develop a new engine that owes nothing to anyone's work, then it's absolutely do-able. I've used ChatGPT to generate 90% of it.

If I can do it, I'm sure anyone can. Anyway, the point being that it's then a huge task bringing the entire language over and all the functions you might need, but at least then you have the bare-bones of an xtalk interpreter.

Nobody else seems to think this approach has legs, but I think it's a better bet than messing about with natifier (that does not turn out to be very 'native' as far as I can tell).

Again, correct me if I'm wrong

[tperry2x]

Experiments with VLC Audio / Video commands in linux:
https://www.openxtalk.org/forum/viewtop ... 5602#p5602
(could eventually be used to create a tsv file to replace [location of oxt lite]/Toolset/resources/supporting_files/property_definitions/com.livecode.interface.classic.Player.tsv)

[overclockedmind]

Experiments with VLC Audio / Video commands in linux:
https://www.openxtalk.org/forum/viewtop ... 5602#p5602
(could eventually be used to create a tsv file to replace [location of oxt lite]/Toolset/resources/supporting_files/property_definitions/com.livecode.interface.classic.Player.tsv)

I appreciate Linux anything, and it appears richmond does too. I bought a few new Macs and whatnot, but my heart lies with my sytem76 serv12, which is probably so mad at me for gaming on Win 10 that it'll never boot Linux again, simply out of spite.

[richmond62]

I've obviously got my socks on back-to-front this morning when attempting to get hold of a trial version of LC 9.6.11:
-

SShot 2024-01-09 at 12.26.39.png (41.22 KiB) Viewed 3532 times

[richmond62]

So: I would be very grateful if someone can get hold of an LC 9.6.11 trial and, with a stack consisting on a single card with a single, un-named button
hive off:

1. A Mac Intel standalone.

2. A Mac ARM standalone.

And make those 2 standalones publically available.

[tperry2x]

So: I would be very grateful if someone can get hold of an LC 9.6.11 trial and, with a stack consisting on a single card with a single, un-named button
hive off:

1. A Mac Intel standalone.

2. A Mac ARM standalone.

And make those 2 standalones publically available.

Here's the download link,
https://downloads.livecode.com/livecode/

I'll see if I get a chance this evening or tomorrow to do the other bit.

[richmond62]

Here's the download link

So it is (facetious remark): but without a Trial password its worth about as much as bikini top to a reticulated python.

Having used a sock puppet email account to sign up for an LC trial, and downloading 9.6.11, the thing will NOT work as my email acknowledgement will not "go through".

[Kdjanz]

So: I would be very grateful if someone can get hold of an LC 9.6.11 trial and, with a stack consisting on a single card with a single, un-named button
hive off:

1. A Mac Intel standalone.

2. A Mac ARM standalone.

And make those 2 standalones publically available.

I have done this. Send me your email and I will give you a link to Dropbox where you can download the binaries. I have 9 more days with 9.6.11 if you have more tests to be done.

kdjanz @ @ @ porta.ca

[tperry2x]

Going through the guides (Yes, I'm almost done), I notice there's places with lots of broken (missing) images on the Widgets section.

guides-oops.png (94.75 KiB) Viewed 3432 times

seriously.png (162.91 KiB) Viewed 3422 times

Rather than the hugely overly complicated method LC mention regarding updating their userguides, submitting changes to github (a moot point as that's been set as read-only, so can't be done anyway), I've ensured changing the userguides for anyone in my stack version is an easy process:

You can edit this "allguides" documentation stack quite easily. No coding is necessary.
Just shift-click the OXT logo at the top-left to enter edit mode.
You can do this on any page to get an idea of the syntax used.

We can easily add sections, and it's just a matter of updating the allguides stack as and when we see fit. You no longer need a degree in C++ or to be a whizz at github to do it.

edit-mode.png (211.93 KiB) Viewed 3432 times

By the way, if you don't like the purple selector colour, that's not fixed in stone either (it's using whatever tool hilight colour you select in the preferences).
The dark theme isn't mandatory either, it's just that I'm on linux and this is the only OS at the moment that OpenXTalk Lite natively supports dark mode in.

[tperry2x]

Speaking of which, I'm going to bring back dark mode for MacOS, using Paul's files from his RCx version on the Mac. I don't have to do anything special for Linux (as I say above).
The biggest problem will be providing support for this on Windows 10 and lower.

Paul has very helpfully confirmed what I'd thought. (Thanks Paul), that the Windows API for drawing dark window titlebars is a bit unsupported on anything prior to Windows 11.

I now have the API documentation to hand, just got to work out how to link it up. Of course, I'll make this a preference that can be toggled on or off.

Something along the lines of:

[ x ] - use system theme (default)
[ ] - dark mode
[ ] - light mode

edit 1: I have found it's possible to do a C++ code injection before the preOpenStack fires in the IDE, and inject the unsupported Windows 10 dark mode code in. Although this works, I think it's a bit of a risky method (it's technically a complete 'hack', and not in a good way) - (the API says throughout that this could break at any time if Microsoft choose to change anything). I may look to set this from within the IDE instead as it is a safer method.

api-windows-10.png (64.08 KiB) Viewed 3319 times

By the way, I'm not ignoring the results of the poll above.
Top of the votes at this time is the Engine (can't do anything about that).
Full set of userguides and documentation (I've done the allguides today)
Youtube videos (I believe Paul is working on when he has time)
The object/card inspector to be revamped (It's a mess, so don't know how doable this is)
(dark mode comes next on the list of votes - this I can have a go at)
Tools palette orientation,
iOS build option fixes,
automatic code completion - these three all come at the bottom of the list of votes.

[richmond62]

So, here's the good news: Kelly has sent me the 9.6.11 builds bless him/her (?) (not, frankly, that anyone's gender really matters round these parts: although, also frankly, it would be super to get a load of female programmers on board (mainly because they see programming in a different way to males)).

So, here's the bad news: nothing doing until sometime over the weekend.

Hope to do a compare-and-contrast between the Mac Intel and the Mac ARM standalones to yield a meaningful something about any difference between them.

However, poisonously minded as I am, what'er the odds that:

1. 'Tis obfuscated code?

2. 'Tain't useful?

3. Is ONLY relevant to that stack, and will have to be something different for other stacks?

[tperry2x]

So, here's the good news: Kelly has sent me the 9.6.11 builds

Best of luck with this. (I have my fingers crossed)

[richmond62]

Hmm . . .

And let's fantasise for a moment that the difference is a single line of code . . .

The next question is whether it would be possible to write a stack that could open a standalone, as a text file, "inject" it with 'the ARM virus' and leave it in such a state that it actually would run on a Mac ARM machine.

Thoughts more than welcome.