Known Bugs

[mwieder]

Re: 15178

The trash folder on linux is normally "~/.local/share/Trash".
The files themselves are within that folder in "files" and their details (for restoring to the original locations) in "info".

[OpenXTalkPaul]

Re: 24559
The script is the same for OSX and linux. In dskmac.cpp and dsklnx.cpp it's a hard-coded constant expression as follows:

Code: Select all

#define DNS_SCRIPT "repeat for each line l in url \"binfile:/etc/resolv.conf\";\
if word 1 of l is \"nameserver\" then put word 2 of l & cr after it; end repeat;\
delete last char of it; return it"

So while it's not equipped to handle ipv6 addresses, it's a simple fix in the engine to allow them.

It's a bit surprising to me to see xTalk script embedded into the C++ code as a constant like that.
Seems like there must be a script on the receiving / other end of this that reformats it with xT script line breaks and then executes it, so maybe we can go behind the front of the engine's back in order to make changes to its implementation?

Edit: Never mind that idea, it looks like the Engine also executes that script with a 'domess' function down the road:

Code: Select all

 MCdefaultstackptr->domess(MCSTR(DNS_SCRIPT)); 

[tperry2x]

..Which you should be able to easily use to move files/folders into that folder using revCopy...

That reminds me, there's also a bug with revCopy in Windows 11 - it's blocked as default and does not show the windows UAC prompt. The workaround is to use the shell cp or xcopy commands instead.

[mwieder]

The embedded xtalk is passed from the engine to the IDE stacks using the legacy externals interface. Another example of using that interface is the code in revzip.cpp, which allows the engine to use the third party libzip library.

[OpenXTalkPaul]

The embedded xtalk is passed from the engine to the IDE stacks using the legacy externals interface. Another example of using that interface is the code in revzip.cpp, which allows the engine to use the third party libzip library.

That's Interesting.

Reminds me a little of the old HC Palette XCMD where each button in the windoid could have its own message/script embedded into the resource that would get execute by the script engine.

I've never actually used the Externals interface in LC/OXT for anything myself, but I gather it's loosely based on HC's external glue. I have looked at the code from it, some aspects of it being shared by Extension Builder.

[FourthWorld]

... the legacy externals interface.

Is "legacy" there referring to an earlier version of the externals interface, or is the externals interface altogether no longer in active maintenance?

[mwieder]

That's the existing externals incarnation, yes. I put the sdk together for LC some 20 years ago.
I used the term "legacy" to differentiate it from the LCB interface, which is supposed to be the more modern way to dealing with foreign functions/libraries. But still very much supported. It's not going away.

[tperry2x]

That's the existing externals incarnation, yes. I put the sdk together for LC some 20 years ago.

Is this the one-and-the-same externals page I lifted from the original LCC user guides?
Help > Guides (contents page: supplemental > externals)

externals.png (105.57 KiB) Viewed 3352 times

[mwieder]

That looks right, but very dated ("Revolution 2.7.x"?)

[tperry2x]

Yes, and if I recall - there was something about needing part of revolution 2.7 to compile the external. Once that was done, then it would run in LCC apparently. I've never been able to test it though on anything modern.
The only thing I ever accomplished with an external was changing the classic menubar colour on MacOS 8 to red.

I'd love to see more externals (in addition to builder) as another in-road into adding external functions. How hard or otherwise would it be to modernise this? I'm wondering if this would provide a way to implement things that are currently broken, like a speech external for Linux or a working video player / working web browser widget etc?

A while back, I posted this.
I don't expect there to be a load of XCMD stack authors spring up overnight, but the sheer amount of what was previously available was part of what made HC such a rich platform. It would be great to rekindle some of that.

[mwieder]

IIRC the thing about Rev 2.7 was that *previous* versions would have a problem with the new paradigm as in Externals v3. I haven't had a problem with later Rev versions but it's been some time since I've ventured down that road. Should probably think about updating the Guide some day.

and the problem with a browser external, of course, is what library to link it to. The actual glue isn't that hard.

[mwieder]

A while back, I posted this.

