OpenXTalk Forums

No SVG handling, fair fekked stuff with GIF images as far as I remember.

If you are going to make a MacOS PPC version "just because you can", well, by all means go ahead, but I really wonder if anyone but a few wierdos (me?) will download it, let alone use it.

Might it not be better to devote your energies to other things.

I am sure the 'few wierdos' who feel an urge to build stuff with xTalk on Mac PPC have either got one of the PPC Open Source versions, or like me, a licensed version (I own RR 3.5, 4, and 4.5), or both.

richmond62 wrote: ↑Tue Apr 16, 2024 1:38 pm No SVG handling, fair fekked stuff with GIF images as far as I remember.

If you are going to make a MacOS PPC version "just because you can", well, by all means go ahead, but I really wonder if anyone but a few wierdos (me?) will download it, let alone use it.

Might it not be better to devote your energies to other things.

I am sure the 'few wierdos' who feel an urge to build stuff with xTalk on Mac PPC have either got one of the PPC Open Source versions, or like me, a licensed version (I own RR 3.5, 4, and 4.5), or both.

I'm one of those weirdos that still has Macs that run 10.4+Classic/10.5++ Sorbet Leo PPC...
I'm such a Mac hoarder that I still have macOS 6.0.7 working on my first Mac (512KE upgraded to a 4MB Mac).
But I agree, it's probably not worth spending much time trying to back-port stuff.

Still I might some day spend just a little time trying to make an v6 based OXT retro PPC build of sorts. While v6 didn't have all the nice newer features of later versions, it was quite a bit faster, and could still be quite useful, and it did supported things like Quicktime APIs and could use that Advanced ExtendedQT external from Trevor DeVore, which are things that can no longer be used on newer versions of macOS.

Additionally, for Intel 32bit on Snow Leo/Lion there could be a v8 based retro build, v8.x version did have Unicode, Widgets (but not FFI), Browser Widget, SVG Widgets, including COLOR SVG Widget which was superseded in v9 by integrating Color SVG support into the classic image control.

OpenXTalkPaul wrote: ↑Wed Apr 17, 2024 1:51 am

richmond62 wrote: ↑Tue Apr 16, 2024 1:38 pm No SVG handling, fair fekked stuff with GIF images as far as I remember.

If you are going to make a MacOS PPC version "just because you can", well, by all means go ahead, but I really wonder if anyone but a few wierdos (me?) will download it, let alone use it.

Might it not be better to devote your energies to other things.

I am sure the 'few wierdos' who feel an urge to build stuff with xTalk on Mac PPC have either got one of the PPC Open Source versions, or like me, a licensed version (I own RR 3.5, 4, and 4.5), or both.

I'm one of those weirdos that still has Macs that run 10.4+Classic/10.5++ Sorbet Leo PPC...
I'm such a Mac hoarder that I still have macOS 6.0.7 working on my first Mac (512KE upgraded to a 4MB Mac).
But I agree, it's probably not worth spending much time trying to back-port stuff.

Still I might some day spend just a little time trying to make an v6 based OXT retro PPC build of sorts. While v6 didn't have all the nice newer features of later versions, it was quite a bit faster, and could still be quite useful, and it did supported things like Quicktime APIs and could use that Advanced ExtendedQT external from Trevor DeVore, which are things that can no longer be used on newer versions of macOS.

Additionally, for Intel 32bit on Snow Leo/Lion there could be a v8 based retro build, v8.x version did have Unicode, Widgets (but not FFI), Browser Widget, SVG Widgets, including COLOR SVG Widget which was superseded in v9 by integrating Color SVG support into the classic image control.

The earliest Mac I owned was a 128K (telephone wiring, pre-ADB) that I got for $10, knowing it would be worth something, someday. The basement it was in flooded.
The earliest Mac I used was an SE/30.

The most recent is in my signature.

overclockedmind wrote: ↑Wed Apr 17, 2024 4:20 am The earliest Mac I owned was a 128K (telephone wiring, pre-ADB) that I got for $10, knowing it would be worth something, someday. The basement it was in flooded.
The earliest Mac I used was an SE/30.

The most recent is in my signature.

Wow, that was an original!

My 512ke still has the pre-ADB phone-line wire too.
I had video repaired once it back it the 1990s. I boot it now and then just to make sure it still does.
The whole OS is on a 800k floppy, that amazes me now.

