Known Bugs

[tperry2x]

I'm hopefully pinning this to the OpenXTalk Workshop topics, as we have a "bugs fixed" section, but not a "known bugs" section.
So, I'll list individual things I find here in greater detail - and try to keep a synopsis of them all on this page as normal.

[tperry2x]

I've just discovered (again, probably ancient news and I'm playing catchup) that "start using font file" does not work under linux.
(source)
I also can verify this with my own testing, and copying a font into ~/home crashes the IDE on linux when it realises the fonts have changed.

[richmond62]

Well, here's an example of how we CAN learn from elsewhere:

https://forums.livecode.com/viewtopic.php?f=7&t=38969

[tperry2x]

I'm finding the same aat the moment.
The font is a TTF font, works fine under MacOS and Windows. Won't load in Linux, using the same stacks that work in Windows and MacOS. I can only think this is something else that is missed out for the Linux engine.

[richmond62]

The Linux version of LiveCode has always been the poor relation.
-

SShot 2024-03-11 at 12.34.48.png (135.11 KiB) Viewed 712 times

-
https://forums.livecode.com/viewtopic.p ... lit=Ubuntu

Frankly, as the Linux version is only guaranteed for a 6 year old version of Ubuntu, I not particularly surprised.

I think LC stopped saying the thing would run on Ubuntu 16.04 because of my snarky remarks about, perhaps, installing a newer type of Linux on their "machine in the corner".

[tperry2x]

Yes, although these are 'minimum' requirements. It does mean they 'might' run under newer libs and newer hardware, but it definitely comes across as 'experimental' or 'untested'.
A lot of distros don't come with a lot of these libs pre-installed now (they have been superseded by newer versions, or altogether replaced by something different).

When they quote old system requirements, the same could be said for the Windows and Mac versions if I were being pedantic.

Supports: MacOS 10.9 Mavericks (which it does).
Supports: Windows XP SP3 [only in x64bit 64SysWow mode].

It doesn't mean that this is the end-goal. That's not the recommended requirement. The MacOS build of OXT Lite should run on MacOS Mavericks, all the way through to Sonoma (with some persuasion) - although personally I'd stop at Catalina as you run into UI issues after that).
Similarly, you could say XPx64 all the way to Windows 11 - but then you probably don't want to try the revCopyFile command on Windows 11 as it puts up a UAC alert. I've even seen this trigger antivirus software under Win11.

Hmmmm... Will add the "start using font" to the list of known issues, and link back to this posting so people can find it. (or so I can at least find it).

[OpenXTalkPaul]

Well, here's an example of how we CAN learn from the "other place":

https://forums.livecode.com/viewtopic.php?f=7&t=38969

Yeah there is definitely some wonkiness to Font handling, really on all three platforms.
These problems seem to be related to PSName / Font Families and those sort of variable weight fonts in .OTF format.
At one point I wrote a Font Extension Builder module for MacOS/Cocoa that gets the Font list as special URLs, that actually includes the real Font Name / Styles tacked on the the end of the URL (filepath) (it also lists system UI fonts that are not normally visible in Mac app's Font menus). That font styles, PSname, etc. information is inside the .otf font files and could likely be extracted (in a way similar to the GIF parser I'm working on) for the correct Font variation names (variable weights, which typically use numbers (500,800, etc.) seems a bit more complicated to derive from the file, based on (very briefly) looking at the OTF file format.

[tperry2x]

Found another bug, with the inspector.
I'm fooling around with the inspector at the moment - only because I'm making my own.

I noticed, the built in / original inspector has another bug.
I don't know how many people would have tried this though.

inspector-bug.png (99.81 KiB) Viewed 453 times

The image of Elvis on this screenshot, I have 'Show Border' turned on, and a border width of 6px.
"3D border" is turned on, so hence there's a 3D border appear around elvis. Fine, however I then add an orange colour to the top edge of the border, and a purple one to the bottom edge. Fine, I can do this, but the inspector does not pick up on it.

As I'm redesigning the inspector (calling it "Properties Inspector" too), weird things like that are for me to worry about next.

[richmond62]

How did you set the bevel edges if you did NOT use the preferences palette?
-

SShot 2024-03-25 at 15.33.31.png (177.94 KiB) Viewed 448 times

[tperry2x]

I did exactly as you've done there, using the inspector. Except, it doesn't show up on the inspector. That seems to be the exact issue I'm experiencing. Is it because I'm on Linux?.... maybe?
More testing to follow on Windows I expect, but I'm just making a note of these as I find them.
Ultimately, I'll replace the inspector anyway, so I suppose a bit of a moot point.

[richmond62]

Yerss, possibly: MacOS 12 round these parts.

I sometimes think the person who thought up interoperability and cross-platform didn't do anyone any favours.

Certainly, trying to run some of my "very clever" programs I made on my BBC Master Compact on anything but that machine would be a laugh: wouldn't even work on my BBC Micro model B as they use different filing systems.

Back at Carbondale, Illinois (where they are going to have a bonzer solar eclipse on 8 April) in 1994 I was well aware that the 2 systems available in the university's computer labs (Mac OS 7.1 and Windows 3.1) were totally different species, and because of that, didn't get all worried about how my HyperCard stacks were going to work out on Windows: because they just weren't.

[richmond62]

Ouch: on reopening the stack, having been away helping "tinies" through the exigencies of the Present Continuous tense, I got this:
-

SShot 2024-03-25 at 17.58.27.png (176.39 KiB) Viewed 432 times

[tperry2x]

Oh well, I won't say 'good' - only in as much as it's a consistent error if you are getting the same.

[richmond62]

Home again, home again, clippety-clop: Xubuntu latest, OXTL 102:
-

problem.png (123.13 KiB) Viewed 417 times

-
tIDE: same problem.

Oh: tIDE does NOT 'see' OXT or LC stacks! Had to choose "all files" to open my stack.

[tperry2x]

Home again, home again, clippety-clop: Xubuntu latest, OXTL 102:
-
problem.png
-
tIDE: same problem.

Oh: tIDE does NOT 'see' OXT or LC stacks! Had to choose "all files" to open my stack.

Yes, tIDE (at this stage) is simply OXT Lite, so runs on the LCC engine. It'll do the same thing as LCC/OXT lite, so not surprising if I'm honest. If It doesn't work in one, it's likely it won't work in any of them.

Re the stack format. I was messing about changing a few things, and this was by design at the time. tIDE only looks for tstack files as default.

If I do complete my own alternate engine, it's not going to look/feel like OXT or LCC in any way because it's not using that engine. It's using my engine, which is embryonic at best.

tIDE is only me messing about. If you've got any serious coding work you are doing, or anything you don't want to risk losing, I'd advocate using OXT / OXT Lite / LCC

[richmond62]

tIDE is only me messing about.

Erm, well: tIDE 1.0 was 'only' there on my desktop last night, so I thought I'd just see.

[tperry2x]

I've just discovered (again, probably ancient news and I'm playing catchup) that "start using font file" does not work under linux.
...

Confirmed, fixed and working for all platforms under 1.03
(demo link here, using a ttf file and sample stack)

Although there are a few slight differences on the 'font weight', but this is down to the underlying OS & screen rendering used by the engine.