OpenXTalk Lite Beta Testers

[richmond62]

Those screen shots are really fantastic!

I will see if I can fiddle around and get things going here on at least one of my machines.

[richmond62]

So . . .

On my 'New-Fer-You' Mac running MacOS 12:

I put a copy of the LC 963 app for Mac into a folder called 'Terry, and, opened it and replaced ALL the folders that could be replaced with yours . . .
-

Screen Shot 2023-08-18 at 22.26.46.png (551.5 KiB) Viewed 16628 times

-
Dunno why it is still called 'LiveCode'.
-

Screen Shot 2023-08-18 at 22.27.10.png (657.93 KiB) Viewed 16628 times

-
That looks good: although, as the thing is meant to be open source, that should use the COPYLEFT symbol:
-

Copyleft.svg.png (11.51 KiB) Viewed 16628 times

[richmond62]

The Dictionary seems empty:
-

Screen Shot 2023-08-18 at 22.27.33.png (226.78 KiB) Viewed 16627 times

-
Bear in mind that this may be something to do with my swapping your folders & files into the Mac App 'shell'.
-

Screen Shot 2023-08-18 at 22.29.24.png (1.12 MiB) Viewed 16626 times

-
Works, but the SUFFIX is meant to be .oxt: or, at least, NOT 'livecode.

[richmond62]

Screen Shot 2023-08-18 at 22.29.43.png (218.79 KiB) Viewed 16626 times

-
There should be no opportunity to upgrade anything.

[richmond62]

This weekend I will attempt to perform a 'purge' with the Mac App, and see what we shall see.
-

Screen Shot 2023-08-18 at 20.52.15.jpg (157.98 KiB) Viewed 16626 times

[richmond62]

Terry, can you tell us all how you replaced all the incidents of 'livecode' in the IDE?

[TerryL]

This is good news Richmond. Findings noted, I'm working on them.

Try the Quick Dictionary plugin. If it doesn't work then something's wrong with the Dictionary database. Both work fine for me.

The Upgrade button is being resistant. I've deleted/saved several different ways...I'll stay on it.

Never said I removed ALL LC references. It appears they went to extraordinary efforts to embed it everywhere. I'm just trying to remove the visible ones.

I need another tester to try another idea I have. Terry

[richmond62]

This IS a problem, I'm afraid:
-

Problem #1.png (1.83 MiB) Viewed 16562 times

[richmond62]

You can simplify things by JUST making the group 'upgrade' on the 'revMenuBar' stack invisible:
-

Screen Shot 2023-08-20 at 12.25.03.png (1.53 MiB) Viewed 16560 times

-
Then shorten the stack so that silly whitespace is no longer visible:
-

Screen Shot 2023-08-20 at 12.27.27.png (1.58 MiB) Viewed 16559 times

-
BUT, because the 'revMenuBar' stack is NOT really a stack, but is generated from a script, the thing does NOT stick:
-

Screen Shot 2023-08-20 at 12.29.24.png (188.05 KiB) Viewed 16558 times

-
Which is a right @#$%^&*(, so you have to think (or I am doing the thinking right now) of something a bit more clever:

Remember:

1. You want to make the 'upgrade' group invisible.

2. You want to make the width of the 'revMenuBar' less.

As #2 should hide the 'upgrade' group anyway, #1 may not be necessary.

OBVIOUSLY, what is needed is a script that shortens the 'revMenuBar' stack as it opens . . .

So, the BIG Q is where to put that script.

[richmond62]

So . . .

I had a look at the script in the 'home' stack:
-

Screen Shot 2023-08-20 at 12.35.18.png (1.93 MiB) Viewed 16558 times

-
Obviously lines 73 and 74 need to go . . .
-

Screen Shot 2023-08-20 at 12.38.24.png (255.58 KiB) Viewed 16557 times

-
Let's see if THAT 'sticks' after a restart . . .
-

Screen Shot 2023-08-20 at 12.40.45.png (292.26 KiB) Viewed 16557 times

-
NOPE

So, the NEXT BIG Q has to be HOW to edit a livecodescript file and get the edit to stick.

