OpenXTalk Forums

-
It is interesting that the IDE (this is a copy of LC 963 I am abusing) gives me a widget icon for my new button.
- -
Pop that in the folder and get a lemon-yellow button called 'Press'.

Oh, and you'll have to pop this new version of a TVS file in the same folder:
- -

TSV = Tab Separated Values.

Yes, this is the same method by which all those extra shapes were added into the tools palette
(credit to Paul on that, for posting how it is done)

Your widget icon is appearing because it can't find the corresponding custom icon for your button, so it's substituting with this so it shows something.

Tom didn't you recompile the Engine on Linux?
Did you pull in any of the the 9.7 waiting (for years now) pull requests?
The recommended build env. for Emscripten is Linux so I was wondering if it built that too.
I'm particularly interested in the patch and related patches linked to here:
https://github.com/livecode/livecode-ide/pull/2129

If it is relatively easy to recompile the engine on Linux what exactly makes things so difficult to compile an engine for MacOS ARM?

richmond62 wrote: ↑Sat Jul 27, 2024 2:46 pm If it is relatively easy to recompile the engine on Linux what exactly makes things so difficult to compile an engine for MacOS ARM?

It's not relatively easy at all, on any platform.
Please see my post to Brian, where I describe what was changed.

What made it possible on Linux, was the fact that I only had the command line to worry about. I didn't also have to fight with VisualStudio or xCode. (There was no additional layer of compiler to contend with).
Even then though, the Gyp build tool had a lot of seriously outdated and depreciated syntax which had to be updated first. Thankfully, it's not too hard to replace the depreciated parts - just time consuming and monotonous, but at least it tells you as you step through it.

But certainly not an easy task. What makes it so difficult to compile for MacOS arm is you are changing the execution language of the application binary. It's not a (simpler) recompile where you make some changes to the source, and recompile the application - (with a normal source change, you aren't having to re-write the execution code each time you do this). When you change the target platform from intel over to Arm, there's also Apple API changes to consider - the way the engine interfaces with other parts of the OS in ways that Apple sanction and expect an application to do.

Plus, as I mentioned elsewhere before my post was deleted, it's not just a case of changing the engine over to arm. The standalones would need to be updated to run on arm too (perhaps a simpler task to some degree), but it really depends on what we've been left with, and how-far-along Arm support came in the 9.7.0-dp1 source.

Oddly enough the engine source you used (stoed on MEGA) is encrypted.

I should like to send an accessible version of it to my friend who is trying to work out what chances there are for an ARM build with people he knows.

richmond62 wrote: ↑Sun Jul 28, 2024 10:30 am Oddly enough the engine source you used (stoed on MEGA) is encrypted.

Try it now. I think there was a # out of place in the link.

Not that you'd necessarily want to use my version.
I did send you all these links previously, when we were discussing exactly this last time, but here's the link to that post again.

That bloke is the sort of bloke who needs to be 'stimulated' on a weekly basis if one hopes to get any results.

Apple API changes to consider

The nice thing is that most of the Objective C Apple API code shouldn't need to be changed (may be just need menu issue Sonoma+ fix), the bigger hurdle may be whatever problems may arise after changing target CPU architecture to Apple Silicon. Apple developer (paid) support might be helpful with that last mile or two?

I don't have an Apple Silicon CPU Mac to even try to build the thing with.

Tom-

Dude, you really should figure out how to use github.
Congrats on getting the engine compiled on osx and windows. But...

Here's some of what I've got in the engine on my github account:

Build libraries from source if necessary rather than fetching prebuilts from a livecode server or from outdated archive

Updates:
these updated libraries will now download and build from source if necessary so no need for prebuilt binaries

Updated icu to version 63.2
Updated curl to version 7.51.0
Updated CEF to version 74.1.19
Updated libxml to version 2.11
Updated OpenSSL to version 1.1.1v
Updated libjpeg to version 6b
Updated libgif to version 5.2.2
Updated sqlite to version 3.44
Updated libzip to version 1.10.1
(NOTE: had to install libzstd-dev)
Updated zlib to version 1.3.1
Updated revzip to match the new libzip and zlib libraries
NOTE: we're still using some deprecated libzip functions in revzip
Updated libpng to version 1.6.43

