OpenXTalk Forums

This requires some close reading as, unlike a lot of recent stuff, it does contain a lot of useful information, and food for thought:

https://livecode.com/livecode-10-things ... nkful-for/

Thanks for sharing this Richmond.
There are some interesting stand out points as far as I'm concerned:

You need a built server engine to be able to run the tools to be able to build the engine (well the part which parses and compiles scripts!)

This may well put the kibosh on our attempts to recompile the engine.

To bring in a new, young, vibrant audience, it must [...] stand up against the increasingly sophisticated competition.

Who would be their direct competition? - Are they referring to us? Perhaps, perhaps not.

AI has become in the blink of an eye not a “nice to have” but a part of the essential toolkit for any programming environment that wants to succeed.

I would disagree. AI is a "nice to have" for repetitive tasks. Coding needs sanitizing and analysis by skilled human individuals, and should be peer reviewed at all times if at all possible.

A fast and easy way to build interfaces is now expected from any serious tool.

This comes down to mindset and personal preference. The IDE that works for one person will not work for everybody. I'm currently thinking of having two modes of GUI. A Classic interface and a 'Modern' minimalist UI to please the younger audience (although this is a huge task* - more on this further down).

How do I see this moving on?
It's becoming clearer and clearer to me that getting the engine recompiled will be a huge task, and one I don't think is probably at all doable by us. We don't have a team of C++ coders (to my knowledge, only foxtrot has come forward so far to offer to have a go at this) - and more power to you btw.

What does that leave us with? - I'm seriously considering if we can stand upon someone else's shoulders to move things forward. I know Paul had luck with getting openxion to begin supporting applescript UI elements, and I'd like to continue this idea through to an object based model using something like wxWidgets for Linux, Windows and MacOS
https://siytek.com/macos-gui-cpp/
I mean, it looks like it'd be ideally suited to drawing native window controls:
https://docs.wxwidgets.org/latest/overview_cmndlg.html

What I'd really need is a huge ask. Would Rebecca G. Bettencourt be willing to take OpenXion away from Java and rework it into a C++ binary? Something she'd let us use as a new engine? I would love to start afresh with a clean streamlined slate, but it needs 'hooks' for a UI and to support wxWidgets
https://github.com/kreativekorp/openxion

