OpenXTalk Linux Tools Library proposal

[OpenXTalkPaul]

This stack is helping and I'm adding to it a little.
I've added handler to get the current default File Manager's name, (returns Nautilus,Dolphin,Caja,etc.)

Window manager:
"Name: Metacity (Marco)"
Seems to play nicely.

Maybe I should take back what I've said in previous post.
After I posted that, I also played with GNOME classic which says GNOME-shell is the Window Manager.
I also opened up the other two browser instances I've used within and as part of the IDE, OXT Web Playground and OXT Repo (Extension 'store') in the Extension Manager tabs, and they actually work fine after a slight delay to download the content from GitHub, while the revDictionary stack pulling it's page from local files does not.

It seems that the Browser Widget isn't actually the whole of the problem, it seems to be window mode conflict (just like the window focus problems).
I've tried modeless and other window modes on that stack, it must be something else that's causing a conflict?
Oh you know what I just realized that my .desktop icons on my desktop no longer point to valid URLs even though I know those directories still exist, so it seems like jumping from one desktop environment to another can screw things up system wide. Maybe the same problem is causing Browser Widget to not find its cache of pages?

[tperry2x]

Having another go at video playing in OXT, just because the amount of dependencies is a bit much to have to install.
I mean, it works, but I can't help feeling there's a better way for linux.
So I've been playing - this is version 4 of a linux video player. (offering a few options now)

screenshot.png (30.58 KiB) Viewed 2964 times

It's still not bound to a stack window, but it's an alternative method and only needs mplayer to work (or vlc if you choose that option) - but mplayer is behaving better with this test stack.

Wondering if we can include some of this in your Linux assorted goodies library Paul?

[OpenXTalkPaul]

