Richmond clicks on a link.

[richmond62]

if this was supposed to be fully open-source at one point, what we are missing are the internal developer notes behind LCC

I have a feeling that that could get quite complicated as the Open Source version was not coded from nothing in a clean room; it was built on the previously closed-source LC 6.something . . . how THAT works is omething that is a bit mysterious to be, becuase if they suddenly declared ALL the code pre the Open Source version, err, how does the current closed-source remain closed-source, and so on?

Certainly the internal developer notes behind whatever was done to transition from closed source to open source would be most instructive.

[tperry2x]

I'd say it doesn't. Essentially, didn't LC / RunRev buy out MetaTalk completely?

If they then said "Anything up to this point we declare as open source" (which is essentially what they did, didn't they?) - then you could rightly say that it made any previously closed-source code that belonged to metatalk, suddenly completely open.

SO.... if it's open, it's open. And the community should have it. Along with the notes behind it?

[richmond62]

My elephant's pink toes WERE generated by A.I.

[tperry2x]

My elephant's pink toes WERE generated by A.I.

What I meant was have a close look at them. Two sets of toes, one on top of the other. That, and the moped rider seems to have his foot merging with the back wheel and exhaust somehow.

AI seems to skip the fine details. It always has problems with hands, feet , toes and fingers for some reason (?)

[richmond62]

When A.I. can get everything right, that'll be time start worrying, not now: and as a computer is good at number crunching (which we aren't), it'll be quite a while, if ever.

Maybe the A.I. have got things right: as a Hindu bloke I once knew said, "Everything is God." So, Ganesh's foot being mixed up with the bike pedal might be some profound message 'from beyond'. LOL.

[OpenXTalkPaul]

AI seems to skip the fine details. It always has problems with hands, feet , toes and fingers for some reason (?)

Right, it may be the same reasons that it seems to be difficult for people to draw those particular things from memory. All the fine details, most of the bones in a human body are in the hands and feet. That's the finer details that AI can't handle, whereas a human artist will just wing it, fake it in until it looks passable (or just use your own hand as a model).

One other thing to look for in AI generative artwork is little bits of a human artist's signatures because they're basically plagiarizing, IP-rights-infringing machines currently.

[OpenXTalkPaul]

Yes, this is my fork, based on oxt lite, but without the CEF engine, because I'll be replacing it for something else. As I have access to the full engine source code for Linux, I can do so.
----- SNIP ----
I'm going back a long way here, but see paragraph 1 under the Linux section here, as to what I plan to replace it with.

I was wondering about that, I thought maybe you just hadn't updated that page to point to OXT Lite.
I'd prefer to link to a web page rather than multiple cloud storage things, but I guess I can update it to point to the forum post about OXT Lite. Anyway I'll try to remember to update that link later.

So you're going with WebKit or NetSurf's own engine? I would go with WebKit just because there's much more support behind the development of that engine, and I think I read somewhere that it's now the default web content view engine on Debian (or was it GTK4?) or something like that. Couldn't you just use the latest CEF binaries from Spotify (I would think they're signing them)?

[tperry2x]

I could indeed use CEF, however it's absolutely huge. Even the webkit stuff is a lot smaller, and probably better supported - my plan was to go with something webkit based (although I was looking at netsurf as it's miniscule in size), and I don't think many people will use the web browsing capabilities of OXT much - they'd probably rather use their preferred browser after all.

It's only for those niche cases where a stack might need to contact a site using SSL, sFTP or updated TLS methods. For all other cases, as long as it supports https and renders pages to a decent standard, then it'll suffice at a 100th of the download size of the CEF engine. That was my thinking, but open to suggestions.

For me, it's all about efficiency where possible.
Quote from netsurf's site: https://www.netsurf-browser.org/

From a modern monster PC to a humble 30MHz ARM 6 computer with 16MB of RAM, the web browser will keep you surfing the web whatever your system

I love the fact that it's available for the range of systems it is:
https://www.netsurf-browser.org/downloads/

You can even get it for the reMarkable, it's that lean:
https://github.com/alex0809/netsurf-reMarkable

There are also forks with additional privacy improvements in place, which the CEF engine does not respect (cross-site tracking and cookie inspection vulnerabilities) https://github.com/CobaltBSD/neosurf

I may see if I can compile a MacOS version at some point too, but my focus is replacing the broken Linux browser support currently.

[OpenXTalkPaul]

Oh I wanted to point out an important correction:
Earlier post you mentioned that CEF works on macOS (which it does with old versions of the Engine), but the macOS version of the Engine already uses the WebKit included with the OS when manufacturing its browser views (both for the Browser Widget and in the older 'External' method), and so the macOS version doesn't need Chromium Embedded Framework at all and hasn't since v8.x (IIRC).
I used to like CEF better because it can be compiled with flags that support a more 'bleeding edge' features (like WebMIDI, since I no longer need to use it for that, I don't much care), but if your source stacks do use a Browser view, it is a rather hefty chunk of files to have to include with your standalone apps files, like 150Mb extra. Better to use WebKit or other engine that's comes with the OS (perhaps that could be a choice for web engine(s)?).