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 7437 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 7179 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 7174 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 7159 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 7144 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.

[tperry2x]

I'll mention the thing about the messed up paint tools, and graphics tools here.
(even though I've fixed it now).

[OpenXTalkPaul]

Tom you're 'killin' it' as the kids say (do they still say that?), thanks!

[tperry2x]

Haha, not sure. "Dem jus' be like Shrug" (apparently).
I don't understand the 'yoof' these days - I'm a Dad in his mid-40's, so I know nothing haha

Getting there patching things. Doing more work on my replacement inspector today, and noticed something with the original.

If you draw a curve vector graphic (freehand line), then inspect it - the inspector does realise it's a 'curve'

cropped-inspector.png (19.98 KiB) Viewed 5402 times

But, if you change it to a 'rectangle' for example, you can't change it to back to a curve with the inspector (because it doesn't have the option), although you can do it in script:

Code: Select all

set the style of graphic id 1018 to curve

(which restores the freehand squiggle I did before I changed it)... so my inspector allows this.

side-by-side.png (87.66 KiB) Viewed 5400 times

There's some undocumented stuff that you seem to be able to set here, which the original inspector doesn't allow.
You can see on the screenshot above - my inspector allows you to assign label text to a field. Even though the original doesn't. This is because I discovered I can use:

b.png (19.73 KiB) Viewed 5396 times

You can set it in script, and...

c.png (19.15 KiB) Viewed 5396 times

You can retrieve it - kind of like a secret load of text that doesn't even show as a custom property.

By the way, (in case anyone is interested), I'm moving the 'tooltip' text of an inspected field along to the third icon (with the pen) as it's all settable text and makes sense to me being on there instead.