Wow. That's quite a collection. Takes me back a ways. I wrote my first XCMDs at Apple in 1987/88.

[OpenXTalkPaul]

The only thing I ever accomplished with an external was changing the classic menubar colour on MacOS 8 to red.

Yeah but remember the joy when it did that? Hah! Wanting to write externals was a primary motivation for me trying to learn C (only got a little bit ANSI C knowledge out of it), and then trying to learn Pascal, and eventually successfully writing a few XCMD/XFCNs using FutureBASIC which included a BASIC version of the glue code (FB 7 is now free BTW, and it now includes a Basic to C transpiler). One of my FB XCMDs ('CursorDo', just another 'CURS' cursor loader) is on an AMUG CD that's now on archive.org).

I'm wondering if this would provide a way to implement things that are currently broken, like a speech external for Linux

I did wrap eSpeak into an Extension, but that sounds a bit like a Speak-N-Spell toy, if you know another FOSS Linux Speech API that sounds better and that's widely available in Linux Distros then let me know and I'll look into wrapping that too. I did eSpeak because it's small, works on just about any hardware, and can be found in most Linux Software Repos

the sheer amount of what was previously available was part of what made HC such a rich platform. It would be great to rekindle some of that.

I SO FULLY AGREE with this!!! I think it's an aspect (beyond the 'live-coding' and english-like script) that a lot of people don't consider when they discuss why HC was so popular back when. The XTernals are what made HC really interesting, it's one of the first examples I know of software that was extensible with a plug-in architecture, and the xTernals could be attached to stacks so you didn't need to worry if the end stack user had xternal installed in their copy of HC (the 'Resource Fork' is something I've wanted an equivalent mechanism in OXT, I know exactly how it could be done). I think XTernals is why it took another 6-8 years after Steve Jobs killed HC for HC to actually stop being used by a lot of people (due to 'Classic' environment in OS X being killed off). And the sheer amount meant you could find externals to do all sorts of things you couldn't normally do with the basic HC install. I think more add-ons can make OXT more appealing, xTalk needs a larger ecosystem the way Python and JavaScript and other far more popular (and even som less popular) languages have.

Extension Builder is a LOT better mechanism IMO, not perfect or complete, but really good. And it's easier, in a way reminiscent of the idea behind CompilIt! which let you write XCMDs/XFCNs with Mac toolbox calls using a super-set of HyperTalk script, no Think-C needed!

[neville]

Here is the list of bugs from LiveCode Bugzilla from 2018 to the close to this date, in a searchable form (this is the stack I promised in a previous post, I'm not sure if tPerry posted this elsewhere, but this seems to be a good place for it) Of interest to us are bugs still not fixed in 9.6.12, and bugs fixed since the Community Edition. Would be good if the stack could be updated with those that have been fixed here etc - but it has over 5000 entries so it is rather unwieldy.

neville

[tperry2x]

Yes, and back up a few posts, there's also a version without the browser requirement (so you can copy and paste the url in)

[OpenXTalkPaul]

'Bug' 24152,

This is because the ascent and descent of fonts are completely different on Mac and Windows (and Linux). There is no way to fix the baseline of text in a field which works cross-platform - or indeed even on a single platform for different fonts sizes or different fonts (which leads to another nasty surprise for LC users: if the user changes the font or font size of text in a field, the content suddenly jumps out of view, and can be difficult to re-find! This would be fixed if the baseline remained fixed.)

I believe this may be due to different resolutions standards and sub pixel rendering differences on different platforms, and specifically there's not that level of fine positional control available in the xTalkScript language our Engines use. It's pixel based (uses older Cairo graphics lib and maybe libPango under the hood), which the standards pixel per inch has changed for some OSes over time from 72dpi in the 90s (which matches closely to Points measurements used in Printing industry probably a result of the 'Desktop Publishing' revolution), some later push for higher quality, 96ppi, and much later 144ppi and 288ppi (like 'Retina') displays. So my thought is this could be keeping 'fixed line height' text baseline from matching?

Another that can be involved is if the Font's metrics of the desire Font are different... let's say Helvetica, on one system is TrueType version 1.x Helvetica distributed by MicroSoft, and on the other system it's Helvetica v.2.x OpenType format that came with Adobe 'Font Folio' disks, if the font's internal metrics are different that could account for different baseline. There's no way of knowing without checking the fonts installed on the systems the bug-reporter was using, But NO rendering engine difference is going to fix a Font mismatch like that.

Anyway as far as solution for someone needing this level of positional control:
1) Maybe look into using a scriptable page layout program instead (or any other solution that's external to OXT)

2) XB eXtension Builder 'Widgets' offers finer control than pixel based does, and the sub pixel rendering (anti-aliasing) is better looking. It can render very thin or thick curved lines nice and smoothly at any size. XB Widgets use its own canvas drawing library (its bound to libSkia via FFI strings). You can position text on a line with it in a resolution independent way, and XB widgets syntax has its own text measuring capabilities which I assume they're as accurate as libSkia is. I'm willing to bet that it's a consistent position on all the various platforms (need to test that theory though).

Note: Not all of libSkia is wrapped in FFI bindings and exposed for 'extra-engine' use (that can be added to, the source for the syntax itself is written in eXtension Builder language module that could be expanded upon), but enough of it is that you can transform paths and image patterns with it.

3) Possibly using the Browser Extension with some HTML5 + some JS library? Using Browser Widget in Linux comes with its own problems with certain window managers in some distros.

