openXION

[richmond62]

https://github.com/kreativekorp/openxion
-

SShot 2022-08-14 at 10.51.57.png (24.92 KiB) Viewed 4496 times

-
I suppose some of us have become spoilt . . . . 29 years of a WYSIWYG GUI . . .

[richmond62]

SShot 2022-08-14 at 10.57.26.png (152.8 KiB) Viewed 4495 times

-
I suppose I now have to dig around and, manually, create those directories, set their permissons, and generally wonder
why I am bothering at all . . .

FFS: for what? To end up with a command-line 'thingy' that, because it has no GUI provides no way
to set up a stack . . . OK, let's try:
-

SShot 2022-08-14 at 11.01.33.png (65.43 KiB) Viewed 4495 times

-
Odd, given:
-

SShot 2022-08-14 at 11.04.07.png (88.33 KiB) Viewed 4494 times

-
And where, forbye, does one put 'it'?

"The newly-created object is placed in the local variable it."

NOT that there seems to be a stack in 'it' in my attempt.

[richmond62]

Well, well, well, over on Mac OS 10.7.5 I managed to do this:
-

Screen Shot 2022-08-15 at 1.25.36 PM.png (101.68 KiB) Viewed 4471 times

-
and this:
-

Screen Shot 2022-08-15 at 1.28.45 PM.png (50.23 KiB) Viewed 4470 times

-
Which does not seem much use as there is NO stack . . . and no visual anything.

[richmond62]

Screen Shot 2022-08-15 at 1.30.55 PM.png (12.13 KiB) Viewed 4471 times

-
What am I missing?

[tperry2x]

Well, as far as I can see - having uncompressed the tgz file at:
https://raw.githubusercontent.com/kreat ... xndocs.tgz

Looking through the "XION Vocabulary Index", there's no mention of the command "Stack", so this is probably why it's erroring as it is an undefined command.

[richmond62]

LOL . . . that 'may be' the reason.

[tperry2x]

Screen Shot 2022-08-15 at 1.30.55 PM.png
-
What am I missing?

In fact, there's no mention of anything I would call user interface elements, such as "button", "stack", or "field".
It seems to be a bunch of string manipulators, calculation arguments, and methods for collecting and comparing data - but no GUI support.

Can I ask, is your intention to try and build OpenXION into OpenXTalk, or to try and make OpenXION aware of OpenXTalk's GUI in some way? I don't quite see how this is relevant to OpenXTalk.