And, before that, to find out WHERE the 'home.livecodescript file IS.

[richmond62]

Erm: took about 5 second to locate the thing:
-

Screen Shot 2023-08-20 at 12.44.07.png (168.09 KiB) Viewed 16558 times

-
Sooooooooo ? Can I edit the thing in an external editor?
-

Screen Shot 2023-08-20 at 12.45.36.png (53.09 KiB) Viewed 16558 times

-
Openable:
-

Screen Shot 2023-08-20 at 12.47.08.png (554.92 KiB) Viewed 16557 times

-
Line numbers a bit different.

[richmond62]

Apparently Editable and can be Saved:
-

Screen Shot 2023-08-20 at 12.48.48.png (37.73 KiB) Viewed 16556 times

-
Now, let's restart LC 963 and see what we can see:
-

Screen Shot 2023-08-20 at 12.51.30.png (172.19 KiB) Viewed 16556 times

-
Wow: I very nearly had a spontaneous #$%^&*(

So: the next thing to do is to see whether we can bung in a line to shorten the 'revMenuBar' stack via the IDE, or we have to go back to the external editor: and, once we have done that see which comes first; the chicken or the egg.

[richmond62]

Screen Shot 2023-08-20 at 12.57.34.png (416.66 KiB) Viewed 16556 times

-
That did NOT stick via the IDE. Back to the external editor.
-
THAT edit made the 'revMenuBar' vanish completely!

Being too clever for my own good.

This, however:
-

Screen Shot 2023-08-20 at 13.03.06.png (40.79 KiB) Viewed 16555 times

-
Did the trick:
-

Screen Shot 2023-08-20 at 13.03.40.png (355.84 KiB) Viewed 16554 times

[richmond62]

So . . . what have I learnt that is useful?

1. livecodescript files CAN be edited and saved in an external text editor: they CANNOT be changed from inwith the IDE.

Well, if nothing else, that is, for me at least, a major bit of useful information.

[richmond62]

The hunt is on:
-

Screen Shot 2023-08-20 at 13.12.19.png (50.78 KiB) Viewed 16551 times

-
Let's try a few 'twiddles':
-

Screen Shot 2023-08-20 at 13.16.30.png (48.89 KiB) Viewed 16549 times

-

Screen Shot 2023-08-20 at 13.17.48.png (43.94 KiB) Viewed 16548 times

-
NOTHING useful at all.

[mdm]

Some months ago I took some time to think this problem through: how to make a truly viable open source xTalk.
I'll spare the details and get to the bottom line: the leanest plan I could come up with takes a minimum of a quarter mil for the first 18 months, with at least half that each subsequent year.

Six days ago when this was posted I was overjoyed to read it,
because something obviously has changed
between "some months ago" when the issue was contemplated behind closed doors
and the current point of time where it becomes an invitation to openly discuss if it makes sense to have a plan for an open-source xTalk.

It seems the thread around it has gone other ways meanwhile.

@FourthWorld - are these questions still on the table? Then let's tackle them according to what you wrote, and let's not "spare the details".

As you have suggested, we should first write a list of features that an open-source xTalk would be bring to market that other platforms do not, making an effort plausible.

When we agree on this first list being non-empty we should discuss a second list, the one of development goals and steps. Right?

When the second list is finished, we should discuss a third document concerning ways to reach the goal and cost of implementation and funding opportunities.

Should we do this in continuing this thread or opening a new one, more concentrated on the questions raised?
In either case I would happily suggest a few entries for list #1.

I would assume the lists are non-empty, but quite short and not so hard to write up.

Cheers guys

[FourthWorld]

Thank you for your interest, mdm.

For myself, my top feature is the establishment of a nonprofit foundation with at least $220k on tap for the first year of operation.

Anything else is details unlikely to become actionable for any long-term benefit without solid funding.

This implies a first step which may be uncomfortable but I believe is necessary:

To find and communicate the reasons an open source xTalk are valuable for the current and next generation of software crafters.

Legacy concerns are of no interest to anyone not already using an xTalk. And there aren't enough people still using xTalks to support this open source effort the way it would require if we seek viability beyond 24 months.

