Richmond clicks on a link.

[richmond62]

https://www.openxtalk.org/OXTDownloads.html
-

Screenshot 2024-02-25 at 22.03.08.png (20.36 KiB) Viewed 2267 times

-
https://www.tsites.co.uk/sites/other/other.php
-

Screenshot 2024-02-25 at 22.02.15.png (406.15 KiB) Viewed 2266 times

-

Download
Version 1.0 beta is currently available for Linux. You can download it 210 MB (ish) from here.
* Windows versions are currently in development and pending further bug fixes.
(You can currently run the Linux version of tIDE through WSL 2 for Windows 10 and 11)

MacOS support is also planned, however this is further down the to-do-list at the moment.

Um?

[tperry2x]

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.

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 did actually have some luck in getting the browser working under Linux, but that was by force-loading unsigned libs (Which I wouldn't recommend).

I'll also be experimenting with alternative players in this version, and this is my 'test build', rather than messing up OXT Lite. I don't want to inflict any more potential crashes on anyone using OXT Lite, so this is kind of a safety-net. That's also why it's labelled as beta.

This should really be labelled "Richmond clicks on an outdated link"

I had requested once that the main OXT site either links to the download section here, or the Dropbox link (or now even the Mega one). This was because my site was brought down due to too much traffic, hence why I moved the download to Dropbox.

That link will have been dead for a long time.

If you are looking for oxt lite links, check out the downloads section. This is where the main OXT site should point to.
https://www.openxtalk.org/forum/viewtopic.php?t=590

As mentioned, you'll also find mega links as suggested, Incase Dropbox is being difficult.

[richmond62]

Very interesting.

Especially as you have kept very quiet about it.

Also the link should indicate what it is a link for.
-

tiddlypom.png (183.16 KiB) Viewed 2254 times

-
It states it is available for Linux, Windows and Macintosh.

[tperry2x]

It will be available for Windows and MacOS eventually. Not yet. Not until the prebuilt binaries surface.

It's currently not that interesting, so not much to shout about. Doesn't differ from OXT Lite 1.01 too much, aside from the CEF removal.

Until I have complete source code for Windows and MacOS, it's just me messing about, as it's incomplete. It should be considered an experiment - A bit like your RM build. I wouldn't recommend trying to do much serious work in it.

But anything in this version will change without notice, as it's really only intended for my purposes, with no guarantee it'll work for anyone else's system.

So, if it messes with your preferences or is incompatible in some way, don't be surprised, as it's not intended to be. That's another reason I've kept quiet about it. Don't blame me if it chews up and spits out your stack, or munches an important file in some way.

I'm also messing about implementing XCMDs for Linux in the tIDE version. This isn't even online at this stage. All I've managed to do is code a fade XCMD for tIDE. Only works on Linux for boring reasons (uses GTK 2, 3, 4, GDM or metacity as a last resort - whichever is available), and works by decreasing / increasing the monitor gamma of all attached screens:

Code: Select all

on mouseup
   gFade in 0,0,0 for 2 seconds
   Wait 3 seconds
   gFade out for 2 seconds
end mouseup

This fades the screen in to black, waits for 3 seconds, (which is quite disconcerting waiting for something to happen), then fades the screen back out to whatever is on your screen again. It's an xcmd that doesn't work under OXT lite or LC, but it's not intended to.

If tIDE was a sandwich, the label on the box would say "warnimg, contains beetroot and prawns: not fit for human consumption"...

You get the idea.

[xAction]

Missed opportunity to call your stacks "pods." Mmm yummy!

[richmond62]

This should really be labelled "Richmond clicks on an outdated link"

Well he certainly clicked on a misleading link.

Could also be labelled "Outdated person clicks on outdated link"

And as to 'CEF' . . .
-

SShot 2024-02-26 at 10.00.43.png (53.2 KiB) Viewed 2196 times

-
That's the problem about acronyms . . .

(Got in a right @#$%^&* when I was invited in the USA to attend a presentation on STDs: I explained I already knew what Standard Trunk Dialling was, and that it was horribly out of date.)

. . . and discipline-specific jargon.

IFF: http://gunkies.org/wiki/Computer_Emulation_Framework count me out, as that is about 3 miles above my head.

[richmond62]

Whatever CEF is, the fact that you can remove the thing, and the IDE continues to work, suggests it might be redundant.

AND, if CEF is redundant why is it being kept in OXT?

As I have access to the full engine source code for Linux, I can do so.

Is that meant to imply that other developers do NOT have access to full engine source code?

And, if not, why not?

[tperry2x]

Is that meant to imply that other developers do NOT have access to full engine source code?
And, if not, why not?

It is. Please see my previous posts about not having the prebuilts, required for building the engine from source, for Windows and MacOS.

[richmond62]

How, then, did you get access to the source code?

[tperry2x]

I was sent a direct link to a Google shared drive. Much the same as I hope will happen with the Windows and MacOS prebuilts.

[tperry2x]

Whatever CEF is, the fact that you can remove the thing, and the IDE continues to work, suggests it might be redundant.

It is for Linux at least, or rather the implementation of it in OXT is broken.
CEF is the browser framework
https://cef-builds.spotifycdn.com/docs/ ... ndler.html

As I mention, I plan to replace it with a better - lighter, faster, stronger... (to the tune of daft punk) and more secure alternative eventually.

[richmond62]

I was sent a direct link to a Google shared drive.

By whom?

AND, at the risk of being hopelessly naive (OK, OK; I am, guilty as charged) WTFF (W.T. Flying F.) is the role of this thing inwoth the IDE?
-

SShot 2024-02-26 at 13.32.23.png (19.42 KiB) Viewed 2144 times

[tperry2x]

Someone who asked to remain anonymous, and obviously values continued development of the engine, rather than seeing it walled-off.

[richmond62]

Someone

Oh, THAT person: possibly the person who let me know about how to import coloured SVGs.
-

Ganesh_on-a-bike.png (933.3 KiB) Viewed 2143 times

-
That picture is a love gift from me to xAction, who ought to lighten up a bit.

Trick question: "What do you call MOOBS on a four-armed, elephant-headed god?"

Answers on a postcard to the usual address.

[tperry2x]

AND, at the risk of being hopelessly naive (OK, OK; I am, guilty as charged) [redacted] [what] is the role of this thing [within] the IDE?

The prebuilts are libraries used when compiling the engine from source. They contain third-party code which the engine relies on (essentially LC borrowed things like display technologies, SSL and encoding libraries that already exist). The engine expects (and requires) these prebuilt libraries to compile properly. They vary by platform because their implementation is different depending on platform. The engine pulls them in and embeds them inside of itself when being compiled.

Without them, having the engine source code in Github is a bit pointless - a bit like having half a jigsaw puzzle. You have to make up the rest, but it can never be put back together as intended.

You cannot simply remove them either, as the engine would not compile (sticking with the jigsaw analogy: you wouldn't get the complete picture). If you changed the compiler scripts to not require these, you might get it to compile - but you'd be missing a lot of features - and multiple things within the IDE just would not work. So we do indeed need them in the future if we want a new engine to be built for MacOS and Windows.

[richmond62]

They vary by platform because their implementation is different depending on platform.

I am able to understand that bit, and that bit is enough for me to grab the horse by the tail.

So, if CEF is NOT necessary for a Linux version of 'an xTalk IDE' (with the proliferation of IDEs this could get very clunky to refer to), how necessary is it for Mac or Win versions, or, for that matter other (potential) platforms?

I have a lot of respect for 'tIDE', and wonder HOW, HOW, HOW, MacOS & Windows, should you decide to eschew CEF entirely.

[tperry2x]

Well, here's the thing - because the CEF browser was broken in Linux anyway (because of dependencies being out of date & unsigned... and many other boring reasons I won't go on about)... it means the browser widget doesn't work. So if someone relies on that for their stack, then they'd just be staring at an empty square rather than the expected web view.

This does work on MacOS and Windows (to a fashion). The Win and Mac versions identify / announce themselves as old versions of Chrome to any website, - so occasionally you'd just get "you need to update your browser to continue" response pages back. It's fine for a lot of sites, but there are quite a few like this. (irrespective of what your main browser you have installed is, and how up-to-date it might be).

I wouldn't say they should be gotten rid of entirely. I'm just recommending we replace them with something else in future. There are alternatives that weigh in under 10MB as opposed to the hundreds of MB that CEF does. Plus their user-agent string can be tweaked easily, so you can identify your OXT browser widget as seemingly being rendered in Edge on Linux, or Safari on Windows - if you so wished. But the point is, it's not then etched in stone & locked away in the engine. This externalises it so anyone with bbedit / pluma / textwranger (etc) can tweak it without needing a full recompile of the browser engine either.

[tperry2x]

Missed opportunity to call your stacks "pods." Mmm yummy!

haha, tIDE pods - I still can't believe kids had a phase where they were daring eachother to eat these. The [many] problems with social media

tIDE can stand for anything you like. Tom's IDE, TinyIDE (at least, it's smaller without CEF), or "Test-IDE" which was my original thinking when I first thought of using this so I didn't do any damage to OXT lite.

I just hope I find time to do more with it, and it's not left floundering (sorry - couldn't resist the pun)

