What I'm adding, and what I'm planning next...
Forum rules
A place to discuss and plan OpenSource xTalk (not exclusively LCC based) and Community Builds of LCC
Ask NOT what xTalk can do for you... get involved you DO have something to contribute, no matter your skillset!
A place to discuss and plan OpenSource xTalk (not exclusively LCC based) and Community Builds of LCC
Ask NOT what xTalk can do for you... get involved you DO have something to contribute, no matter your skillset!
- richmond62
- Posts: 2905
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: What I'm adding, and what I'm planning next...
Bonus bragging . . .
That's a Windows executable in a wineskin wrapper on MacOS.
Well, I was doing that with LC 963 and MacOS Snowman for quite some time.
The only snag (and quite a big snag) was hiving off MacOS standalones . . . that did not function in MacOS.
That's a Windows executable in a wineskin wrapper on MacOS.
Well, I was doing that with LC 963 and MacOS Snowman for quite some time.
The only snag (and quite a big snag) was hiving off MacOS standalones . . . that did not function in MacOS.
https://richmondmathewson.owlstown.net/
- tperry2x
- Posts: 1689
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Britain (Previously known as Great Britain)
- Contact:
Re: What I'm adding, and what I'm planning next...
Correct. And an updated one, based on this, to work on MacOS 10.15.4 through to (in theory) MacOS 14.richmond62 wrote: ↑Fri Apr 12, 2024 9:12 am Bonus bragging . . .
That's a Windows executable in a wineskin wrapper on MacOS.
- overclockedmind
- Posts: 300
- Joined: Sat Apr 30, 2022 9:05 pm
- Location: Midwest US
- Contact:
Re: What I'm adding, and what I'm planning next...
Wineskin.tperry2x wrote: ↑Fri Apr 12, 2024 8:52 amI think you are right, and it's a real pity.overclockedmind wrote: ↑Fri Apr 12, 2024 1:51 am Sorry to be so blunt, but Apple isn't Apple anymore. Those who don't see it, simply refuse to see it.
I wonder if this method would be the future option for running OXT lite on MacOS?
No prizes, but bonus bragging rights if you can spot what might be different to this version I open, as opposed to the normal MacOS 1.03 version.
MBA (Early 2015, 8GB/512G SSD, Monterey 12.7.2)
System76 serv12 (64GB RAM, 2TB SSD, 2TB HD, Win 10 Pro x64)
Power Mac 3,1 Project - Needs TLC will get it soon
System76 serv12 (64GB RAM, 2TB SSD, 2TB HD, Win 10 Pro x64)
Power Mac 3,1 Project - Needs TLC will get it soon
- tperry2x
- Posts: 1689
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Britain (Previously known as Great Britain)
- Contact:
Re: What I'm adding, and what I'm planning next...
![Image](http://www.tsites.co.uk/sites/openxtalk/images/thumbsup.png)
Yes, that's the one, but modded for newer MacOS.
The thinking being that it's a way of providing a newer engine (9.7) if the mac version won't compile. Hopefully it won't come to that. Otherwise, anyone is welcome to try compiling it.
Paul mentioned that the code might be intended to compile under Big Sur (which I can't run here as don't have anything capable of running it, let-alone compiling in it). - But, I don't mean to heap this job onto Paul, so with the link above, it's fair-game for anyone to have a go at.
- OpenXTalkPaul
- Posts: 1723
- Joined: Sat Sep 11, 2021 4:19 pm
- Contact:
Re: What I'm adding, and what I'm planning next...
That's not the only snag, no maOS native functionality is going to work with a Windows version running in a Virtualization, and to make a 'standalone' of sorts you would have to include Wine Engine.richmond62 wrote: ↑Fri Apr 12, 2024 9:12 am The only snag (and quite a big snag) was hiving off MacOS standalones . . . that did not function in MacOS.
What I meant was I think they must have been compiling on BigSur, but 9.6.3 the build target macOS SDK is 10.9 (Intel 64 bit arch only, 32bit was dropped after 9.6.1). They were likely testing the build on macOS 11 because there's BigSur related bug fixes listed, so it would make sense to compile on that too (the testing automated).Paul mentioned that the code might be intended to compile under Big Sur (which I can't run here as don't have anything capable of running it, let-alone compiling in it). - But, I don't mean to heap this job onto Paul, so with the link above, it's fair-game for anyone to have a go at.
If you read through the Gitter.im LiveCode dev chat group, Monte mentions compiling on macOS 10.12, but maybe he meant macOS 12? Not sure.
- tperry2x
- Posts: 1689
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Britain (Previously known as Great Britain)
- Contact:
Re: What I'm adding, and what I'm planning next...
That potentially means that no 32-bit mac standalone can be produced if I did succeed in updating the mac engine to the 9.7-dp1 github version (?) I wonder if that was dropped in the standalone builder, or if it was axed via the engine directly.OpenXTalkPaul wrote: ↑Fri Apr 12, 2024 9:20 pm (Intel 64 bit arch only, 32bit was dropped after 9.6.1). They were likely testing the build on macOS 11 because there's BigSur related bug fixes listed,
I wasn't aware there's a LiveCode dev chat group (?)OpenXTalkPaul wrote: ↑Fri Apr 12, 2024 9:20 pm ...read through the Gitter.im LiveCode dev chat group, Monte mentions compiling on macOS 10.12, but maybe he meant macOS 12? Not sure.
Have tried on MacOS 10.13 and got the results mentioned previously. It would make sense that they were doing this on big sur.
- tperry2x
- Posts: 1689
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Britain (Previously known as Great Britain)
- Contact:
Re: What I'm adding, and what I'm planning next...
I've also made this conditional, so you can turn it on and off via the preferences:
- tperry2x
- Posts: 1689
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Britain (Previously known as Great Britain)
- Contact:
Re: What I'm adding, and what I'm planning next...
Also added this for Linux users.
If this is turned on, the engine uses the system's shared memory extension (if available) to speed up rendering.
The setting of this property has no effect on MacOS or Windows. (It's a Linux-only thing).
If this is turned on, the engine uses the system's shared memory extension (if available) to speed up rendering.
The setting of this property has no effect on MacOS or Windows. (It's a Linux-only thing).
- tperry2x
- Posts: 1689
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Britain (Previously known as Great Britain)
- Contact:
Re: What I'm adding, and what I'm planning next...
Just checked: I can make a stack on linux (using the 9.7-dp1 engine from my recompile).tperry2x wrote: ↑Sun Apr 14, 2024 7:06 amThat potentially means that no 32-bit mac standalone can be produced if I did succeed in updating the mac engine to the 9.7-dp1 github version (?)OpenXTalkPaul wrote: ↑Fri Apr 12, 2024 9:20 pm (Intel 64 bit arch only, 32bit was dropped after 9.6.1).
I can save this as a 32-bit MacOSX standalone
Transfer to the old MacOS machine, and confirm it's running in 32bit mode.
If anyone is wondering why didn't I make the stack on the Mac version of OXT lite - it's because it wouldn't have been a worthwhile test. That version of the engine is stuck at 9.6.3, so I wanted to check that the 32-bit build option hadn't been disabled in-engine in 9.7-dp1 (which it hasn't been by the look of this).
Long story short: looks like we can retain MacOSX 32-bit compatibility for a while longer.
- OpenXTalkPaul
- Posts: 1723
- Joined: Sat Sep 11, 2021 4:19 pm
- Contact:
Re: What I'm adding, and what I'm planning next...
Excellent!
Will help me in merging too!
Having all the things like this as optional is a great, one thing I'd also like to get to is for everything to be user customizable. The reason being can be seen in this instance in that U.S. Letter/Legal/Tabloid Paper standard sizes may not be particularly useful for someone that's not even printing or if they are maybe not buying printer paper in the USA. So I propose we can have simply line-delimited or tab delimited IDE .conf configuration files in the user's folder for things like this.
I was thinking that these extra Sizes, along with IDE / syntax coloring sets, and color swatch palettes (those GIMP .gpl files, two palettes I've worked on and that GIF Editing library could all benefit from supporting color swatches / color tables files). Eventually I wanted to also make 'Template' stacks a thing, and also Auto-completion snippet additions could be added in there as well. They would be loaded via directory in the ~/My OpenXTalk/ (or ~/.openxtalk/) folder (where user installed extensions get installed). They'll be setup in the same way as other parts of the IDE in that the content can be extend over the content included in the IDE folders (such as the AddOns/ or the revLibIcons stuff for examples).
A little work would be needed for syntax coloring sets so as to not be limited to the hard-coded sets. I think those get stored as an array so should be able to replace/add to that array.
I want to be able to set the IDE highlight colors too, like the color of the highlight block in the Tools pal, which currently in my build it's still that 'OXT' violet color/ Really this color should be auto-set to what the user has selected in their operating system/ UI theme. I have extension the can get the system wide user selection color on macOS. Did you implement something to get the equivalent from the elected theme on Linux/FreeDesktop compliant OS UIs? Or did you already make this a user-settable pref?
I'm currently cleaning up my dev projects folders again and I really want to do a 'Deluxe' release before moving on to making a serious effort to do a 'clean' build of LC CE 9.6.3 for the mac engine binary (and then moving on from there to doing some editing to it).
- OpenXTalkPaul
- Posts: 1723
- Joined: Sat Sep 11, 2021 4:19 pm
- Contact:
Re: What I'm adding, and what I'm planning next...
Not sure how your SBuilder is set up, but my 9.6.1-based 32bit-building (re-) setup, builds from as separate 32 bit standalone build folder/procedure. The older scripts would build 'FAT' 32+64 and then called on 'Lipo' command line to strip out the unused architecture bits for 32-only or 64 only. Currently we want 32-only as a back-porting option only, since 32 bit on macOS has long been deprecated at this point 10.8, and the 32bit engine is 9.6.1 (not 9.6.3).
Yeah, but its not at all active these days:I wasn't aware there's a LiveCode dev chat group (?)
https://app.gitter.im/#/room/#LiveCode_Lobby:gitter.im
- OpenXTalkPaul
- Posts: 1723
- Joined: Sat Sep 11, 2021 4:19 pm
- Contact:
Re: What I'm adding, and what I'm planning next...
From the last posts in that chat room:
ICUDK, 'Travis' is an automated build system:
https://www.travis-ci.com
I don't have a machine that runs El Capitain v10.11, I skipped over that macOS version, but I suppose it could be set up, maybe in a VM, for compiling purposes.brucemontegani (Bruce Montegani)
Is there a reason the engine is still being built against MacOS SDK 10.9? It would seem that it would be easier for Livecode to drop support for old versions and only support newer versions both for MacOS and iOS. 10.9 (Mavericks) was released in 2013 and the last update was in July 2016. Anyway, which SDKs do I need to install to get livecode to compile. This includes:
engine/ — The main LiveCode engine. This directory produces the IDE, "standalone", "installer" and "server" engines
Non-third-party libraries:
libcore/ — A static library that provides various basic functions and types, and is used by many of the other subprojects
libexternal/ and libexternalv1 — Static libraries that support the LiveCode "external" interface, which allows the engine to load plugins
Externals (libraries that can be dynamically loaded into the engine at runtime):
revdb/ — Database access external, and drivers for various backend database systems
revmobile/ — The iOS support external (which can only be built on Mac) and the Android support external (available on all desktop platforms)
revpdfprinter/ — Print-to-PDF functionality
revspeech/ — Text-to-speech support
revvideograbber/ — Video capture (Windows only)
revxml/ — XML parsing and generation
revzip/ - Zip archive management
Can I install the latest sdks?
montegoulding (Monte Goulding)
We build and run tests against macOS 10.11 on Travis so you could go with that if you want (requires extra configuration). The simplest is to download Xcode 6.2 and use the script as described to symlink the SDK into a newer version of Xcode.
ICUDK, 'Travis' is an automated build system:
https://www.travis-ci.com
- tperry2x
- Posts: 1689
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Britain (Previously known as Great Britain)
- Contact:
Re: What I'm adding, and what I'm planning next...
I made this a user settable pref: Only because you can theme Linux and Windows (to a lesser extent), so having something that picks up on whatever theme might be in use is quite hard. I thought it was simpler just to let the user select their own colour for the tool button hover/select colours.OpenXTalkPaul wrote: ↑Mon Apr 15, 2024 8:49 pm Did you implement something to get the equivalent from the elected theme on Linux/FreeDesktop compliant OS UIs? Or did you already make this a user-settable pref?
That would be great. If you can get that engine to compile. Using the 9.7 source from github for the engine though would bring a lot more fixes to the party for MacOS. These are fixed in the 9.7 engine:OpenXTalkPaul wrote: ↑Mon Apr 15, 2024 8:49 pm I'm currently cleaning up my dev projects folders again and I really want to do a 'Deluxe' release before moving on to making a serious effort to do a 'clean' build of LC CE 9.6.3 for the mac engine binary (and then moving on from there to doing some editing to it).
- X and Y Co-ordinates now should be correct for multi-screen macOS systems.
- Placing buttons and progress bars on a card will no longer cause slowdowns on macOS 10.10 or later.
- When opening the IDE menus on macOS, there should no longer be a delay.
- The engine will no longer crash when accessing the camera or microphone on recent versions of macOS X.
- Scripts which run without locking the screen are a lot faster (macOS Big Sur and later)
- If lots of fonts are loaded into memory, the time to quit the IDE has been improved.
- If an engine runtime error occurs, an error dialog will be displayed rather than failing silently.
- While typing in the script editor, performance has been improved.
- If you open and close the message box, the IDE used to get slower. Fixed.
- tperry2x
- Posts: 1689
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Britain (Previously known as Great Britain)
- Contact:
Re: What I'm adding, and what I'm planning next...
Not depreciated in my version, I re-enabled it again in the standalone builder a while back.OpenXTalkPaul wrote: ↑Mon Apr 15, 2024 9:13 pm Not sure how your SBuilder is set up, but my 9.6.1-based 32bit-building (re-) setup, builds from as separate 32 bit standalone build folder/procedure. The older scripts would build 'FAT' 32+64 and then called on 'Lipo' command line to strip out the unused architecture bits for 32-only or 64 only. Currently we want 32-only as a back-porting option only, since 32 bit on macOS has long been deprecated at this point 10.8, and the 32bit engine is 9.6.1 (not 9.6.3).
My version uses lipo too, resulting in non-fat (slimmed-down / specific x32 and x64) binaries:
- tperry2x
- Posts: 1689
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Britain (Previously known as Great Britain)
- Contact:
Re: What I'm adding, and what I'm planning next...
Poking around in the various LCC builds, I think I spotted a typo.
In 9.0, this file seems to be incorrectly spelt - and seems to have been incorrectly spelt all the way up to 9.6.3 and 9.7 from what I can tell. The IDE is looking for the file with the correct spelling, so I've corrected it. I'm not sure yet what side-effect this might have. (good or bad) - more testing to be done, but it seems like it would allow mobile/android built apk and iOS apps - the datagrid should recognise a swipe gesture.
In 9.0, this file seems to be incorrectly spelt - and seems to have been incorrectly spelt all the way up to 9.6.3 and 9.7 from what I can tell. The IDE is looking for the file with the correct spelling, so I've corrected it. I'm not sure yet what side-effect this might have. (good or bad) - more testing to be done, but it seems like it would allow mobile/android built apk and iOS apps - the datagrid should recognise a swipe gesture.
- tperry2x
- Posts: 1689
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Britain (Previously known as Great Britain)
- Contact:
Re: What I'm adding, and what I'm planning next...
I'll cover those points from that chat room (as far as I'm concerned anyway):
If I had my way, I'd support MacOS X 10.6 or further back to PPC. Why can't we have some backwards compatibility as well as MacOS 14+?Is there a reason the engine is still being built against MacOS SDK 10.9? It would seem that it would be easier for Livecode to drop support for old versions and only support newer versions both for MacOS and iOS. 10.9 (Mavericks) was released in 2013 and the last update was in July 2016.
The instructions are here for Mac compile environment setup. You need multiple versions of xCode (6.2.1 > 8.3)Anyway, which SDKs do I need to install to get livecode to compile.
Yes, but I only care about the 'Engine' - not fussed about the others at this point. Baby steps first.engine/ — The main LiveCode engine. This directory produces the IDE, "standalone", "installer" and "server" engines
Aren't these all part of the Mac prebuilts - I believe all these libs are included inside the tar.bz2 files. You can manually copy these into the 'Fetched' folder, to skip all the hassle of the gyp build script trying to access them from the livecode server, which obviously it can't do.libcore/ — A static library that provides various basic functions and types, and is used by many of the other subprojects
libexternal/ and libexternalv1 — Static libraries that support the LiveCode "external" interface, which allows the engine to load plugins
Externals (libraries that can be dynamically loaded into the engine at runtime):
revdb/ — Database access external, and drivers for various backend database systems
revmobile/ — The iOS support external (which can only be built on Mac) and the Android support external (available on all desktop platforms)
revpdfprinter/ — Print-to-PDF functionality
revspeech/ — Text-to-speech support
revvideograbber/ — Video capture (Windows only)
revxml/ — XML parsing and generation
revzip/ - Zip archive management
Yes, and if retaining support for 10.9, need to install and link additional xCode versions in /Applications/xCode_Dev/Can I install the latest sdks?
Yes, exactly my point above - but wrong MacOS version?We build and run tests against macOS 10.11 on Travis so you could go with that if you want (requires extra configuration). The simplest is to download Xcode 6.2 and use the script as described to symlink the SDK into a newer version of Xcode.
Do they mean MacOS 11?I don't have a machine that runs El Capitain v10.11, I skipped over that macOS version, but I suppose it could be set up, maybe in a VM, for compiling purposes.
- OpenXTalkPaul
- Posts: 1723
- Joined: Sat Sep 11, 2021 4:19 pm
- Contact:
Re: What I'm adding, and what I'm planning next...
I think mine is the same, I recall now that originally I tried to make this use 32-bit-slice-only binary (to save on a few megabytes of space) and then change script to skip the lipo part of the SB building process but I couldn't get that to work correctly for some reason and so just left it as-was.tperry2x wrote: ↑Mon Apr 15, 2024 9:52 pmNot depreciated in my version, I re-enabled it again in the standalone builder a while back.OpenXTalkPaul wrote: ↑Mon Apr 15, 2024 9:13 pm Not sure how your SBuilder is set up, but my 9.6.1-based 32bit-building (re-) setup, builds from as separate 32 bit standalone build folder/procedure. The older scripts would build 'FAT' 32+64 and then called on 'Lipo' command line to strip out the unused architecture bits for 32-only or 64 only. Currently we want 32-only as a back-porting option only, since 32 bit on macOS has long been deprecated at this point 10.8, and the 32bit engine is 9.6.1 (not 9.6.3).
My version uses lipo too, resulting in non-fat (slimmed-down / specific x32 and x64) binaries:
sb-oxt-lite.png
I still think it would be cool to also add back-in an even older back-port option, back to a PowerPC engine. Such as build script would need to down save the stack versions of all stacks down to like vers. 4 or 5 stack file format (loosing bits like Widgets and better Unicode support).
- tperry2x
- Posts: 1689
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Britain (Previously known as Great Britain)
- Contact:
Re: What I'm adding, and what I'm planning next...
Me too. In fact, it makes me wonder if I can look at an older LCC standalone builder and pull the 10.4 PPC > 10.6 routines from it.OpenXTalkPaul wrote: ↑Tue Apr 16, 2024 12:50 am I still think it would be cool to also add back-in an even older back-port option, back to a PowerPC engine. Such as build script would need to down save the stack versions of all stacks down to like vers. 4 or 5 stack file format (loosing bits like Widgets and better Unicode support).
- tperry2x
- Posts: 1689
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Britain (Previously known as Great Britain)
- Contact:
Re: What I'm adding, and what I'm planning next...
Today, I've been going through removing typos like this:
- OpenXTalkPaul
- Posts: 1723
- Joined: Sat Sep 11, 2021 4:19 pm
- Contact:
Re: What I'm adding, and what I'm planning next...
![Laughing :lol:](./images/smilies/icon_lol.gif)
Hah I've corrected little things like that in a few comments, it just looks sloppy but has no actual effect on the IDE operations.
That was my thoughts on PPC engine, might possibly need 'lipo' still, as that probably used a PPC32/Intel32 'FAT' binary. The PPC Engine binary can certainly be lifted from 6.5.2 (IIRC) Community edition. It seems the standalone 'building' is not so much 'building' as it is more the 'linking' part of compilation. Again, must ensure stack files are in 6.x compatible stack format version before building.
Who is online
Users browsing this forum: No registered users and 2 guests