In fact, there's no mention of anything I would call user interface elements, such as "button", "stack", or "field".richmond62 wrote: ↑Mon Aug 15, 2022 10:30 am Screen Shot 2022-08-15 at 1.30.55 PM.png
-
What am I missing?
tperry2x wrote: ↑Mon Aug 15, 2022 11:52 amIn fact, there's no mention of anything I would call user interface elements, such as "button", "stack", or "field".richmond62 wrote: ↑Mon Aug 15, 2022 10:30 am Screen Shot 2022-08-15 at 1.30.55 PM.png
-
What am I missing?
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?
I must have missed this thread a year ago when it started, but I'd still like to throw my two cents in here...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?
For what reason?I'd going to make the OpenXION Dictionary available online
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).richmond62 wrote: ↑Wed Dec 04, 2024 7:46 pmFor what reason?I'd going to make the OpenXION Dictionary available online
If the 'new' (i.e. non-LC) language terms are 'folded into' OXT, I can see a reason.
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).OpenXTalkPaul wrote: ↑Thu Oct 19, 2023 9:31 pm ...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
OpenXION has Python as an alternativeScriptingLanguage:
Code: Select all
do tMyUIScript as Python
put the result into tDialogResultCode: Select all
do tMyBashScript as BashCould you perhaps use the package:OpenXTalkPaul wrote: ↑Wed Dec 04, 2024 9:06 pm 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.
I'll look for that package, would be much easier than symlink manually, thanks.
Probably, but it would be better if linked to Python 3 since 2 is now pretty much dead now.Alternatively, can OpenXION be statically linked to a python 2 folder?
Haha, you say that, but the LCC engine when compiling makes heavy use of Python 2.OpenXTalkPaul wrote: ↑Wed Dec 04, 2024 9:21 pm Probably, but it would be better if linked to Python 3 since 2 is now pretty much dead now.
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.tperry2x wrote: ↑Wed Dec 04, 2024 8:45 pm 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.