[xAction]

I've been using tVariable for ages and ages, 'cause that's the way I learned the language, so I just associated the lower case t with that, thought it was pretty cool. I tried Pascal and they used the tVariables everywhere too.

Should maybe contact some Linux gathering places to draw in some downloads and feedback, maybe get some extra eyes, hands and brains involved. If people don't know about things ,they languish. It amazes me how some open source endeavors explode in popularity and other things just get lost in the data stream, then one day you find it "Wow, neat", check up on the source...last edited 9 years ago. WHAT?

[tperry2x]

And there I was thinking it was nice they used my first initial for variables... I jest, I'm not that self-absorbed. Well, perhaps I am, but that's off-topic

The more the merrier as far as developers really, as far as I'm concerned. Perhaps we'll attract some seasoned C++ coders too - that would be cool. I know enough to be able to get the gist of what I'm looking at, but my understanding of C++ is still in it's infancy. (I'm still learning xTalk *), and even then I'm better at GDScript than C++. Even html and CSS (if you can call CSS a programming language - I think that's stretching it a bit).

*"Livecode script" as LC would like it referred to as - (except it's essentially MetaTalk's "Transcript" wearing new robes).

If we have a talented C++ coder, then it'll open a lot more doors as to what we can do with our legacy engine (I don't think that's being too harsh - it does describe what we have currently, after all).

I know there's a lot that jumps out at me in the engine that is now defunct and could be removed. There's also a lot that needs changing because there's better ways to accomplish the same function, but with less lines of code - more efficiently.

However, messing around in the engine source is something I've been reluctant to do. Not only because of me being a n00b to C++, but also because of how intertwined and cross-referenced it all seems to be. I don't know if changing something somewhere is likely to break a function elsewhere along the chain.

In my view, if this was supposed to be fully open-source at one point, what we are missing are the internal developer notes behind LCC - why things were done the way they were done, what functions actually do what, and why were some bits seemingly left in when they are 10+ years old. Was it to maintain compatibility, or were they just overlooked? Coupled with the parts of the source that we just don't have... I'm not going there again, you know where we are with all that.

I can only suggest that once we have things a bit more finalised, that perhaps I upload all of OXT Lite (and the engine source) - and yes - the prebuilts I have too, to something like github. Developers seem to expect this now. The first question seems to always be, where's your git repo for that?

It's a valid question, but I can't help feeling that git is overcomplicated and clunky. (The difference of dealing with MS365 and LibreOffice for comparison). Git is over-complicated and makes a meal of the simplest change, whereas something like SVN is far simpler, and just works without needing to learn git-specific terminology.

This: (exactly this)
https://stackoverflow.com/questions/576 ... ves-to-git

Agreed. Git is a pain. Nobody wants to change history: why is that option even there? Why dozens of commands with as many options? Why distributed repositories? Why staging? Nobody needs that.

But this isn't the time and the place to have a discussion about git. Perhaps we should?
While many would say that version control = Git or nothing, I'm not so sure there aren't better (& simpler) alternatives.

I don't know if anyone else has any strong feelings towards git, or an alternative they'd prefer?
I'd like us to have a consensus before I upload the entire OXT lite build (as individual files that can be edited).

Perhaps GIT and SVN aren't your thing. How about Mercurial?
https://www.mercurial-scm.org/

(A simple GUI for version control) - yes please!
http://easyhg.org/download.html

Or perhaps Monotone?
https://www.monotone.ca/

Or maybe CVS is what immediately comes to mind?
http://savannah.nongnu.org/projects/cvs

... or perhaps I should stop hijacking this post and make a new one