Documentation - Instructions - Buses

[Skids]

Hi All,

I have been randomly reading older posts in an attempt to try and understand where I can offer help. So far all I have managed is to realise that there is a lot of terminology and under the hood techniques over and above the low level engine used by OpenXtalk that I don't know about.

I wonder if any of you experts (people who know more than I do) has ever made notes they are willing to share that describe how the overall OpenXtalk works. I'm not asking for detail but a broad brush overview of the internal structures would be very useful. This would be useful should anyone get hit by a bus and have to stop work. I have attached a pdf of an Omni Graffle drawing I made to describe a project I was playing with back in 2012 which sort of shows what I am thinking.

Wisper8Documentation.pdf

(153.94 KiB) Downloaded 64 times

Do any of you think that something like this would be useful? I am happy to create such a file but I will need to ask lots of questions.


Lastly if I find an area that I am able to make changes how do these get included in one or both of the two versions of OpenXTalk that are available?

best wishes

Simon

[OpenXTalkPaul]

Hi All,

I have been randomly reading older posts in an attempt to try and understand where I can offer help. So far all I have managed is to realise that there is a lot of terminology and under the hood techniques over and above the low level engine used by OpenXtalk that I don't know about.

I wonder if any of you experts (people who know more than I do) has ever made notes they are willing to share that describe how the overall OpenXtalk works. I'm not asking for detail but a broad brush overview of the internal structures would be very useful. This would be useful should anyone get hit by a bus and have to stop work. I have attached a pdf of an Omni Graffle drawing I made to describe a project I was playing with back in 2012 which sort of shows what I am thinking. Wisper8Documentation.pdf
Do any of you think that something like this would be useful? I am happy to create such a file but I will need to ask lots of questions.


Lastly if I find an area that I am able to make changes how do these get included in one or both of the two versions of OpenXTalk that are available?

best wishes

Simon

How the IDE (as opposed to the underling Engines ) works, to be honest, is a mish-mash patchwork of scripts sending messages to other scripts (in extension libraries), plus smatterings of oddities like JavaScript used in the Browser Widget plus SQLite DB (Dictionary), and storing lots of info in script-local arrays and/or custom properties in the revPrefs stack.

If it were to be put into a flowchart like your PDF it would look like a bowl of spaghetti.
But I think we're making some progress trying to simplify that, or at least not make it worse while hopefully improving on it.

One great contribution would be collecting all of the bits of info on the forum that we've spilled out here, mostly as we're figuring out how things actually work ourselves, into cohesive set of documents. There is lots of info on this site, but it is not at all well organized.

To contribute just pick a bug or feature you're interested in or think you could help with, and then ask about it first in case it's something we've already worked on or discussed. Collaborations have mostly been done by uploading stacks or posting scripts right here in the forums. Myself and a few others also use GitHub but Tom (tPerry2x) doesn't, and it's certainly not a requirement to contribute.

[tperry2x]

That's exactly it. Anything I discover of note, I've been putting into my mega file share under sample stacks.
As Paul says, we are figuring things out as we go. We've not been left any instructions at all

Mega file link here.

I get what you mean though. While nobody aims to have a close encounter of the bus kind, I'm all for sharing what we do know collectively. The biggest unknown for me is knowing how all this classic control / widget remake / new button xcmd / xBuilder controls... whatever is going to actually work. That's not a dig at Paul though, as I get the impression he's still figuring all that out himself and is making larger inroads into it than I've even managed to.

[OpenXTalkPaul]

Yes I certainly am still figuring some things out about parts of the IDE and Extension Builder, and learning more about various libraries the Engines depend on, and also trying to learn C++ while I'm at it. It's slow and tricky to try to make changes to IDE scripts because if you change something in one IDE library, it may have unexpected consequences in some seemingly unrelated other part of the IDE as there is some interdependence. Something that works well on macOS, may not work well on Windows, or might not work at all on a certain Linux distributions. So we need to be careful and have lots of people testing things against various setups and reporting problems, or giving us feedback (which I know encourages me to keep at it).

Even if you don't think you can contribute directly to the IDE or Engine dev, users could always contribute documentation. Write a walk-through lesson of how do some common programming task with OXT. Or do videos on YouTube if you don't want to write. Or you could just share some stacks that you've created or experiments you have worked on. You could just let us all know your story of what you've done with xTalk (could be non-OXT: HyperCard, SuperCard, LC CE or whatever) over the years. I mean there's lots of interesting things that have been done with xTalk/xCard tools over the past...[calculates].. 37 years (wow)! I enjoy hearing not only the famous stories, like the game Myst or Wikipedia started as Stacks, but also everyday work or non-commercial hobbyists play too. I think many of us are here because we simply love xTalk scripting. I think HyperCard / xTalk has a fandom that's unlike many other more traditional programming tools.

Really one of the goals I originally wanted for OXT was documenting the story of xTalk legacy, influence on other technologies. It has a history that's bigger than any one company. I think it would be cool to put together an open-source xTalk history eBook. Who knows, maybe we could generate some funding for some Engineering help by selling nice printed coffee table book about it!

[Skids]

Thanks for your replies. I shall try and start putting information published on this forum into some form of reference, possibly an SQLite database with an Xtalk front end. I am also happy to describe some of what I think are more interesting projects that I have created. I probably won't make a start until the autumn as I am away quite a lot in August and September as its suppose to be summer.

best wishes
Simon

[OpenXTalkPaul]

Thanks for your replies. I shall try and start putting information published on this forum into some form of reference, possibly an SQLite database with an Xtalk front end. I am also happy to describe some of what I think are more interesting projects that I have created. I probably won't make a start until the autumn as I am away quite a lot in August and September as its suppose to be summer.

best wishes
Simon

Cool, and no rush, I'm in this for the long haul.
I've actually been thinking about your flow chart PDF, and came around to the idea that it might not be a bad idea to have a map of sorts of the IDE startup process, the extensions libraries and UI stacks that it loads into memory immediately or 'lazy loads' later, what those depend on (if anything), and what info they store and where they store it (which is often in revPreferences file). That could help us to not break something when we change some other interdependent thing.

One issue with this is that we're changing some things, and in different ways (OXT DPE vs OXT Lite may be different in some aspects), and so some info may not be accurate after changes. For example, I have added a 'forwarder' stack (which behaves a bit like an Alias/Shortcut/Symlink) in place of the old 'revResourceCenter' stack, which in turn loads a stack 'Resource Center' in editable mode, which I've 'unbranded' but I wanted to redesign that stack completely so that it loads example/lessons content in a more dynamic way from separate files or URLs so that we could more easily include user submitted content (I've not yet spent much time to working on this idea). Eventually I would replace the 'forwarder' with the redesigned stack itself.