I'm definitely interested in having working full range of multimedia capabilities on Linux,
but for this library what I had in mind was more like the Linux equivalent to macOS Native Tools, and by that I mean limited to handlers related to making our non-'Native' engine and standalone apps look and behave like the rest of the apps on the system (of course that's not so easy with Linuxes) or that facilitate interacting with common system components like its Window Manager, File Manager, Desktop Envirnmoent ( Workspaces, Docks/Panels,), etc. I think something like "Video Tools Library" or "Multimedia Tools" would be a better location for employing various Video tools or APIs, because many of those tools are cross-platform, not limited to Linux. MPlayer, FFMPEG. VLC, etc. all work essentially the same way on macOS and Windows as well.

After some more testing, I'm going to say that IceWM with DE is out of the running, the Browser Widget works somewhat, but there's all sorts of other graphical layering glitching. In this screen I'm not in mid-drag-drop, that Bowser Widget instance got "placed" into thin air, outside of any window surface and remained floating there even after exiting the IDE!

quickshot_241127_091555.png (621.01 KiB) Viewed 2917 times

Some window managers show the window object class name rather than the Windows Title, exposing some Engine internal 'branding'.

Screenshot from 2024-11-27 09-31-40.png (34.7 KiB) Viewed 2917 times

In some window managers, like I've said, you get a dual window result from 'native layer' Widgets (and Player control). If you don't know what I'm talking about here's a screen to illustrate:

Snapshot_2024-11-25_12-18-44.png (327.44 KiB) Viewed 2917 times

See the blacked out window behind the Dictionary stack is where the Chromium Embedded Browser is actually doing it's thing and THEN it passes its rendering to our engine / stack window. Notice the name of that extra window in the wmctr - l list field is named 'N/A".

[OpenXTalkPaul]

So far for me the Window Managers for XFCE (xfwm) and KDE Plasma (KWin) have been the most compatible/stable when trying to use browser widget or externally rendered 'Native Layer' widgets on Linuxes.

[OpenXTalkPaul]

I've been looking into the Browser Widget problem on Linux again lately. With a compatible Window Manager the Browser Widget does 'work' but the problem then is a keyboard-focus issue, Keyboard input 'works' on page load, but as soon as you click on something else within the page, outside of the focused text input, the keyboard input focus is lost, and the only way to get it back is to reload the page (not a real solution). Which is why I've been experimenting using window manager to try to refocus the window, which now I've realized is NOT the problem.

One thing I learned for sure is that our thing here is not the only thing that has had this problem with keyboard focus with the embedded browser view. Here's a small list of some of very similar problems developers reported on the CEF forums:
https://magpcss.org/ceforum/viewtopic.php?f=6&t=13037
https://magpcss.org/ceforum/viewtopic.php?t=15423
https://www.magpcss.org/ceforum/viewtop ... =6&t=10900
https://magpcss.org/ceforum/viewtopic.php?f=17&t=17305
https://bitbucket.org/chromiumembedded/ ... quests/202
https://www.magpcss.org/ceforum/viewtop ... =6&t=16763
https://magpcss.org/ceforum/viewtopic.php?f=6&t=19388
https://magpcss.org/ceforum/viewtopic.php?f=6&t=18797
https://www.magpcss.org/ceforum/viewtop ... =6&t=20023
https://magpcss.org/ceforum/viewtopic.php?f=6&t=14568
https://www.magpcss.org/ceforum/viewtop ... =6&t=13813
https://magpcss.org/ceforum/viewtopic.php?f=6&t=13891
https://www.magpcss.org/ceforum/viewtop ... =6&t=16458

I've looked at the LCB source for Browser Widget. That is not very helpful because that is basically a very thin wrapper around the engine's 'Browser Factory' routines. MAYBE if I can find out what in the Browser Factory part of the engine makes keyboard focus work correctly on the initial page load then MAYBE we can call that routine directly via FFI bindings in Extension Builder without reloading the web page, which we do not want to have to do.

For awhile I was thinking it could be solved by using some JavaScript executed from within the context of inside the Browser's page, which could focus on the inputs DOM object properly but didn't re-enable text input to that input object after keyboard input focus had been lost.

It could very well be that this problem can not be solved without at least making some modifications to the 'Browser Factory' in the Engine source. At which point it might be better to try to translate the code for macOS Browser Widget that uses Apple version Webkit view to code that can do the same with a WebKitGTK view on Linux and while we're at it do WebView2 w/ MS Edge webkit engine for Windows), which is what LC once said they were going to do (but it seems that is now vaporware).

I tried to test the older External version of using the Browser Factory (called revBrowser or revBrowserCEF, prior to that called xBrowser ) but that doesn't seem to work at all, gives me a script error like that external is not loaded). Maybe we could test out some older versions of LC Community like v7 (pre-widgets). I mean it must have worked correctly on Linux at some point, right?

For Linux at least think I'm going to change to open Dictionary by default in the system default external browser (where focus works fine, so it's not the webpage code at fault), and perhaps also add stack-based Dictionary viewer (but to me, that must support dynamic loading new entries).

[tperry2x]

...and perhaps also add stack-based Dictionary viewer (but to me, that must support dynamic loading new entries).

Just as it can easily get missed on these forums, I have mentioned (somewhere, if I can find it), that the text-based version of the dictionary does support dynamic loading of new entries.
Just that they are text files, not SQL databases. My intention would be when something is installed that needs custom dictionary entries, the text files get copied to:
[path to dictionary stack]/exports/xtalk/plugins/

They'll then be available as custom dictionary entries in the text dictionary.

[OpenXTalkPaul]

Just as it can easily get missed on these forums, I have mentioned (somewhere, if I can find it), that the text-based version of the dictionary does support dynamic loading of new entries.
Just that they are text files, not SQL databases. My intention would be when something is installed that needs custom dictionary entries, the text files get copied to:
[path to dictionary stack]/exports/xtalk/plugins/

They'll then be available as custom dictionary entries in the text dictionary.

