In Scotland an 'x' is a negative sign.

@ Richmond. I hope you understood that the x)'s in the to-do list have already been done. The numbered items I still need help with. Also, I have managed to download the debranded dictionary database file from gethub, and waiting for permission from Paul to use it. Terry

FourthWorld wrote: ↑Sun Aug 20, 2023 9:31 pm If the reasons are good, we can shout them from the rooftops.

It seems that the system here shows my follow-up questions under "Guest".
Also I made no direct reference,
so this doesn't really help for a consistent discussion I guess...

If you want to have a look, it's post #3142:

viewtopic.php?p=3142#p3142

I would still like to explore the next steps along your path.
In this case it might be really worthwhile to open a new thread soon.

Best wishes

Never a dull moment with this 'one':
- -
Oh, Blast it, I'll open the thing anyway . . .
- -
What was that rubbish I wrote about God liking a trier?

I think at least one 'God' is redefining the word 'Lila' in a whole new way:
- -
One, Seriously Blue Meanie!

documentation/html_viewer/resources/data/api/api.sqlite

Ho, Ho, Ho: time to reach for one's highly developed sense of humour (or, possibly, 'humor').

This seemed like a good idea:
- -
https://sqlitebrowser.org/

until I actually opened the fudging thing:
- -
I assume (?) those 'BLOBS' encoded in some filthy sort of binary data are what we'd like to edit . . .
- -
GREAT JOY

x) Add btn "Clear Msg Box History" and minor alignment of objects to Preferences.

I spent 4 hours this afternoon cursing and swearing in an attempt to modify the Preferences stack.

Of course you could provide a plugin:
-

Wow: totally screwed the 'revMenuBar' stack:
- -
Oh, well, God likes a trier: back we go again.

Just copied the Quick Dictionary plug-in across to my thing to see . . .
- -
MAGIC!
-
Now the "dirty trick" is how to make the Dictionary button and the Dictionary menu item open that instead of the standard dictionary . . .
-
Oooops: just one thing, on QUITTING the IDE with the Quick Dict open there is a 'bluey" thrown:
- -
I'm going to do some 'sophisticated' programming and try to see what happens if we just kill some of those code lines.
- -
Yup: that did it.

Paul replaced the sample video with another film clip: easiest way to do things.

Release notes: personally I just wrote my 'crap' in Open Office and saved it as a PDF.

I am currently in a 'spot' as my modded IDE won't save stack!

Minimum requirements SHOULD be no different that those for LC 963, if that is your hack-base.

Making good progress. All appears stable and working on Windows. On track for a public release in early September.

o Richmond's great idea of hiding group "Upgrade" from Toolbar Icons and Toolbar Text by shortening the menuBar worked. Much thanks.
o I noted Brian Milby's link to his dictionary editing tool on gethub. I tried, but I'm not smart enough to figure out how to download anything on gethub.
o Currently working on tperry2x's idea of editing the dictionary's database directly to debrand. Thank you. On Windows, the dictionary db file is at:
documentation/html_viewer/resources/data/api/api.sqlite. What was used to edit this SQLite database file?

@ Richmond. I appreciate the leg work trying to find a way to edit the dictionary's database file. I could not find your questions on the dictionary. Still request:
- Could you lend your expertise with mac/linux to check Release Notes and post an updated list of platform minimum requirements?
- I think preferences stack is the same on all platforms. Could you compare preferences on mac/linux?
- Does Quick Dictionary plugin work or is it blank like the standard Dictionary?

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) Hide group "Upgrade" in View > Toolbar Icons and Toolbar Text menuItems, and reordered them in the menu making Icons first then Text.
x) Add copyleft notification to About.txt and revAbout dialog.
x) Lighten Message Box blue hilite color in single-line and multi-line modes.
x) Add nine tutorial stacks.
x) Add btn "Clear Msg Box History" and minor alignment of objects to Preferences.
x) Add "Bug Report" heading to "Release Notes.pdf".
x) Fix program name to appear in menubar on all platforms.
10) Update "Release Notes.pdf" list of platform minimum requirements. Need help.
11) Blank dictionary. Probably uses absolute filepath rather than relative filepath to database file.
12) Debrand dictionary database. There are only a few. Is there a tool for that? Need help.
13) Make .oxt extension. Still want .livecode compatibility. Need help.
14) Add 64-bit re-compiled engine. No contact from Paul or Mark.

#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?

@ 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.
----

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.

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.

FourthWorld wrote: ↑Mon Aug 14, 2023 3:11 pm 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

The hunt is on:
- -
Let's try a few 'twiddles':
- - -
NOTHING useful at all.

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.

-
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:
- -
Did the trick:
-

Apparently Editable and can be Saved:
- -
Now, let's restart LC 963 and see what we can see:
- -
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.

Erm: took about 5 second to locate the thing:
- -
Sooooooooo ? Can I edit the thing in an external editor?
- -
Openable:
- -
Line numbers a bit different.