Known Bugs

[OpenXTalkPaul]

So I'm working on a widget with feature parity to the classic 'button' which means I've been spending time looking at our 'classic button' control in detail lately. I found a bug I haven't seen reported before, it may have been more like an intentional deprecation. There's no Property Inspector menu item for the button style 'oval'.

Make a new stack with a new button then in the message box do:

Code: Select all

set the style of btn 1 of the topstack to "oval"

Screen Shot 2024-08-24 at 5.42.23 PM.png (104.7 KiB) Viewed 5137 times

Oval button style is built in to the engine, but there's no way to created it from the IDE GUI. Oval Graphic would be better looking with antialiasing on, but Graphics can't have a icon with 'gravity' like buttons can.

It has a rather pixelated edge, and being a 'classic button' you can not enable antialiasing to try to make the edges look smooth. Also the border is functional but weird, but that could be that it just needs a default properties set that's appropriate for it.

The button on the top right is actually a widget, and it has antialiasing on. You can see a difference in the way the side lines of the 'stack' icon is rendered.

[tperry2x]

Just posting this in the known bugs section, more as a reminder for myself than anything.
Reported by Neville, weird issues with revmenubuilder.

[tperry2x]

The plot thickens.

In LCC 9.x the Linux "Player" object is broken.
However, this is NOT completely the case in LCC 7.14 for Linux x64

Providing you install the necessary dependencies, then it will indeed play back the video.
I'm testing this in LCC 7.1.4 for Linux in this screenshot.

video-linux.png (241.35 KiB) Viewed 508 times

video.livecode

(2.27 KiB) Downloaded 6 times

So then it makes me wonder if I can isolate the "Player" subroutine from the LCC 7.1.4 Linux engine, and place that into the LCC / OXT Lite (9.6.3 / 9.7.0-dp1) engine...

If I can't, then a cunning plan-B I have is to create a player binary from the LCC 7.1.4 IDE, which can be controlled via the 9.6.3/9.7.0-dp1 engine of OXT lite, so it'll be like a scriptable binary which you can issue player commands to via xtalk script. That would get around the issue of a broken player for Linux.

If you are on Linux, and have those dependencies installed, you can download the test video binary from here.

Edit 1:
Unfortunately this isn't a 100% magic bullet.
The issue is, as far back as LCC 7.x, seems to be that it calls GTK in a depreciated way. Hopefully that helps someone debug it?

no-magic-bullet.png (15.84 KiB) Viewed 481 times