This is how I see things moving forward. I don't know if this makes sense, and so I'd like Paul to consider this approach too if he can have a read of it. (I'll PM him with this link to this post).

There's a lot of ifs there, and either way it's a lot of work. I honestly see this as inevitable, as it increasingly feels like we are flogging a dead horse regarding the current LC engine underpinnings.

we are flogging a dead horse regarding the current LC engine underpinnings

Well that depends on what 'we' are trying to do:

1. Produce a "continuation LC Community" that is, basically, LC 963 with new labels and, possibly, a way to produce Mac ARM standalones.

2. Producing something that, while using LC 963 as a starting point ends up as something quite new and different.

We need to get a #1 "out of the front door" as soon as possible [one of my criticisms of Paul was that he was being distracted by wanting to add so many fancy bells and whistles that no solid OXT 'starter version' was forthcoming].

Were I to be asked to teach Primary children xTalk NOW, I would use LC 963 because there is STILL nothing that looks, on the surface, that polished.

AND, beyond the surface 'twiddles' there is nothing that justifies an engine rework at the moment: and that should wait until:

1. We have a #1 to get 'out there' and start attracting attention.

Education is not going to give a flying fudge about what the underlying engine is; they are going to give an FF about what the GUI looks like.

Cripes: a Windows engine build requires Python as well:

https://github.com/livecode/livecode/bl ... ild-win.md

THIS looks comparatively easy:

https://github.com/livecode/livecode/bl ... d-linux.md

Not too bad either:

https://github.com/livecode/livecode/bl ... ild-mac.md

HOWEVER, it does look as if each engine has to be built on a machine running the target operating system . . .

. . . you are certainly not getting me running out to buy Windows for that.

or, perhaps:

3. Start with a fresh clean slate, that we can base our UI on top of. Create things that aren't 'locked away' in the engine, and have no reliance on legacy underpinnings that are no longer maintained.

Also, we could suggest that we change the license to an open source permissive license.
So keep it a free-software license for the end user, but we include minimal restrictions on how the software can be used, modified, and redistributed, usually including a warranty disclaimer. This also means that LC can't touch or take anything from our efforts in future.

I'm not suggesting this to be 'spiteful' or anything like that. I kind of resent putting loads of work in, only to have it 'ripped off' for want of a better word into a commercial product. Feelings aside for how I might perceive LC, I think what they gave the Open Source Community was fantastic back-in-the-day. But that was back then, and things have moved on (and continue to move on).

I'm very aware that whatever I do to the IDE is just windowdressing: papering over the cracks. We need to tackle the engine, and I'd like to start with something we can get our teeth into with the permission granted for us to use it from the outset, with maintainability in mind.

Rebecca may / may not give us permission, so this is just pure conjecture at this point.
I'm also aware that what I'm considering involves a huge amount of work. But so does struggling on with an engine that is flawed. (That's not being unkind). Reading how the current engine creates bottlenecks in the processing timeline, I can absolutely see LC's logic of needing to rebase it completely. It's just a case of how long do we carry on trying to patch and struggle with what may be a bit of a dead-end?

If we change the engine over to something else, which already has great underpinnings (openxion), then the issues of building for ARM / iOS / Android / Intel x32 / Intel x64 are possibly easier to tackle. I think it better to write things that everyone can understand and follow, rather than struggling on with a complex engine that nobody really knows well enough.

I'll refer back to this, but with a caveat:
viewtopic.php?p=4095#p4095
The caveat is, can we have it as a native executable rather than a java (jar) file? Rebecca mentions as much at https://github.com/kreativekorp/openxion

Version 2 will be ported to a lower-level language.

I'm reading that and interpreting it as C++ or something similar?
Even most of the code is a mystery to those at LC, who don't seem to know why some bits are why they are the way they are. There's plenty of examples of this if you dig deep enough.

I get what you are saying about getting point 1 done and dusted first, and I'm not saying that we abandon the LCC 9.6.3 base tomorrow. I'm just suggesting that work should begin on an alternative that we can move to, sooner rather than later. We can carry on fettling OXT, because most of the changes we make (all) will be done in xtalk scripting. We can probably move this to a new engine as long as the hooks for a UI are in place, so this does not prevent progress still being made on OXT Lite and OXT.

I'd just rather have a plan in place for continuation as I'm aware that this isn't going to be a 5 minute job for anyone.

richmond62 wrote: ↑Thu Nov 23, 2023 8:57 am Were I to be asked to teach Primary children xTalk NOW, I would use LC 963 because there is STILL nothing that looks, on the surface, that polished.

Are we no further forward now than we were?
https://www.openxtalk.org/forum/viewtopic.php?f=2&t=502

Please can I have your feedback on what you'd like changed. I don't mean this in a flippant way at all. Please tell me what you feel is preventing you from using OpenXTalk Lite 0.94 to teach with (aside from the lack of examples, templates, and hand-holding documentation)?

If I know what you think is missing, it's something I can work towards implementing (engine limitations not withstanding).
But, I'm getting away from the refactoring topic and moving more into the realms of 'feature requests' again here.

https://www.bluemangolearning.com/livec ... community/

In fact, in fact, in fact, a slew of useful stuff here:

https://www.bluemangolearning.com/livecode/

Please can I have your feedback on what you'd like changed.

Nothing much beyond the numbering (err . . . 1 . . . hint, hint) and the start image.

My "Kiddy Tools" should be ready by Christmas, and they can be strapped to anything; possibly even to the extent of making ALL the 'standard' GUI invisible.

only to have it 'ripped off' for want of a better word into a commercial product

Have you any evidence LC are pinching any of your stuff?

richmond62 wrote: ↑Thu Nov 23, 2023 9:20 am Have you any evidence LC are pinching any of your stuff?

Not yet they aren't, and they currently have no reason to. However, if we were to do a lot of work in a new engine, the last thing I'd want is anyone to take that away and sell it on as a commercial product in future.

This is not an accusation that they would, it's merely putting a clause in place to say that it can't be done (by anyone, not just LC).

richmond62 wrote: ↑Thu Nov 23, 2023 9:18 am Nothing much beyond the numbering (err . . . 1 . . . hint, hint) and the start image.

Please see:
https://www.openxtalk.org/forum/viewtop ... 4441#p4441

While not yet deserving of a 1.0 release for the many reasons I've mentioned, I also don't see what difference calling it v1 makes to students/pupils (whatever you want to call them), or even to teachers. It does matter to anyone looking at the more technical aspects as version 1 should be perceived as a more polished / finished product than it already is.

This comes down to the lack of documentation.

richmond62 wrote: ↑Thu Nov 23, 2023 9:18 am My "Kiddy Tools" should be ready by Christmas, and they can be strapped to anything; possibly even to the extent of making ALL the 'standard' GUI invisible.

I meant to ask about this, and ask how it was coming along.

richmond62 wrote: ↑Thu Nov 23, 2023 9:16 am https://www.bluemangolearning.com/livec ... community/
In fact, in fact, in fact, a slew of useful stuff here:
https://www.bluemangolearning.com/livecode/

This all pertains to building the IDE from source, not the engine I'm afraid, and is of course still using the outdated 9.6.3 codebase.

The Kiddy tools have stalled: took up some time with trying to sort out some sort of online squabble between two people . . .
- - -
Right: running for the bus as my wife went off with the car as she had a very early start.

tperry2x wrote: ↑Thu Nov 23, 2023 9:27 am

richmond62 wrote: ↑Thu Nov 23, 2023 9:20 am Have you any evidence LC are pinching any of your stuff?

Not yet they aren't, and they currently have no reason to. However, if we were to do a lot of work in a new engine, the last thing I'd want is anyone to take that away and sell it on as a commercial product in future.

This is not an accusation that they would, it's merely putting a clause in place to say that it can't be done (by anyone, not just LC).

The license cannot be changed for anything that includes any code from the original open source release.

That's in the license itself, and the cornerstone of international copyright law; only the creator of an original work can determine the terms under which it is distributed.

The GPL goes further to state that anyone receiving a software released under GPL has a right to request the source code and to modify it for any purpose whatsoever, but anything they released based on it must use the same license.

That requirement would seem to protect your interests with regard to that company: they make a proprietary product, and as such cannot include GPL-governed code.

It does not, however, help if the goal is to produce a proprietary product that no one else can modify and redistribute. Anyone interested in making anything that uses anything in a GPL-governed work can do so. That's why the license was created, to encourage proliferation.

Ah. Okay. Thank you for clarifying.
So, if I were to generate an entirely new stack, and it's therefore all my own code, can I specify that the code within cannot be used in anything other than an OpenXTalk distribution?

The reason I'm wondering this is if Rebecca (of the openxion source) permits us to use it as an engine (something we can develop in the background parallel to OXT lite), then I'd like to ensure we protect that going forwards.

Stupid people like me are going to get tied up in knots with something that contains components with radically differing licences.

In fact this is a load of crap for 2 reasons:

1. The people "up the road" are extremely cocksure (one in particular), and they have reason to be so to a certain extent, so I cannot see them 'lowering' themselves to pinching code.

1.1. Of course if they want to mimic any new functionality, that should be seen as praise, and good on them.

2. Mixing and matching copyright, copyleft, and some sort of copyslalom will just not work.

What IS needed is a competent person to go through the LC engine with a fine toothed comb, get out the knots, nit eggs, ticks, and so forth, and build us a set of lightened engines that will serve us for the next 4-5 years.

Please do not tell me that with each incremental upgrade LC ran off new engines.

richmond62 wrote: ↑Thu Nov 23, 2023 6:59 pm What IS needed is a competent person to go through the LC engine with a fine toothed comb, get out the knots, nit eggs, ticks, and so forth, and build us a set of lightened engines that will serve us for the next 4-5 years.

I'd love to believe this was possible, and I wish anyone nothing but all the luck in the world with it. However, who wants to do such an arduous task for free? It's been said before, but this is probably where a developer / developers will give up a sizeable amount of time and incur costs to do this.

richmond62 wrote: ↑Thu Nov 23, 2023 6:59 pm Please do not tell me that with each incremental upgrade LC ran off new engines.

No, I won't tell you that, but bits seem to be tacked on from version 8 onwards. None of it is really commented either. It's a bit of a nightmare to fix.

Well, as evidenced from that LC announcement you found me. It's taking a team of them ages to unpick it all, and they put most of it together in the first place.

they put most of it together in the first place

Not as far as I can tell: most of the staff that worked on LC 8 decamped quite some time ago.

With the exception of the top 3 or 4, most of the staff look like fresh graduates from University.