OpenXTalk possible bugs, April

[tperry2x]

The following are tests done in Devuan Linux, (non systemd based distro) - I've also tried on xubuntu too (my second distro of choice).

When you launch Openxtalk, after the splashscreen, you get a revErrorDisplay dialog. Showing the message box, you get "Function: error in function handler." It's not the end of the world as you can just ignore it.

If you go to the "Help" menu > About OpenXTalk Community > the dialog that appears still mentions "2000-2022 Livecode Ltd" at the bottom left. (We could have something like, "(Formerly known as Livecode). OpenXTalk is a fully independent project.")

If you make a new project / stack and go to save it, the default file extension is ".livecode". If you remove the filename extension manually, and save, I noticed it uses the file extension ".otxstack".
Could OpenXTalk put ".oxtstack" extensions on automatically as default. I think it should possibly be oxtstack rather than otxstack to be consistent.

When building a standalone, in the "Standalone Application Settings" dialog, the user is still presented with a lime green banner that says "Did you know that if you want to close the source of your LiveCode applications you can do so with a LiveCode commercial license."
Perhaps get rid of this - but this raises another question. Is it possible to activate the closing-of-source in a standalone with OpenXTalk, as this is no longer affiliated with LC.

I'm using a dark theme in Devuan at the moment. The standalones I build are respecting the dark theme, however the only part of OpenXTalk that does not is the tools palette, which shows with a white background and dark icons theme. Again, not the end of the world - I merely mention it as it's something I noticed.

The start centre just displays an empty window at the moment. I know this may not yet have been implemented. I was wondering if we could have the Livecode dictionary handled within an OpenXTalk dialog, rather than loading in the user's default browser. This is the behavior on Mac and Windows if I recall correctly.

I'd say it looks like 90-95% almost there, and is definitely functional as an IDE. More importantly than that though, it represents the open community-spirited development of xtalk, rather than the closed nature that LC wants to steer towards.

So, although I'm finding these small adjustments here and there, I think it's amazing that OpenXTalk is where it is already.

[tperry2x]