Whether this should be a new thread is something I don't have an opinion on. With any xTalk fork it would seem relevant to ask: why are we doing this?

If the reasons are good, we can shout them from the rooftops.

[Guest]

Great!
Let's talk about reasons why we and other (would-be) developers still should stick with OXT/LC:

My notion would be that only a certain combination of features makes the platform unique:
GUI-centric + multi-platform + live coding + easy entry/installation + decent range (meaning you can go quite deep into application development on a coherent basis).
The product has big deficiencies as well. Let's talk about those later.

Other ("competing") platforms cover some of these features quite well:

You can do some nice GUI stuff in JavaScript as long as you follow the browser model. For real deployment you need to become a professional (a DOM pro or a node.js pro or a framework XY pro). Live-coding can be done, but not in a way comparable to the LC engine. I might be wrong.

You can very easily get something going in Python and go very far but if you want to do GUIs you are still left out in the wild. There is a range of options from Jupyter notebooks to 3D animation frameworks but this does not make it a coherent platform for interaction stuff.
I do not see a way to establish a live-coding experience in Python.

There are several Smalltalk dialects/derivatives which naturally are live-coding champions. GUI-wise they do not have much to offer if you want to go beyond a toy-like appearance.

We can take a look at no-code/low-code tools and at compiled languages as well, but both are a different kind of beast regarding the mentioned feature set.

I guess we would need to make a canonical list of features for a good comparison matrix.
Then we could put values there (like 1-5 or -- to ++) and see what the picture is.
Would you agree?

I would assume OXT/LC still would show a very distinct profile there.

Number one deficiency of course is the availability of a free scripting/runtime engine (in LC).
Who would pay or accept strange restrictions just to explore a new language nowadays?
This is something an OXT initiative would try to heal.

There is more, like
integration in modern development systems (version control etc)
or a way to work coherently across different platforms (esp across the desktop/mobile gap)
This would be key as well, and OXT/LC does not yet offer convincing solutions.

And there is real object-orientation and modern language constructs.
And other things.
Should we work on some kind of feature comparison in this manner and thus find out if OXT/LC could still be attractive beyond pure nostalgia and the legacy?

As you always rightly mention the number of people involved,
I guess a group starts with more than one.
So, two people finding common ground on how to proceed would be fine for a beginning.
There are many able people having stated different interesting things on different channels in the past two years,
I would think there is enough talent and willingness to help once some focus is established.
People will have to be actively approached of course. At some point, a foundation would need to pick up speed.

At least we are on the same page concerning the necessity of C++ work,
as past discussions on this site have shown.
Two years have passed, but it is not too late.

[TerryL]

@ Richmond. I'm making progress.
- post or send me directions to remove grp "upgrade" and I'll try. I failed and just removed the toolbar menuItems.
- I think preferences stack is the same on all platforms. Would you compare preferences on mac/linux?
- Would you check Release Notes and post an updated list of platform minimum requirements for mac/linux?
- Any ideas why the Inspector lost the tabs?

OXT Lite To-Do List
x) Fix App Browser plugin to show IDE stacks.
x) Fix Player object's default fileName to empty, so "Sample" video (LC Logo) can be removed.
x) Remove View > Toolbar Icons and Toolbar Text menuItems.
4) Copyleft in About. Can't find a copyleft text symbol. Found reverse c. Open source LibreOffice uses standard © symbol.
5) Make .oxt extention. Need help.
6) Blank Dictionary. Probably uses absolute filepath rather than relative filepath to database file: specialFolderPath("engine") &"/...
7) Debrand dictionary database. There are only a few. Is there a tool for that? Need help.
8) Update Release Notes list of platform minimum requirements. Need help.
9) Add 64-bit re-compiled engine. No contact from Paul or Mark.
----

[richmond62]

#6 is dead easy as the Dictionary IS built-in, and while lots of 'eggspurts' have (I hope, unintentionally) led me astray I have nailed the document down and you can learn about that here:

https://forums.livecode.com/viewtopic.p ... 62#p225262

I wonder why you did not bother to reply to any of my questions about editing the Dictionary?