Sneak peak at 1.04
I'm changing to an orange scheme, away from the purple.
(That's not all that's added/changed - there's quite a list). This will be detailed in the OXT Lite release announcements page nearer the time.
Just extensively need to test on Windows and MacOS before I release this.

Does this mean that you have compilled from 9.7?

Mic

I'm changing to an orange scheme, away from the purple.

As a purplist I am very happy to know that, and look forward to 1.04 with anticipation (admittedly not only for the orange theme).

micmac wrote: ↑Fri Apr 19, 2024 11:04 am Does this mean that you have compilled from 9.7?
Mic

For Linux and Windows, not for MacOS.

And why not for Mac, forbye?

richmond62 wrote: ↑Fri Apr 19, 2024 11:31 am And why not for Mac

Version 1.04 of the mac version will be using the older engine of 9.6.3, whereas the Linux and Windows builds have additional fixes as they are using the 9.7 engine.
(As mentioned at the bottom of this comment)

That version of the engine is stuck at 9.6.3

So you'll get a 1.04 build for MacOS, but it won't include some of the fixes in the Linux and Windows versions.
This is because the 9.7 engine source will not compile for MacOS, so currently the mac version is trailing behind the other builds - with the engine from 9.6.3.

Which is a shame, as most of the fixes in the mac engine were patches to improve the compatibility with big sur+

We know it can be done because Livecode company has done it. They even made it run on ARM.
There must be someone out there that have the knowledge of this and who will maybe volunteer.

Mic

micmac wrote: ↑Fri Apr 19, 2024 3:32 pm There must be someone out there that have the knowledge of this and who will maybe volunteer.

That would be nice, and also quite unlikely it seems.
While we are there, we could ask that they maintain the mac version going forward.
Also, any help updating the iOS and Android standalone build targets would be good - as these have no maintainer / developer who can update them as part of the OXT project now either.

I'm sure it makes sense to LC, because ultimately they created it and already have their build machines configured exactly how they need. We don't even know for sure what version of MacOS we are supposed to be compiling this on. I know we are looking to keep a build target of 10.9 as a minimum still, which should be doable. But, what version of MacOS and xCode is this intended to be compiled in?

micmac wrote: ↑Fri Apr 19, 2024 3:32 pm We know it can be done because Livecode company has done it. They even made it run on ARM.

I'm no expert on C++, as I've only recently taken the plunge to learn it. (A couple of months ago now), so I still have a long way to go.
Someone who also has modern mac hardware to try to compile it on is also needed.
If anyone wants to pass £549 to me, for a mac that will run a new MacOS, with absolutely no guarantees that anything will ever come of it - feel free

richmond62 wrote: ↑Fri Apr 19, 2024 11:22 am ...(I) look forward to 1.04 with anticipation (admittedly not only for the orange theme).

This will sound a funny question, but what exactly are you hoping to see in v1.04 of OXT Lite? - Realistically that is. Bearing in mind it's purely just me contributing to it?

Actually, you know what - scrap what I did with the engine recompile on Windows.
Why? Because I just did a speed comparison between the 9.6.3 and the 9.7 engine in windows 10, and the 9.7 engine is sloooow.

Seems it was too good to be true.

It's probably something I did at compilation stage. I'm really not happy with it - I don't want to inflict that on anyone, so...
Going back to the 9.6.3 engine for windows. The 9.7 engine for linux will be the only one that's updated.

I'll leave the re-compiling the engine to someone else. Link here. Fill your boots. Someone who's better at C++.
I've updated the bug status page to reflect this.

richmond62 wrote: ↑Fri Apr 19, 2024 11:22 am

I'm changing to an orange scheme, away from the purple.

As a purplist I am very happy to know that, and look forward to 1.04 with anticipation (admittedly not only for the orange theme).

Originally I changed it from LC CE Green to purple just because that was one color that hadn't been used for any edition of LC. Personally, I think this should automatically change to whatever the system UI theme has as the highlight color.
Which is why I wrote that bit of code (that one I did the Extension Builder FFI walk-through on) to get that system setting.
But that only works on macOS so does anyone know a reliable shell command line way to get the highlight color info from a Gnome, KDE, etc. themes on Linux? Or Windows?

I was wondering about that before. The only way I could reliably do it (when you factor in the combination of different window managers and such in Linux), was to have a field with a selection, then get the mouseColor of a coordinate - sampling the colour.

Now that's fine on windows and Linux, but can't use that on Mac without a dialog popping up (MacOS 10.11 El-Cap+ I think), saying "OpenXTalk wants permission to record your screen" - which is a bit disconcerting for Mac users.

We could use a combination of approaches - one method for Win & Linux. Then a different method for MacOS.
However, was your idea to have variable icon colours too?

I think there should be some sort of limit on aesthetic considerations: increased functionality is more desirable.

Or, put another way:

Once a developer has finished programming their thing to the level of functionality they desire, they can work on the aesthetic of their thing themselves.

In other words, stop messing about with the appearance and focus on the other bits that matter.

Yes, I know. Point taken - I just wanted to get away from the purple (if nothing else, to differentiate "lite"). To fix the other bits is still my focus, however I obviously lack the ability to start fixing lots in the engine (at least for Windows and Mac), and we need someone to fix the iOS and Android engines / build targets too.

That's just it. None of those jobs are '5 minute jobs'. Each of those jobs that matter (on that list in the above link) all represent large headaches. Frankly, this is why I'm sure LC have a 'dev team' rather than just 2 people.

TAK1974 wrote: ↑Sun Apr 07, 2024 7:58 am Yes that would be the one. Since discovering it, I’ve had a hard time going back to the built in LC script editor.

Just to revisit old ground, and going back up this message chain a bit. Is there already (or can someone provide) a demo video of the GLX2 script editor in action? Just so I can see how it's supposed to work and take some of those features across to OXT Lite.

Well: I did not mean it in such a strong fashion.

HOWEVER . . .

Over the last 22 years I have pumped out about 90 standalones from RR/LC, and every single time, used images-as-buttons, and so on, as really have never "gone for" the bog-basic aesthetic provided by RR/LC.

After all my target end-users have been:

1. University students at St. Andrews in Scotland. Programs for practising phonetic recognition and transcription.

2. High School kids in Scotland. 'Listen Hear'.

3. Indic language digitisers in all sorts of places (even India!). 'Devawriter'.

4. Bulgarian academics. 'Pismo'.

5. Academics worldwide. 'Grendel'.

6. 6-18 year old children learning English. Too many of the things to mention (well, 75).

Obviously in each use-case there are different considerations, and whether the IDE that is used to develop those things has looked has pink, green or orange 'twiddles' has been neither here nor there.

Now, of course, I cannot speak for other programmers: but those whose end products I have seen seem to fall into 2 camps: those who are worried about functionality only and produce fairly ugly things based directly on what the IDE provides that do lots of "computing magic", and those who have spent quite some considerable time making their things look the way their personal aesthetics go (doing as much magic as the others).

So, as far as I am concerned, what you need to produce is a front-end that is not too jarring on the programmers' eyes (and I do think that purple was a bit jarring), and that's all.