BTW, there is a XB extension library that allows scripters to use a limited set of canvas drawing stuff on your cards/stacks. The LCB files found in Engine Repo folders. That library could probably be extended a bunch more.

Also, I there is a nice 'label box' extension (made by MadPink I believe) on GitHub, that does text line-breaks better (IIRC).

[OpenXTalkPaul]

'Bug' 24152,

Another that can be involved is if the Font's metrics of the desire Font are different..

I'm going to say this is NOT a bug, at least not in the way as described by the user who reported it.
They're using different system fonts, I would totally expect they're going to have different metrics and therefore render differently.

A much more effective test is to use the EXACT same font on all the platforms and then check if there's a difference in the position on the card.

[neville]

aargh, sorry Tom, I completely missed that pages of the Known Bugs thread!

[neville]

OpenXTalkPaul wrote: ↑Tue Aug 13, 2024 2:39 am
'Bug' 24152,

Another that can be involved is if the Font's metrics of the desire Font are different..
I'm going to say this is NOT a bug as described by the user who reported it.
They're using different system fonts, I would totally expect they're going to have different metrics and therefore render differently.

A much more effective test is to use the EXACT same font on all the platforms and then check if there's a difference in the position on the card.

It was me that posted the bug. I was indeed using the exactly same font in each case on each platform, not the System fonts. They do appear in different places on each platform (vertical displacement out by noticeable amounts - not much one can do about different lengths, though Windows and Mac seem now to agree in that dimension, Linux not so much- actually not much at all) ; which makes it very difficult to get consistent alignment of objects across platforms - important for things like music scores, but also just for a professional look. There was a stack and a document posted with LC which made the difference quite glaringly obvious.

It is not surprising that the font metrics reported by LC for the same font on different platforms are different because each OS has its own font engine. So also not surprising they will render in different positions on the card. What I was after was a feature enhancement to get and set the baseline of a line of text in a field, so that the developer could align other objects to that baseline, and *that* would work cross-platform. Currently it is not possible to compute the baseline accurately from the font metrics returned by LC. There were some old algorithms proposed on the LC forum, but in fact they were inaccurate for about 50% of the 700+ fonts I tested. I have an algorithm which is mostly accurate, but can still be out by 1 pixel for certain fonts at some unpredictable sizes on the Mac, I think possibly because of a round off error in the Mac reporting. My point in the bug report/feature request was that the LC engine *does* know exactly where the baseline is, because it can draw that dotted line and it always gets it right - but currently doesn't expose that information to the user.

Neville

[OpenXTalkPaul]

OpenXTalkPaul wrote: ↑Tue Aug 13, 2024 2:39 am
'Bug' 24152,