Bug Fixes
21231 linux printing using cups
import snapshot #17257, 20104, 15541, 15103, 15094
23149 ???
16682 inherited hilitePattern
17323 view backdrop obscures entire screen
195 (!) second parameter in menuPick message
7330 webassembly
19236 update lots of outdated libraries
11032 pkexec vs gksu
removed nag screen message (tperry's fix)
LCB guide block comment syntax
macos systemversion

New features
PR #6644 (matches operator):
"foobar" matches wildcard pattern "*b*" -- evaluates to true
microsecond timing for Windows ( the long milliseconds )
cross-platform not-equal operator
remove license check
linux specialFolderPath("documents") bz #15904, 21032 (English only for now)

WIP:
Updated pixman to version 0.43.2
Updated libfreetype to version 2.13.2

mwieder wrote: ↑Wed Jul 31, 2024 1:33 am 7330 webassembly

I'm salivating over here.

LCB guide block comment syntax

What's that bug? I've not had a problem with comment blocks in Xtension Builder lang.

cross-platform not-equal operator

Is this the unicode equivalent of the old HyperTalk MacRoman character (≠) ?
I'd also like to have the HC line-continuation token back (¬ which is option+L on mac)

So do you have compiled binaries we can download?
Even if it's Linux only (Emscripten wasm build option?) build?

Here's my git commit comment for the LCB thing... I don't remember whether there was a bug report on this or whether it came up in a forum post or who came up with this. It sounds like something Bernd would do. It's just a fix to docs/guides/LiveCode Builder Language Reference.md.
I've only got the linux binaries but I'll see about posting them somewhere. The big thing for me, though, is not having to rely on the prebuilt libraries anymore. They're way out of date and now I can update them as needed. Libcairo is still giving me problems but it's a WIP.

mwieder wrote: ↑Wed Jul 31, 2024 3:37 am the linux binaries but I'll see about posting them somewhere. The big thing for me, though, is not having to rely on the prebuilt libraries anymore. They're way out of date and now I can update them as needed. Libcairo is still giving me problems but it's a WIP.

That would be great!

That's great you got the dependencies pulling from repos and compiling from source, but I imagine that adds significantly to the overall compiling time. I believe that's why LC team did the prebuilt thing to begin with.

It might be best if I re-fork from your engines repo, and then add in my dictionary .lcdoc files/revDocParser changes.

OK - I've put the linux binaries du jour online for you. I put the whole directory online, so it's 300 MB. I grab the engine binary (LiveCode-Community) and replace the 9.6.3 engine with it to test it out, but in a real-world situation you should also replace the extensions that get built at the same time (revdb, revxml, etc).

And obviously this will start getting out of date as soon as changes get made.

https://mega.nz/file/h5YUVBqR#1zuKX0Qyh ... JK882wSgf4

Yeah, the new build paradigm does increase the build time a bit, but I think it's worth it to be able to upgrade thirdparty libraries. I can slightly improve on that by replacing the "cp" commands in the builds with "cp -u", but I'm keeping it that way for now because I've had to back down from some newer libraries when things didn't quite work out.

...and yes, go ahead and refork from my engine repos.
You'll need both the livecode-thirdparty submodule and the main OpenTalkEngine.

This bit was in the welcome section, but I replied to it here instead - so the welcome section doesn't get full up with comments:

OpenXTalkPaul wrote: ↑Thu Aug 01, 2024 3:03 am LCB (for de-branding purposes I've been calling that XB / eXtension Builder) Widgets and Libraries (specially with foreign function interface) in my opinion is an extremely useful piece of the platform, and I have no intentions of removing it...

I don't wish to cover up LCB / XB at all or hide it from view. However, this is where the OXT Lite version will differ from OXT DPE as you may decide to make XB more visible.
I've not nixed anything in XB, however my dictionary and guides are now .txt based in v1.07 and so there's no need for all those html files and web-based dictionary-generating stuff. - but the "api.sqlite" database remains, as there's no need for it (unless the 'quick dictionary' is chosen in the preferences). I'm keen to keep the rest of XB available - so if you make a hand-holding auto-generating XB stack, I'd love to include that as part of OXT Lite too.

tperry2x wrote: ↑Thu Aug 01, 2024 2:59 pm if you make a hand-holding auto-generating XB stack, I'd love to include that as part of OXT Lite too.

I don't know if auto-generating Xtension Builder is possible as such, it may be too general-purpose use for that, but I do think that a stack with pre-made template handler's and metadata generating is surely doable.

There is a command-line thing that auto-generates FFI binding strings from Java and there were plans to do the same for C/C++/Objective C that would be parsed from .h header files but that never came to fruition. ChatGPT can be pretty good at doing that if you point it at an API's documentation.

The docs are .txt files now! That's awesome
...and having looked into that before, I'm impressed by the amount of work I imagine went into that.

The startup handler in the home stack is still causing this same error for me, and I had to implement the same fix.
I'm imagining that it's something to do with the default path but haven't plugged in any deeper.
And mystified about why it works for you and not for me.

viewtopic.php?p=9550#p9550

...and after I fix that I get an error from the message box.
Something is calling the tMsgSelect handler and I get the error
"can't select object that isn't open"

Update:

in the openCard handler of card id 1002 of stack revMessageBoxSingleLinecardBehavior is (line 37) The error causes the openCard handler to stop executing at that point.
From there I have to click at where the File menu of the menubar should be, select "float above everything" from the inspector, and quit.

Nobody else has reported that kind of error, and that's why I'm perplexed by it. (Although it doesn't take much).
I wonder if it's something in your preferences - so could you try running this as either another user or in a VM, or on another computer that hasn't had LCC / OXT / previous prefs file saved?
Sounds like I'm clutching at straws, and that's only because I am

LOL. I got around the second problem by increasing the timing from 5 ticks to 100. Possibly a difference in cpu speeds.
...and I did try this without preferences or third-party plugins.
I can try digging into the path thing but it'll have to wait until tomorrow.