(I would submit the above info to github, but I can't understand how Github works)
Not sure how I create a 'pull request'?? Whatever.
I'm probably just too dense to work it out.

It's over complicated and confusing, so I only end up looking for the 'releases' option and downloading what's on there. At that point, Github for me is reduced to a a simple http directory listing on a page, or even akin to an FTP directory.
But this is why I like Livecode, and not XCode / Visual Studio (Insert name of full-code IDE here).

[richmond62]

to activate the closing-of-source in a standalone

That would violate the Open Source licence.

[OpenXTalkPaul]

to activate the closing-of-source in a standalone

That would violate the Open Source licence.

That is correct as far as publicly releasing an OpenXTalk-built stack or standalone that is closed source.
That is anything released with it requires the source code to be released as well.
LC Ltd's has put forth on multiple occasions that their interpretation (as far as derivative works anyway) is the same as WordPress' interpretation (https://kinsta.com/learn/wordpress-gpl/), in that if a work could not have been created or is not functional without the original work, then it is a derivative work that is subject to that same license.

So conversely, if your xTalk scripts WOULD work in any other xTalk then, I guess, they are NOT derived from OXT LCC, and therefore NOT subject to the GPL license. Disclaimer: I'm not an IP lawyer. I would like to know if that's correct, I have scripts that I've developed in one xTalk and then much later on moved them to another xTalk, largely unchanged from the original content, and in fact I'm thinking of 'porting to another xTalk (XION). I've also developed GUI front ends for things like shell scripts and scripts that are really just wrappers for AppleScript (used via the 'do myScript as appleScript' syntax), things that could be done with alternative GUI / Engine kits. I wonder how those would land in regards to the licensing?

If you wanted to enable encryption for some other, perhaps completely private, personal use reason for something that you don't intend to release commercially or publicly, that is different.

I think it could be done with some GPLv3 compatible encryption method replacing whatever LC Ltd. uses. I don't think closed-source is at all beneficial to democratizing software dev or enabling a "anyone can code" scenario within a "programming for the rest-of-us" environment, and then there's also the LC Ltd. commercial alternative if you really wanted to release something commercially, with it's scripts encrypted.

[OpenXTalkPaul]

Here's an OXT ToDo List I put together last week:

First Priority
Add AVMIDI & AVAudioSampler stuff for mac (mac FluidSynth won't open the macOS system DLS GM bank)
Re-enable, add too "darkMode" make it cross-platform again (at least Linux & Mac), take out visual effect during change over
Add devGuides script-extension or Bernd's Guides plug-in and add IDE menubar & prefs guides integration too
Make all or most of the IDE Palettes sizable via stack scaleFactor prop
Sync default prefs with saved revPreferncesUI stack (darkMode,revMenubar)
Remove duplicate Piano Widget (ensure org.openxtalk.* id)
Include SF2 HyperSoundFonts (Piano,Harpsicoord,Boing) and smallest GM bank
Include FluidSynth controls demo stack, fix up FluidSynth docs
Update GeneralMusic lib to make PlayPMD command useable at IDE-wide at launch time (can delay init until when it's actually used first the first time)
replace the included blank "Startcenter" stack with OXT vers
Fix revTools-revMenuBar mouseLoc offset issue when their windows are overlapped
Fix Linux revTools-MsgBox-XFCE-problem
Add "Gather All Windows" to the "View" menu

Secondary Priority
Add more Cross-Platform MIDI I/O Options (like shell CLI calls for playing MIDI for example)
Make revTools/oxtTools IDE Palettes into tabbed palettes that can merge into each other's window
Add a few useful Widgets from Community and/or from lessons and demos
Add a "StyleSheets" saved property-set -setter palette
Add Font/Text styling tools palette
Make SVGIcon List palette, that places the selected SVG Icon inserted into an SVGIcon or Tile Widget when double-clicked (a single step action)
Add some more info, xTalk history and how OXT relates to LCC to the StartCenter, maybe add back in a 'recent stacks' list
Work on Adding Terry's xtalk-features demos to ResourceCenter with Folder / go stack in window
Work on modularizing ResourceCenter with Folder / go stack in window
Fix up Users Guide, re-enable launch menuitem
Make Dictionary fonts changable if possible, text is too large on small screens
Make revTools/oxtTools be all vector
Clean up Dictionary rebuild some, ensure no duplicate entries, include entry for LiveCode AND OXT, add others like OpenXION, StackSmith, Web/jsCard ///_Hyper stuff
Update GeneralMusic lib to include chordNames, chordFormula, circleOfFiths functionality
Inlcude Hunspell (and work on 'xTalk dictionary') and NSSpell?
Fix Linux Dictionary and inline "Extension Store" issues

Add new Library Called Linux Tools for things like getting the deskopEnvironment (GNOME,KDE,ETC)

[OpenXTalkPaul]

When you launch Openxtalk, after the splashscreen, you get a revErrorDisplay dialog. Showing the message box, you get "Function: error in function handler." It's not the end of the world as you can just ignore it.

"Function: error in function handler" Might it also say something about "ideCOntrol" (the cap-O is intentional) not found or something to that effect? There's definitely a bunch more work to be done as far as figuring out these issues on Linux, and there's so many more things to try to account for due to the open nature of the platform.
Script errors in stacks that load in the startup change can be difficult to debug, that usually fail silently and then whatever comes after it doesn't get loaded.

If you go to the "Help" menu > About OpenXTalk Community > the dialog that appears still mentions "2000-2022 Livecode Ltd" at the bottom left. (We could have something like, "(Formerly known as Livecode). OpenXTalk is a fully independent project.")

The copyright notice I believe has to stay. The source code for the engine Community engine is still copyright LiveCode Ltd. at least everything of it that was done up until Sept.1st 2021 is. That 2022 date must be inserted by script? I think is should say 2000-2021 Livecode Ltd.? And I don't think I've touched that bit since Oct. and I know I didn't change any dates.

If you make a new project / stack and go to save it, the default file extension is ".livecode". If you remove the filename extension manually, and save, I noticed it uses the file extension ".otxstack".
Could OpenXTalk put ".oxtstack" extensions on automatically as default. I think it should possibly be oxtstack rather than otxstack to be consistent.

Oh thanks, I did actually have this changed at one point but I may have lost some of that work when I messed up my SSD Drive partition tables back in Nov. I'll have to look into that again, I remember for some reason that change wasn't as straight forward as you would think (or that it should be).

When building a standalone, in the "Standalone Application Settings" dialog, the user is still presented with a lime green banner that says "Did you know that if you want to close the source of your LiveCode applications you can do so with a LiveCode commercial license."
Perhaps get rid of this - but this raises another question. Is it possible to activate the closing-of-source in a standalone with OpenXTalk, as this is no longer affiliated with LC.

The green color probably that the graphics asset didn't get updated.

I'm using a dark theme in Devuan at the moment. The standalones I build are respecting the dark theme, however the only part of OpenXTalk that does not is the tools palette, which shows with a white background and dark icons theme. Again, not the end of the world - I merely mention it as it's something I noticed.

Hmm that's odd, it works for me, including the Tools palette, with "Greybird Dark" and some other default dark themes. Try toggling the 'darkMode" checkbox that I added to the prefs window (under the 'appearance' pane)?

The start centre just displays an empty window at the moment. I know this may not yet have been implemented.

Yes there is a 'start center' stack that I've worked on that wasn't included in the .AppImage. In place of it is a 'forwarder' stack, so if you put a stack with the right name in the user's 'My OpenXTalk" folder, that will be loaded instead.

I was wondering if we could have the Livecode dictionary handled within an OpenXTalk dialog, rather than loading in the user's default browser. This is the behavior on Mac and Windows if I recall correctly.

IMO, the Browser Widget problems are the biggest issues I'd like to get worked out for Linux. And Yes, Linux builds are the only version that launch the Dictionary (cache) pages in an external browser app instead of in a stack with the Browser Widget. I think that originally a quick fix workaround, and there are other problems with the Browser Widget on Linux.

And thanks for the feedback. Much appreciated!

[tperry2x]

to activate the closing-of-source in a standalone

That would violate the Open Source licence.

That is correct as far as publicly releasing an OpenXTalk-built stack or standalone that is closed source.
If you wanted to enable encryption for some other, perhaps completely private, personal use reason for something that you don't intend to release commercially or publicly, that is different.

I think it could be done with some GPLv3 compatible encryption method replacing whatever LC Ltd. uses. I don't think closed-source is at all beneficial to democratizing software dev or enabling a "anyone can code" scenario within a "programming for the rest-of-us" environment, and then there's also the LC Ltd. commercial alternative if you really wanted to release something commercially, with it's scripts encrypted.

That makes perfect sense. Thank you both for clarifying.
It was just something that occurred to me when I saw that green banner when building the standalone. The far easiest way is to delete the banner about closing the source on the dialog. I have no issue or requirement to close the source myself, but might be something someone else would want to do.

[tperry2x]

I'm using a dark theme in Devuan at the moment. The standalones I build are respecting the dark theme, however the only part of OpenXTalk that does not is the tools palette, which shows with a white background and dark icons theme. Again, not the end of the world - I merely mention it as it's something I noticed.

Hmm that's odd, it works for me, including the Tools palette, with "Greybird Dark" and some other default dark themes. Try toggling the 'darkMode" checkbox that I added to the prefs window (under the 'appearance' pane)?

Yes, turning the 'Dark Mode' checkbox back on works. There's a weird fade kind of thing that happens when this gets toggled on, but it does work.

[tperry2x]

IMO, the Browser Widget problems are the biggest issues I'd like to get worked out for Linux. And Yes, Linux builds are the only version that launch the Dictionary (cache) pages in an external browser app instead of in a stack with the Browser Widget. I think that originally a quick fix workaround, and there are other problems with the Browser Widget on Linux.

And thanks for the feedback. Much appreciated!

No problem at all. Again, the dictionary cache opening in a browser isn't the end of the world, but I just mention as a nod towards a consistent approach with other platforms.

Glad to be of help

[tperry2x]

"Function: error in function handler" Might it also say something about "ideCOntrol" (the cap-O is intentional) not found or something to that effect? There's definitely a bunch more work to be done as far as figuring out these issues on Linux, and there's so many more things to try to account for due to the open nature of the platform.
Script errors in stacks that load in the startup change can be difficult to debug, that usually fail silently and then whatever comes after it doesn't get loaded.

It seems to be called from revMenuBar if that helps track it down.


it must be like hunting for a needle in a haystack, and I'm sure you probably keep finding things where you ask yourself "why on earth did they do it like that?" (or words to that effect)

[OpenXTalkPaul]

I'm using a dark theme in Devuan at the moment. The standalones I build are respecting the dark theme, however the only part of OpenXTalk that does not is the tools palette, which shows with a white background and dark icons theme. Again, not the end of the world - I merely mention it as it's something I noticed.

Hmm that's odd, it works for me, including the Tools palette, with "Greybird Dark" and some other default dark themes. Try toggling the 'darkMode" checkbox that I added to the prefs window (under the 'appearance' pane)?

Yes, turning the 'Dark Mode' checkbox back on works. There's a weird fade kind of thing that happens when this gets toggled on, but it does work.

That weird fade kind of thing that happens was one of my many attempts to use xTalk to simulate the changeover from dark <> light that macOS normally does to windows that it manages (stack windows I believe are a customized class), on my macOS IDE copy I've already taken that out for plain Lock Screen /unlock screen because it just didn't cut the mustard. The Linux copy wasn't up to date, the next AppImage will be more up to date.

[OpenXTalkPaul]

IMO, the Browser Widget problems are the biggest issues I'd like to get worked out for Linux. And Yes, Linux builds are the only version that launch the Dictionary (cache) pages in an external browser app instead of in a stack with the Browser Widget. I think that originally a quick fix workaround, and there are other problems with the Browser Widget on Linux.

And thanks for the feedback. Much appreciated!

No problem at all. Again, the dictionary cache opening in a browser isn't the end of the world, but I just mention as a nod towards a consistent approach with other platforms.

Glad to be of help

Cool, but the browser widget is used more than the just for the Dictionary. And it can be extremely useful to have a a properly functioning WebEngine that can enable communicating with JavaScript libraries. And it should work, at least on 64Bit Linux (I don't really think that 32bit is worth much effort at this point).
FYI, The Browser Widget in that first AppImage is broken, this is because there were libraries binaries that were left still compressed (due to GitHub size limits). but I uncompressed those and it now works running from my OpenXTalk.AppDir (which was used to build the AppImage). If you:

put 1 into $LIVECODE_USE_CEF

in your message box and then open the dictionary, you will see that even though the Browser Widget works, the Dictionary Stack that uses it is still broken for some reason, it only shows the tabs at the top, no web view.
But if I make an new stack with Browser Widget and point that to the Dictionary HTML cache index URL, it works fine (but then is missing the dictionary behavior scripts and such). I'd like to make some sort of QuickSearch/Syntax display from within the MenuToolbar, in addition to the regular dictionary, but that's a down-the-road thing.

[OpenXTalkPaul]

"Function: error in function handler" Might it also say something about "ideCOntrol" (the cap-O is intentional) not found or something to that effect? There's definitely a bunch more work to be done as far as figuring out these issues on Linux, and there's so many more things to try to account for due to the open nature of the platform.
Script errors in stacks that load in the startup change can be difficult to debug, that usually fail silently and then whatever comes after it doesn't get loaded.

It seems to be called from revMenuBar if that helps track it down.


it must be like hunting for a needle in a haystack, and I'm sure you probably keep finding things where you ask yourself "why on earth did they do it like that?" (or words to that effect)

It does help.
And yup there is a bit of that, it's like following the bouncing message as it makes three seemingly inexplicable stops along the message path.

[OpenXTalkPaul]

It seems to be called from revMenuBar if that helps track it down.


it must be like hunting for a needle in a haystack, and I'm sure you probably keep finding things where you ask yourself "why on earth did they do it like that?" (or words to that effect)

I can't find "ideCOntrolTypes" anywhere in the IDE, but maybe that's the problem? At least it doesn't seem to effect anything.

It may just be that I was experimenting with and then saved the message box stack with that result in the result field so that it appears every time it's first opened in the IDE?
Have to be extra careful when saving IDE binary stacks because everything gets saved along with the scripts (stack window size, screen position, etc.). I know from experience that can be a problem if you open a stack that was last saved on a computer with a 5K ("Retina") display while the stacks was positioned on the right side of the screen and then open it on an old 1024x768px display.
At any rate I've resaved the message box stack and I'm not seeing that message any longer... and I can't find a single reference to ideCOntrols anywhere.

[tperry2x]

It may just be that I was experimenting with and then saved the message box stack with that result in the result field so that it appears every time it's first opened in the IDE?

At any rate I've resaved the message box stack and I'm not seeing that message any longer... and I can't find a single reference to ideCOntrols anywhere.

That sounds like it's quite possibly the case. Fingers crossed.

Would a fix for any floating windows that may be positioned outside the screen, be something like:

Code: Select all

if the right of wd [name of wd] > item 3 of the screenrect then set the right of [name of window] to item 3 of the screenrect

[OpenXTalkPaul]

It may just be that I was experimenting with and then saved the message box stack with that result in the result field so that it appears every time it's first opened in the IDE?

At any rate I've resaved the message box stack and I'm not seeing that message any longer... and I can't find a single reference to ideCOntrols anywhere.

That sounds like it's quite possibly the case. Fingers crossed.

Would a fix for any floating windows that may be positioned outside the screen, be something like:

Code: Select all

if the right of wd [name of wd] > item 3 of the screenrect then set the right of [name of window] to item 3 of the screenrect

Yes, I think something like that would work in a repeat loop checking every Window or at least the every IDE stack window. I also think it would be useful to have some more options in the View menu, such as "Collect all windows" to stack all windows to the top left of screen 1 and make sure the bottom right fits within that Screen's Rect, because I've made stacks that were sized too big for the current smaller screen and couldn't fix them manually because the bottom right was off the screen (had to make a script to fix). Perhaps we add some others options too like "Tile windows" where it would split the screen into evenly divided rects and then fit the Stack Windows into those rects.

BTW, I've fixed the saving/save as file naming so it will use oxtstack or oxtscript (oxt NOT otx!) instead of .livecode or .livecodescript. Currently the only purpose in having OXT file .extentions is to allow for operating systems to launch OXT instead of LCC or LC if those are also installed. I suppose down the road we could make actual file-format changes if there's a good reason to.

I've also tracked down and fixed a bug in the Extension Manager that's been annoying me for a long time. The sample stacks that can (but not always) come with builder Widgets or Libraries would not open when you selected them from the pop-out menu in the extension list (v9.0 and above). Often these sample stacks come with Libraries and provide a Demo of how to use the Library's handlers, so that's pretty important.

[tperry2x]

I also think it would be useful to have some more options in the View menu, such as "Collect all windows" to stack all windows to the top left of screen 1 and make sure the bottom right fits within that Screen's Rect.

Perhaps we add some others options too like "Tile windows" where it would split the screen into evenly divided rects and then fit the Stack Windows into those rects.

I like the idea of having a way of arranging windows with an option. Perhaps options to arrange, tile, or list all open project windows (I've placed buttons on the toolbar in this mockup, but could be a Menu to save space).


I also just noticed the Script Editor window also is not aware of the dark mode theme setting. Again, not a huge problem, but just a visual quirk.

[tperry2x]

BTW, I've fixed the saving/save as file naming so it will use oxtstack or oxtscript (oxt NOT otx!) instead of .livecode or .livecodescript. Currently the only purpose in having OXT file .extentions is to allow for operating systems to launch OXT instead of LCC or LC if those are also installed. I suppose down the road we could make actual file-format changes if there's a good reason to.

I've also tracked down and fixed a bug in the Extension Manager that's been annoying me for a long time. The sample stacks that can (but not always) come with builder Widgets or Libraries would not open when you selected them from the pop-out menu in the extension list (v9.0 and above). Often these sample stacks come with Libraries and provide a Demo of how to use the Library's handlers, so that's pretty important.

That's great news - exploring the sample stacks is one of the first things new users to OpenXTalk will likely do, so if things are broken there, they would notice it and it might give them a negative impression.

This is one for the wish-list. (Perhaps we need a wish-list section), although not meaning to make lots of extra work.
I'd love to see something like an externals wizard.
What I mean by this, is a window that opens that can list pre-approved externals (XCMDs / XFCNs back in the day), which can provide extra functionality. (Something such as the XCMDs that used to be available like Rinaldi's externals), so it could show a window for all externals for the current operating system?

We just then need some talented XCMD builders. There was always loads of extra functionality that could be added to Supercard, Hypercard et-al with these.

[tperry2x]

I'm thinking of externals which provide functions (on all platforms) such as:

Code: Select all

GammaFade(in/out,durationinticks)

Code: Select all

GetResolution

Code: Select all

SetResolution

Code: Select all

Play(soundfile, pitch/notes, tempo)

Code: Select all

7ZFile(filename,destination)

Code: Select all

Un7ZFile(filename,destination)

(I mention 7Z as I think it's open source, so would be a universal way to add a compressor, decompressor into OpenXTalk)

Code: Select all

ReverseString(thestring)

Code: Select all

GetFrameRate

Code: Select all

SetFrameRate

Code: Select all

Put ShellNonBlock("ls -a -r ~/") into cd fld "output"

(Non-blocking shell commands)

Integration with other languages:
I'm aware you can obviously run shell commands with:

Code: Select all

get shell("mkdir ~/test")

and run Applescripts with:

Code: Select all

do script (myvariable) as applescript

but, would it be possible to:

Code: Select all

do script (myvar) as pythonscript

Code: Select all

do script (myvar) as rustcode

Code: Select all

do script (myvar) as javascript

Code: Select all

do script (myvar) as parsePHP

Also, simplification of the network packets and sockets would be good.
Something like:

Code: Select all

SendNetworkData(ipaddress, port, TCP/UDPprotocol, thedata)

and

Code: Select all

get SendNetworkData(listening-for-ipaddress, listeningport, thedata)

And, while I'm there:
GetTotalBytesOfFile(pathtofile)
SendNetworkFile(ipaddress, port, TCP/UDPprotocol, entirefile/bytes-from-and-to)
GetNetworkFile(ipaddress, port, TCP/UDPprotocol, entirefile/bytes-from-and-to)

This could be handled through an external, or perhaps a code addition to OpenXTalk itself, which could go in the dictionary?
Sorry - I'm aware I'm throwing these ideas out here and there, and I understand if they are not achievable.

This is probably all a bit pie-in-the-sky

[OpenXTalkPaul]

I've also tracked down and fixed a bug in the Extension Manager that's been annoying me for a long time. The sample stacks that can (but not always) come with builder Widgets or Libraries would not open when you selected them from the pop-out menu in the extension list (v9.0 and above). Often these sample stacks come with Libraries and provide a Demo of how to use the Library's handlers, so that's pretty important.

That's great news - exploring the sample stacks is one of the first things new users to OpenXTalk will likely do, so if things are broken there, they would notice it and it might give them a negative impression.

This is one for the wish-list. (Perhaps we need a wish-list section), although not meaning to make lots of extra work.
I'd love to see something like an externals wizard.
What I mean by this, is a window that opens that can list pre-approved externals (XCMDs / XFCNs back in the day), which can provide extra functionality. (Something such as the XCMDs that used to be available like Rinaldi's externals), so it could show a window for all externals for the current operating system?

We just then need some talented XCMD builders. There was always loads of extra functionality that could be added to Supercard, Hypercard et-al with these.

I just meant in the Extension Manager window, which is very similar to what I think you're looking for, except that it only manages Extension Builder Extensions, which are basically meant to replace Externals (The RunRev equivalent to XCMDs/XFCNs). The difference between externals and extensions is that you don't need any external development tools or languages to make them. You code them in Extension Builder (LCB=LiveCodeBuilder) language and compile them into intermediary bytecode from the Extension Builder stack. Builder language is similar to LiveCode Script with some differences and additions, such as strictly typed variables and metadata syntax.

BTW, I have great respect for Frederic Rinaldi, he practically single-handedly kept HyperCard useful for me at the same time that Apple/Claris were letting it stagnate, and inspired me to learn to build XCMDs/XFCNs back when (I only ever publicly released one of those, called CursorDo, built with FutureBASIC).

I'll try to go through your wishlist later.