Another that can be involved is if the Font's metrics of the desire Font are different..
I'm going to say this is NOT a bug as described by the user who reported it.
They're using different system fonts, I would totally expect they're going to have different metrics and therefore render differently.

A much more effective test is to use the EXACT same font on all the platforms and then check if there's a difference in the position on the card.

It was me that posted the bug. I was indeed using the exactly same font in each case on each platform, not the System fonts. They do appear in different places on each platform (vertical displacement out by noticeable amounts - not much one can do about different lengths, though Windows and Mac seem now to agree in that dimension, Linux not so much- actually not much at all) ; which makes it very difficult to get consistent alignment of objects across platforms - important for things like music scores, but also just for a professional look. There was a stack and a document posted with LC which made the difference quite glaringly obvious.

It is not surprising that the font metrics reported by LC for the same font on different platforms are different because each OS has its own font engine. So also not surprising they will render in different positions on the card. What I was after was a feature enhancement to get and set the baseline of a line of text in a field, so that the developer could align other objects to that baseline, and *that* would work cross-platform. Currently it is not possible to compute the baseline accurately from the font metrics returned by LC. There were some old algorithms proposed on the LC forum, but in fact they were inaccurate for about 50% of the 700+ fonts I tested. I have an algorithm which is mostly accurate, but can still be out by 1 pixel for certain fonts at some unpredictable sizes on the Mac, I think possibly because of a round off error in the Mac reporting. My point in the bug report/feature request was that the LC engine *does* know exactly where the baseline is, because it can draw that dotted line and it always gets it right - but currently doesn't expose that information to the user.

Neville

Ah thanks for clarification, to be honest I probably didn't give it a thorough read thru as I was skimming though the bugs lists posted, I'll check it out again. What was the Pixel Per Inch on the screen(s)? Were all os involved all using the same screen-size and pixel depth or was one a Retina display (144/288 ppi) and another screen 72 1920x1080 or similar?

Mac Apps have info.plist setting for HiDPI I believe, but I think that option is only effective if the screen is high enough resolution, the IDE would actually load slightly different startUp revSplash screen on high-res screen (I changed this to use a single image recently).

Oh if you have a good algorithm for getting accurate alignment to the nearest +/- 1 pixel difference on Mac/Win platform then it may very well be a sub-pixel rendering thing? Also I don't want to use that bugzilla. Would you mind posting that scripts/examples here? Perhaps in a new topic?

With SVG / Canvas drawing in Widgets you can position with floating point accuracy (at least in theory accurate) with or without anti-aliasing. The coordinates system is a bit different from Card coordinates, it goes from lowerLeft instead of topLeft. But you can use SVG path strings exported right from a vector drawing app.

I'd guess it would give more accurate text positioning (and certainly SVG symbols placement) too, but I haven't done a whole lot with text-rendering in eXtension Builder Widgets myself, With my Widgets I've tended to stick to using 'flattened' (compound paths) SVG on canvas layers (vector paths stored in Array) and proportional divisions of the widget canvas rect for positioning.

If you're interested in doing Music Notation stuff, that's great! I've never really learned to read sheet music myself, but I did add some notes length symbols (SVG glyphs) to my OXT IDE svgicons set, as part of the addition of OXT SVG Icon Set loading library (along with SVG Glyphs Browser stack). Perhaps we could collaborate on some music symbol notation typesetting widget? I've worked on Piano-Roll / Drum Pattern style grids as Widgets (and as DataGrid)...again I don't do notation. I do however do HyperTalk 'playSentence' style 'ABC' notation, and I made an algorithm to map it to my Piano/MIDI X-Y Grid Widget (playSentence -> PianoRoll) to display / edit it. When I say HC PlaySentence style, I'm actually talking about a super-set of that called PlayMD/MakeSMF, an xTalk script library by UDI that has additional mappings to General MIDI (Quicktime's Rolland GM Set originally) features like vibrato and can output standard MIDI files and so can playback on any MIDI playback engine (such as OXT FluidSynth Extension or Android mobile play as movie or whatever).