I do recall you mentioning that, I just think that would be better it it could simply look into each extension directory (there's two Extension directories, IDE Included Extensions and User Installed Extensions), pulling in the text from an extensions already existing text file: API.lcdoc only stripping of the 'lcdoc' markdown formatting when displaying the contents if need be, I suppose I could work on making it do that. I do like the concept of mainly using plain old text files over SQL or JS/JSON (used in the Web Browser version), keeps things nice and simple, I just don't want extension loading to get broken. Modifying the Extension Manager library is also an option, we could have that output the plain text file when an extension is loaded.

[OpenXTalkPaul]

For Embedded Browser, I kind of feel like if you need a lot of interaction with HTML DOM objects, JS routines and Web APIs, at some point you might as well just run the thing inside of a web browser, perhaps including an xTalk<>JS intepreter of some kind, either using the Emscripten port of the engine, or something like HyperCard Simulator's 'engine' (which is a much much smaller download than the Emscripten engine), and then run that in Electron or similar if you need it to run as an offline 'Desktop App'.

[richmond62]

the text-based version of the dictionary does support dynamic loading of new entries

You bet:
-

richmond.jpg (183.62 KiB) Viewed 2450 times

-
Oh, Blast! I forgot to add that bit about his incredible modesty.

[tperry2x]

Haha, I like it.
Joking aside though, this illustrates what I'm going on about; where the text version of the dictionary really opens it up to editing, for everyone.

With the Attributions idea (hang on, let me reference it in the right topic...)

[tperry2x]

Maybe we could test out some older versions of LC Community like v7 (pre-widgets). I mean it must have worked correctly on Linux at some point, right?

There's no browser option in LCC v7 at all. Was that something they added in 8?

[OpenXTalkPaul]

Maybe we could test out some older versions of LC Community like v7 (pre-widgets). I mean it must have worked correctly on Linux at some point, right?

There's no browser option in LCC v7 at all. Was that something they added in 8?

There was/is an (not-a widget) external called revBrowser for Mac and Windows at least, I thought it was available on Linux as well (I could be wrong?).
Apparently it was an external called xBrowser prior to that.
https://livecode.fandom.com/wiki/RevBrowserOpen

This is the source code from 2011 that shows a file with Lnx (linux) in there:
https://github.com/livecode/livecode/tr ... revbrowser
Again, that's an external and it was indeed a part of v7, not exactly the same thing as the Browser Widget, although it has mostly the same functionality as the Browser Widget version, they both use the Engine 'Browser Factory" under the hood.

Here's one option the Browser Widget version doesn't have:
https://livecode.fandom.com/wiki/RevBro ... TextBigger

Oddly enough the Mac version of v7 used Chromium Embedded (compiled for 32bit only) as its web engine instead of WebKit (Safari engine) but they switched it on Mac to use WebKit when v8 came out (64 & 32bit Engine build).

[tperry2x]

There was/is an (not-a widget) external called revBrowser for Mac and Windows at least, I thought it was available on Linux as well (I could be wrong?).

Ah, found it. That produces a script error when the stack is opened (standard, unmodified LCC 7.0)

2024-12-05-06-15-55.png (253.52 KiB) Viewed 2173 times

[OpenXTalkPaul]

There was/is an (not-a widget) external called revBrowser for Mac and Windows at least, I thought it was available on Linux as well (I could be wrong?).

Ah, found it. That produces a script error when the stack is opened (standard, unmodified LCC 7.0)
2024-12-05-06-15-55.png

Yeah same here, It's probably compiled for 32bit (?), so it's not going to be ABI compatible with 64bit engine (POSIX sub-process must be compiled for same architecture as the binary that launched it). I'm pretty sure it worked for me back when (8 years ago or so), and I'm pretty sure the arm6 32bit build worked on RPi 2B+ Raspbian (when I had one).

[tperry2x]

...I'm pretty sure it worked for me back when (8 years ago or so), and I'm pretty sure the arm6 32bit build worked on RPi 2B+ Raspbian (when I had one).

Probably the case, the same with pretty much everything engine-related here.
It was great at the time, and worked well back then - as it was designed to run on those systems. However it's not been maintained or updated to keep pace with modern systems and newer hardware.

So all these engines:
Stacksmith =objective-c only, won't compile on any modern MacOS (and is MacOS only)
Metacard =no intel OSX version (& linux version missing unresolvable dependencies), works fine via wine though.
OpenXion =Java, but no GUI, so limited use compared to anything with a GUI. (OS X 10.9 didn't come with Java, because Apple had a fall out with Oracle at the time).

The only viable one at the moment, with a GUI, that compiles (*almost on MacOS) is the LCC engine, which for all it's many faults, is sadly the best we have at the moment.

*I'm making in-roads into compiling for MacOS, but it's slow going. It'll help when a newer mac arrives - which is in the pipeline.

Yes, I was contemplating making my own rewrite in C++ from the ground up, but I'd be 70+ by the time I got near to Metacard capability. A complete rewrite of the engine is just too big a task I'm afraid. That's even if I had the skills to do it. I'm still learning C++ and would class myself as a newbie there.

I would love for someone to come along out of the blue, and drop a fully open-source engine into our laps, which supports everything you'd care to create in LCC 9.7.0-dp-1 (with fixes).... but what are the chances?
I'd also love a set of winning lottery numbers, which is equally as unlikely.

[continued engine rantings here]

[OpenXTalkPaul]

Stacksmith =objective-c only, won't compile on any modern MacOS (and is MacOS only)

The only viable one at the moment, with a GUI, that compiles (*almost on MacOS) is the LCC engine, which for all it's many faults, is sadly the best we have at the moment.

That's not true, I compiled StackSmith from Source into a working app (on macOS 11 iirc), and it was super fast and easy, no errors at all in XCode. (sure the thing is a little buggy, it could use some work, but it did compile and run quite easily)

Also StackSmith is written in C++, but you HAVE TO use Objective C (or on newer macOS you can use Swift) in order to use most Apple's API objects like NSButton, NSMenu, etc. (some APIs like Core Audio are written in C). LC uses some Objective C in the mac engine too (see the Sonoma Menu Bug).

Theoretically Objective C is cross-platform if you use GNU Step frameworks which are partially compatible with Apple's Cocoa frameworks that they've been modeled on (originally it was the reverse when Apple first bought NeXT).

StackSmith's Hammer interpreter is not platform specific..
The only thing is the licensing is unknown.

I just found OpenXION v1.1 was MPL 1.1 license, which free software foundation discourages using because it was likely not GPL compatible MPL 2.0 is however, I'm not sure if she ever updated the license.

[tperry2x]

I'm probably being stopped because I'm using an older MacOS. Hopefully that will change soon though.
So how would you go about getting this to build on windows or Linux? That's not a flippant or loaded question. As far as I'm aware, that would need a lot of changes?

[OpenXTalkPaul]

I'm probably being stopped because I'm using an older MacOS. Hopefully that will change soon though.
So how would you go about getting this to build on windows or Linux? That's not a flippant or loaded question. As far as I'm aware, that would need a lot of changes?

Ah yes now I recall the minimum OS versiion for StackSmith I think is 10.13 (or maybe it was 10.14), that might be because he's using the newer multimedia APIs (https://developer.apple.com/documentation/avfoundation).

I would imagine it would be a lot of work to get any alternative up to a comparable level to OXT ( if that is the goal ), but it could be worth the effort, it could be a big help if we can find a good base to work from that is FOSS and has liberal license.It could be fairly easy to substitute GTK controls for the Objc C ones, i don't know.
Probably go in a thread about StackSmith

[tperry2x]

Well, what is apparent is that I'm not up to the task of writing (re-writing) an entire engine.
It's just too much of a complex task, and my C++ skills aren't up to much. (Objective-C even less so).
I'll leave that to the professionals.

Having said that, I've not given up on getting the mac version to compile. That's my own personal headache though it seems

In the meantime, I'll just focus on tweaks to the IDE in our legacy LCC engine, with the hope that whatever engine we jump to in the future - that this work will be largely transferrable. (I know, that's a stretch right? )