It seems a bit like trying to reinvent the wheel, (when there's nothing wrong with the current wheel).
Trying to take another programming language and kind of force it to work with OpenXTalk seems a lot of extra un-necessary work. Trying to build a GUI on top of OpenXION when there's no suppport for it does seem like a diversion away from the improvement of OpenXTalk.

With xTalk, the key things would probably be to bug fix and improve the documentation. Perhaps improve the code-completion in a script editor to be on-a-par with the likes of Python IDLE, or UnityScript, or Godot's code editing mode.
(to have the documentation included after LC pulled it would be a good start)

Improvements and additions to the syntax could come later. There are things that really need improving upon, where other languages are way ahead currently (network packet transfer, sending and receiving, opening ports, sending binary data) - this is currently an arcane method and usage in xTalk and is due a huge refresh to keep pace with other languages.

Again, there's plenty of xTalk-like languages out there (SenseTalk for example, by Eggplant software)
https://codedocs.org/what-is/sensetalk
Or Supercard, or Metacard, or HyperStudio et-al...

There's no point trying to imalgamate and shove them into OpenXTalk (in my opinion) as we'll end up with a bloated mess.

Better to improve on what foundations we currently have, bugfix and update the core components, and then build out from there methinks?


Or, is your intention to try and do what PyQt is. You have an underlying core language (Python, or course), then have a GUI builder on top of that (example walkthrough: https://new.pythonforengineers.com/blog ... -and-pyqt/)
or, the PAGE GUI builder for Python:
https://www.youtube.com/watch?v=oULe0h0Jl3g

Is this essentially where xTalk or OpenXTalk is headed? - To have a base OpenXTalk core library installed - like your OpenXION command-line, then a GUI editor program on top of it? Are you thinking this would be an easier approach in the long run?

[richmond62]

"Can I ask" . . . just Richmond pissing around on his summer holidays.

[tperry2x]

The documentation from Livecode Community 9.6.3:
https://www.tsites.co.uk/otherstuff/run ... e-9.6.3.7z

At least on Linux, it goes in ~/.runrev/
Not sure about other OS's.

[OpenXTalkPaul]

Screen Shot 2022-08-15 at 1.30.55 PM.png
-
What am I missing?

In fact, there's no mention of anything I would call user interface elements, such as "button", "stack", or "field".
It seems to be a bunch of string manipulators, calculation arguments, and methods for collecting and comparing data - but no GUI support.

Can I ask, is your intention to try and build OpenXION into OpenXTalk, or to try and make OpenXION aware of OpenXTalk's GUI in some way? I don't quite see how this is relevant to OpenXTalk.

It seems a bit like trying to reinvent the wheel, (when there's nothing wrong with the current wheel).
Trying to take another programming language and kind of force it to work with OpenXTalk seems a lot of extra un-necessary work. Trying to build a GUI on top of OpenXION when there's no suppport for it does seem like a diversion away from the improvement of OpenXTalk.

There's no point trying to imalgamate and shove them into OpenXTalk (in my opinion) as we'll end up with a bloated mess.

Better to improve on what foundations we currently have, bugfix and update the core components, and then build out from there methinks?

Or, is your intention to try and do what PyQt is. You have an underlying core language (Python, of course), then have a GUI builder on top of that (example walkthrough: https://new.pythonforengineers.com/blog ... -and-pyqt/) or, the PAGE GUI builder for Python:
https://www.youtube.com/watch?v=oULe0h0Jl3g

Is this essentially where xTalk or OpenXTalk is headed? - To have a base OpenXTalk core library installed - like your OpenXION command-line, then a GUI editor program on top of it? Are you thinking this would be an easier approach in the long run?

I must have missed this thread a year ago when it started, but I'd still like to throw my two cents in here...

I think you both were missing something here. Mainly that OpenXION was created as a reference implementation fro the language xTalk dialect called XION. As you figure out, It doesn't come with or use any graphical controls or GUI libraries. Beyond that however, it is a useable xTalk that can be used on command line (from shell()) and runs on JAVA VM(s) (I've tested it on a few different JVMs).
So Java VM is OpenXION's 'Engine'. While it has no built-in knowledge of GUI objects such as 'Stacks','Buttons','Fields', etc. it DOES have syntax for defining from scratch and creating those sorts of objects in memory. Those objects could in theory then link to use or drive some GUI library that actually builds and manages the UI. This could be a lot like building GUI apps with Python using Qt or similar, In fact OpenXION can execute Python using syntax like do tMyPyScript. You can also do tScript as Bash, VBScript on Win, and of course AppleScript on macOS.

To test this idea, some time ago, I created a small library replaces the textual 'Ask','Answer', 'Answer Folder/File(s)', etc. commands and uses graphical AppleScript dialogs instead (from the AS standard editions lib available on every mac for many years now). It works well.
https://github.com/OpenXTalk-org/OpenXt ... criptUI.xn


With GraalVM 'natifier' that compiles the used JVM bits into a platform native executable binary, I can imagine this could be bundled up into a little standalone utility app, maybe make a good simple UI for some command line utility (like FFMPEG/FFPLAY for examples).

The advantage OpenXION has over our currently focused xTalk based on LC CE is that there's no need to recompile the 'Engine' to use OpenXION 'natively' on Mac's with AppleSilicon CPUs, or Raspberry Pi's, or FreeBSD, or whatever, because as long as there's a Java VM on the target platform then you're good to go!

https://github.com/OpenXTalk-org/OpenXt ... XION_Stuff

[OpenXTalkPaul]

I'd going to make the OpenXION Dictionary available online (again) but hosting on a OXT repo on GitHub.
I'd like to try to stick to using the keywords Becky used for non-HyperTalk xTalk syntax.
For example: the appPath -- that basically yeilds the same as "command -v" or "which" on POSIX OSes (I'm not sure if it's smart enough to return .app bundles on macOS as I can't test that at the moment). So if we're wrapping such a thing in a handler of a library (like in a Linux Tools library), we should use appPath() or 'the appPath of tAppName'.

[richmond62]

I'd going to make the OpenXION Dictionary available online

For what reason?

If the 'new' (i.e. non-LC) language terms are 'folded into' OXT, I can see a reason.

[OpenXTalkPaul]

I'd going to make the OpenXION Dictionary available online

For what reason?

If the 'new' (i.e. non-LC) language terms are 'folded into' OXT, I can see a reason.

For the reason that it will make it much easier to reference that particular xTalk dialect (xion/OpenXION), so I can more easily use it for whatever I might use it for (maybe even on FreeBSD which our OXT Engine doesn't do... anymore) and so that if I add any library commands or functions that need to be named I can try to keep the names consistent with other xTalk dialects (which helps make scripts that are PORTABLE to alternatives engines). XION is not the same as OXT xTalk dialect, although being very much an xTalk much of it of course is very similar. OpenXION, for example, has a 'Dictionary' variable type (like an Associative Array, formatted like a JSON wrapped Array), so until OXT has a 'Dictionary' value type, it's not going to be in an OXT Syntax Dictionary (unless we transform it into a multi-xtalk-dialect dictionary).

[tperry2x]

...some time ago, I created a small library replaces the textual 'Ask','Answer', 'Answer Folder/File(s)', etc. commands and uses graphical AppleScript dialogs instead (from the AS standard editions lib available on every mac for many years now). It works well.
https://github.com/OpenXTalk-org/OpenXt ... criptUI.xn

Therein lies my issue. That's purely just for MacOS if we use applescript for UI graphical elements. What about Windows and Linux? We need something that would work on all three (Linux, Windows and MacOS).
This is why I wondered about using wxwidgets previously - because it's cross platform.

Without a GUI, and something that can load a stack, something that drops you into an xtalk scripting shell where you can create GUI stacks with a set of tools (and more importantly save them), I don't see much advantage over using openxion at the moment than any other [vapourware] engine.

Yes, there are web versions, there are lots of things half-done and unfinished across the internet, and partial implementations offering bits of what we want, but nothing that offers anything like a set of comparable features in one engine. There's also things that have come and gone, (stacksmith, supercard, metacard et-al) - they need recoding heavily or completely reimagining to be cross platform. - either way, the IDE to go with any of these would need to be remade from the ground up.

[OpenXTalkPaul]

Therein lies my issue. That's purely just for MacOS if we use applescript for UI graphical elements. What about Windows and Linux? We need something that would work on all three (Linux, Windows and MacOS).

OpenXION has Python as an alternativeScriptingLanguage:

Code: Select all

do tMyUIScript as Python
put the result into tDialogResult

I did the same UI dialog trick using Tk from python to present the dialog, and it worked much the same way... on macOS with Python 2.7x installed (in addition to Python3).
However, I just today tried the same script on an up to date Linux and there's no way to easily install Python 2.7 nowadays (Python2 has been deprecated for a long time now, and last minor security updated 4 years ago). Tk is (and of course other UI toolkits are) available from Python3, but as I understand it Python 3 is significantly different syntax so the generated Python script may need to be updated. One other problem with this is that the OpenXION keyword 'as Python' points to the command 'python' which normally references Python2, but for Python 3 it would be like 'python3 myPyscript.py' in the terminal. I tried making 'python' be an alias for python3, but that has no effect on the OpenXION interpreter (I didn't try making it symlink'd).

As an alternative I could also re-write it as a bash script that runs python and the UI .py script.
OpenXION doesn't have shell() but it does have bash as an alternativeScriptingLanguage:

Code: Select all

do tMyBashScript as Bash

The bottom line is OpenXION needs to be updated to use Python3 as that is today's standard.
I'll see if I can find it in her java source and push the change.

[tperry2x]

The bottom line is OpenXION needs to be updated to use Python3 as that is today's standard.
I'll see if I can find it in her java source and push the change.

Could you perhaps use the package:
python-is-python3
This symlinks /usr/bin/python to python3

Alternatively, can OpenXION be statically linked to a python 2 folder?

[OpenXTalkPaul]

Could you perhaps use the package:
python-is-python3
This symlinks /usr/bin/python to python3

I'll look for that package, would be much easier than symlink manually, thanks.

Alternatively, can OpenXION be statically linked to a python 2 folder?

Probably, but it would be better if linked to Python 3 since 2 is now pretty much dead now.

[OpenXTalkPaul]

So what I'm thinking of is basically something like this:
https://github.com/benjie-git/CardStock
But with xTalk wrappings around the Python bits.

There was a similar project many years ago called PythonCard:
https://pythoncard.sourceforge.net

[tperry2x]

Probably, but it would be better if linked to Python 3 since 2 is now pretty much dead now.

Haha, you say that, but the LCC engine when compiling makes heavy use of Python 2.
Not saying you are wrong at all when you say Python 2 is dead though

[OpenXTalkPaul]

Without a GUI, and something that can load a stack, something that drops you into an xtalk scripting shell where you can create GUI stacks with a set of tools (and more importantly save them), I don't see much advantage over using openxion at the moment than any other [vapourware] engine.

Yes, there are web versions, there are lots of things half-done and unfinished across the internet, and partial implementations offering bits of what we want, but nothing that offers anything like a set of comparable features in one engine. There's also things that have come and gone, (stacksmith, supercard, metacard et-al) - they need recoding heavily or completely reimagining to be cross platform. - either way, the IDE to go with any of these would need to be remade from the ground up.

I disagree, I quite enjoy playing around with GUI-less xTalk. At a minimum it can do anything you could do with a bash script or from OXT using shell(). It also runs on anything from the last 15+ years that has a JVM, which was her intention in writing it in JAVA for "maximum protablity' (per the docs), and a huge advantage in my opinion. And the 'Engine' being JVM, is maintained by a community that includes some really big companies with resources and actual staff, that's another huge advantage.

I don't think every xTalk needs to be an xCard too (just look at Eggplant's SenseTalk, or even the LiveCode Server engine), but I do think a few simple GUI dialogs would make it much more useful and easier to do things like pick a color or select a bunch of files for some kind or processing. I think what it really needs is simply graphical implementations for 'Ask/Answer' that is Ask/Answer (with the normal options), Ask/Answer File/Files, Folder/Folders, Answer Color, Answer Record. Which are already syntactical abstractions of underlying system APIs.

I also think there's a lot of potential for StackSmith to be ported to Linux using Gtk or maybe even GNUStep (some of its code might even work unmodified in that case), the Hammer script dialect interpreter is not platform specific, and Uli designed the whole thing with portability in mind. My biggest question about StackSmith are licensing related, if it's an FOSS, GPL, BSD, or MIT license I would be willing to work on that effort. But that's a different topic.