Edit 2:
Although that error is triggered, turns out it's not fatal and not what is causing the lockup in the IDE in Linux.
That can be caused by the engine recursively seeking out mplayer. If mplayer isn't installed, it doesn't exit gracefully with an error - it just goes into a loop. With mplayer installed, success (can't believe I missed that) - but I changed distro and that doesn't have mplayer as default.

doh.png (315.28 KiB) Viewed 470 times

So now, next move is not to include all those dependencies and libraries - as it'd add 240ish MB to the download size of OXT Lite. Rather, I think I'll have an option such as:

to-add.png (29.14 KiB) Viewed 465 times

I'm thinking about making the video.bin (which is an externalised C++ player currently), possibly an appimage instead (eventually). That way, if these libraries ever disappear - we won't be stuck for video playback support as they can be included.

None of this is an easy fix though, but at least it seems to work.

However, all the required dependencies seem to be being maintained at the moment, and are in mainstream repos.
You can check if you have all the required dependencies using this stack:

OXT-vid-deps.png (22.7 KiB) Viewed 456 times

OXT-vid-deps.oxtstack

(4.44 KiB) Downloaded 7 times

I may be able to refine this down further, for example - I don't think you'd need automake necessarily.

[OpenXTalkPaul]

If I can't, then a cunning plan-B I have is to create a player binary from the LCC 7.1.4 IDE, which can be controlled via the 9.6.3/9.7.0-dp1 engine of OXT lite, so it'll be like a scriptable binary which you can issue player commands to via xtalk script. That would get around the issue of a broken player for Linux.

I like that idea, it could even be packaged as an extension (because then it makes it easy to deploy it along with your standalones) which would runs it as a subprocess from its resources folder.

I might try to squeeze some time to do a proof of concept with an app wrapped as an extension, like a command-line tool.

If mplayer isn't installed, it doesn't exit gracefully with an error - it just goes into a loop. With mplayer installed, success (can't believe I missed that) - but I changed distro and that doesn't have mplayer as default.

Is there any reason we can't just include mPlayer (or similar) along with the IDE? I don't think it would even be as big as Chromium CEF, even with all the dependencies included.

[tperry2x]

I like that idea, it could even be packaged as an extension (because then it makes it easy to deploy it along with your standalones) which would runs it as a subprocess from its resources folder.

Yes, that was my thinking. In that respect, it's no different than something else you might have to add - like the JDK toolkit for Android deployment - just an addon that you download (which we / I could obviously host if we had to one day - if the repositories 'go away').

Is there any reason we can't just include mPlayer (or similar) along with the IDE? I don't think it would even be as big as Chromium CEF, even with all the dependencies included.

I'll just see how large a download all those dependencies might be...

After a bit of refinement, I can get the amount of libs required down to 57MB, so not too bad as an add-on.
I can cut this down even further, to just the minimum video dependencies (23MB).

refined-further.png (59.61 KiB) Viewed 434 times

I didn't necessarily want to force any dependencies on anyone's system, so instead - a button in the IDE asking to download the required dependencies would be better in my opinion.

I have also backed up those dependencies as they are, just in case...

[richmond62]

Is mPlayer preferable to VLC?

[tperry2x]

Is mPlayer preferable to VLC?

Depends who you ask. VLC is more versatile perhaps (more codecs), but mplayer is more standardised.
The only advantage to using mplayer is that the engine won't need recompiling to deal with it, so it's easier if we can just get the built in mplayer function to work as it should. (which I'm nearly there on - although want to test on various other distros to be sure).

[richmond62]

more standardised

What does that mean?

I run VLC on MacOS, Xubuntu, Debian 32-bit, and Devuan: I belive there is also a version for Haiku.

Oh: TANGENTIALLY: erm, Haiku . . .

https://www.haiku-os.org/

Depending on who you listen to and what you believe, Haiku might be the "coming thing", and porting OXT (lite) to it mu=ight be a good thing.

Certainly it looks a better bet than ReactOS (and at least they have had the good sense to get out of Russia):

https://reactos.org/

Although, at least, there is a chance that the Windows version of OXT Lite will run on ReactOS without any mods.

[tperry2x]

What does that [standardised] mean?

You can find mplayer binaries going back to early versions of MacOS and also in various projects in Windows. They don't normally bundle VLC as it's a bit more third-party.

I run VLC on MacOS, Xubuntu, Debian 32-bit, and Devuan: I belive there is also a version for Haiku.

Yes, I mean - I know it exists for pretty much anything - and I am a fan of it.

Depending on who you listen to and what you believe, Haiku might be the "coming thing", and porting OXT (lite) to it might be a good thing.

Yes, but probably not very likely. I say that as in theory, the MacOS and Windows versions of the engine already exist... and yet... we are where we are with them. Neither will currently compile to my knowledge. Trying to recreate the engine for what is essentially a completely bespoke OS - not based on anything, with it's own unique Kernel, will take a long time. What the Haiku team have done so far is fantastic, but it's not going to happen overnight and probably not at the top of their priority list - even if we were to beg. It would tie up a lot of time.

Certainly it looks a better bet than ReactOS

Yes, I think Wine has surpassed that in functionality a long time ago, without needing a whole other 'os' based around it.

Although, at least, there is a chance that the Windows version of OXT Lite will run on ReactOS without any mods.

I don't know if you spotted it previously, but wine on Haiku runs OXT Lite 1.07 without a hitch on my test system. (Was sketchy in a VM - better on real 'bare-metal' hardware).

[OpenXTalkPaul]

Both VLC and mPlayer use a bunch of libraries to do what they do, I believe they have some of those dependencies in common.

https://wiki.videolan.org/MPlayer/

There are common elements between VLC media player and MPlayer, and the two projects share at least one contributor (Diego Biurrun). VLC reuses the MPlayer swscale software scaler library (included with FFmpeg) and MPlayer can be extended with the VideoLAN x264 library. libdvdnav and libdvdcss were included with MPlayer until 1.2. VLC and MPlayer both currently use FFmpeg to support many codecs, and work is done to keep MPlayer, VLC and FFmpeg codec support in sync.

FFMPEG nowadays includes its own player (FFPLAY), it also includes a video serving thing so you can stream your viddies to your TV or whatever.

FFMPEG can do a heck of a lot more than just play video, it can edit, convert to different video formats for examples, Combined with libdvdnav and libdvdcss many a DVD library was 'ripped' to divx/xvid.avi or .mp4 files, back when people did that sort of thing that is

I'd love to have a library that wraps all of its functionality for xTalk scripting.

[richmond62]

I don't know if you spotted it previously, but wine on Haiku runs OXT Lite 1.07 without a hitch on my test system. (Was sketchy in a VM - better on real 'bare-metal' hardware).

I did, and also know about a man trolling around in a frock trying to pass oneself off as a woman:
very, very quickly the sh*t is going to hit the fan.

A native Haiku build of OXT that can spin off native Haiku standalones would be a BIG thing.

A Hijra is not a Woman, whichever way you look at things: sorry.

https://en.wikipedia.org/wiki/Hijra_(South_Asia)

[tperry2x]

I also know about a man trolling around in a frock trying to pass oneself off as a woman:
very, very quickly the sh*t is going to hit the fan.

? Not sure what you mean, but a native Haiku build of OXT that can spin off native Haiku standalones would be a BIG thing to attempt to put together.

We have to work with what we have, and at the moment, via wine is the only way to run it on that OS.

Haiku is not Linux, nor is it Unix. It's closer to BeOs - or more accurately, the NewOS kernel. Generally code written for BeOS will run in Haiku. Even if we had a department / team of BeOS coders, I wouldn't expect to see anything for months on end. However, we don't have that so....

[richmond62]

That is exactly why I used

a BIG thing

so I would not even mention Haiku OS as any sort of target.

Running things on WINE is running things on WINE: good as far as it goes, but, like the bloke in a frock, not the real thing.

[tperry2x]

I didn't mention it as any sort of build target. merely to see if OXT Lite could be made to run on there one way or another.
Wine is just a compatibility layer, in the same way that Rosetta, Whiskey or Box86 is.
I wouldn't be too dismissive of those kinds of approaches - it might be the only way we have to run it in MacOS one day.

[richmond62]

Just trying OXT Lite Windows on MacOS 15 with WINE and got this:
-

SShot 2024-10-01 at 16.26.30.png (265.22 KiB) Viewed 374 times

-
Obviously those references to LiveCode need to go.

Um: Just 'xTalk files' perhaps?

[tperry2x]

Obviously those references to LiveCode need to go.

Why? I don't know how you reached that conclusion.
If a user only has OXT Lite installed, they'd want livecode files associated with it too. They can just choose "No" if that's not what they want.

I haven't removed the references to Livecode there as it's a file format, and one that OXT Lite can open and should have file associations with as needed.

[richmond62]

On thinking about things, I think you are correct.

[tperry2x]

There kind of was logic in my decision to keep that. However if you tick "don't show this again", then it's no problem. It won't do anything anyway when running in Wine - it's really for Windows installations, but not something I added - it was already there in LCC.

Anyway, I now have a function in the "compatibility" section of the prefs (which only shows up if you are on Linux) - and hides on other platforms.

fix-in-prefs.png (25.05 KiB) Viewed 344 times

Just got to test it on a variety of Linux flavours first, before I unleash it on the world! (well, our microcosm)

[richmond62]

That's wonderful . . . I look forward to try playing an embedded movie clip on Xubuntu as soon as you lob me a beta build.

[tperry2x]

You can do it now if you'd like:
Here's a demo video of what it should do when all configured on Linux.

Everything you need is in this folder.
First, open the stack "OXT-vid-deps-v3.oxtstack"

If you see:

nope.png (16.6 KiB) Viewed 327 times

Then you need to add the dependencies mentioned.
If you are on a 'buntu or debian-based Distro, the easiest way would be:

Code: Select all

sudo apt-get install libx11-dev libxext-dev libxrender-dev libpopt-dev mplayer libxinerama-dev

Once you've added them, click "Check Dependencies" again. What you are looking for is this:

yup.png (17.2 KiB) Viewed 327 times

Once you get the 'green tick', download the file "testing.7z" from that shared folder (as above).

When you unzip the 7z file, open the stack "Video Linux.oxtstack", it should play. The inspector still has shortcomings, which the second bit to this will perhaps be seeing if I can take bits from the linux v7 engine*, but you can set all the things the inspector should be setting with various buttons. I've only implemented the "play" and "stop" so far.

That dependency-checking part is built into the preferences in my next update, but I just wanted to see if it works for other linux-es first. Feel free to test in a VM. This is on a fairly mid-range PC too (i7 processor, 7th gen) - I hope it performs well on older hardware, but not tested that as yet.

*or I'll do my alt-player version, which I discussed with Paul, above.