OpenXTalk Forums

Hi Paul

What is your workplan?

Kind regards
Michael

Coincidently I just came on to this forum to post an update.

As far as I can tell the IDE is about 97/98% de-branded, including the dictionary and docs.

I should probably release some type of beta build for people interested in joining the effort, to help coordinate so that we aren't independently working on the same aspects of it going forward from the de-branded beta starting point. Valentine's Day? That would be Monday.
At the very least I could package up the IDE bundle that I've personally been using (on macOS BigSur) and put it up on a Google Drive and/or MEGA cloud storage for mac based testers.

I'm currently building an OXT Tools palette, and also preparing a few other small things that I'd like to include in a first (or possibly second) release of the "Don't Panic Edition" IDE. The Tools redesign is part of a larger effort to (finish what LC started and..) make all of the icons in the IDE use resolution independent SVG Paths instead of bitmap images (from 15 years ago ). In my opinion this is important work to do for several reasons, LCD screens resolutions are getting higher and higher, need sub pixel drawing and large size scalability, the way widgets work can be made to be system darkMode compatible (at least on macOS) so that if the OS is put into darkMode or lightMode the SVG Icons automatically change their forground color to the inherited system color, black icons become white and the inverse, without any coding to make it do that. And it also allows a lot more possibilities for inteface layout than static images (that can pixelate badly when you scale them too large or too small)

For making SVG 'button' grid palettes, I've taken the code from the IconPicker widget that is part of the IDE and is used by a few other widgets and I've modified it so that you can set a custom Icon Set and which icons from that set should appear and in what order. I've changed the paint so that it inherits it's colors (from the system) and I've also made it send post iconClicked messages with the name of the icon that was clicked as a parameter.

Coincidently I just came on to this forum to post an update.

As far as I can tell the IDE is about 97/98% de-branded, including the dictionary and docs.

I should probably release some type of beta build for people interested in joining the effort, to help coordinate so that we aren't independently working on the same aspects of it going forward from the de-branded beta starting point. Valentine's Day? That would be Monday.
At the very least I could package up the IDE bundle that I've personally been using (on macOS BigSur) and put it up on a Google Drive and/or MEGA cloud storage for mac based testers.

I'm currently building an OXT Tools palette, and also preparing a few other small things that I'd like to include in a first (or possibly second) release of the "Don't Panic Edition" IDE. The Tools redesign is part of a larger effort to (finish what LC started and..) make all of the icons in the IDE use resolution independent SVG Paths instead of bitmap images (from 15 years ago ). In my opinion this is important work to do for several reasons, LCD screens resolutions are getting higher and higher, need sub pixel drawing and large size scalability, the way widgets work can be made to be system darkMode compatible (at least on macOS) so that if the OS is put into darkMode or lightMode the SVG Icons automatically change their forground color to the inherited system color, black icons become white and the inverse, without any coding to make it do that. And it also allows a lot more possibilities for inteface layout than static images (that can pixelate badly when you scale them too large or too small)

For making SVG 'button' grid palettes, I've taken the code from the IconPicker widget that is part of the IDE and is used by a few other widgets and I've modified it so that you can set a custom Icon Set and which icons from that set should appear and in what order. I've changed the paint so that it inherits it's colors (from the system) and I've also made it send post iconClicked messages with the name of the icon that was clicked as a parameter.

A beta release would be excellent, and highly appreciated for people like myself who aren't great at compiling things from source.
At least on Linux, could we have an appimage build of a beta to test?

A few things I noticed about using Livecode on mixed platforms.
On Windows, the window focussing mode can feel pretty broken at times, and it's not always evident which stack or palette is genuinely at the front.

On Mac / Windows, if you want to go fullscreen with a stack, you can use: This produces the desired effect in a standalone, so that your stack is sized as per your available screen.
To get the same effect on Linux (especially if you have floating panels in XFCE/Gnome), you have to have wmctrl installed and call it with: Sorry if these things should go somewhere else in the forum (feel free to move, or let me know if you have a 'bugfixes' section).

Many thanks for your continued efforts with this project,
Tom Perry

tperry2x wrote: ↑Sat Feb 12, 2022 6:52 am A beta release would be excellent, and highly appreciated for people like myself who aren't great at compiling things from source.
At least on Linux, could we have an appimage build of a beta to test?

So this weekend was a bit of a wash for me, partly because it snowed here (at least my 12yr old son and 3 labradors like it), and I would like to spend some time on the Linux side so I think maybe the beginning of March is a better target, that would be six months from when LC Ltd. dropped its GPL3 support.

I do want to package for Linux with .appimage (which I have yet to do but I've read up on it).
I really like appimage as it's very similar in concept to macOS .app bundles.

The person who created the appimage format also has a very cool (and macOS-like) FreeBSD based operating system project going that's call 'helloSystem'. I'd very much like to package OXT to run on that OS (has Linux compatibility layer).

A few things I noticed about using Livecode on mixed platforms.
On Windows, the window focussing mode can feel pretty broken at times, and it's not always evident which stack or palette is genuinely at the front.

On Mac / Windows, if you want to go fullscreen with a stack, you can use:

Code: Select all

set the rect of this stack to the screenrect

This produces the desired effect in a standalone, so that your stack is sized as per your available screen.
To get the same effect on Linux (especially if you have floating panels in XFCE/Gnome), you have to have wmctrl installed and call it with:

Code: Select all

get shell("wmctrl -r :ACTIVE: -b toggle,fullscreen")

Sorry if these things should go somewhere else in the forum (feel free to move, or let me know if you have a 'bugfixes' section).

Many thanks for your continued efforts with this project,
Tom Perry

When I want my stack to be fullscreen I usually use the 'fullscreen' keyword: but I haven't tested this is Xubuntu (which is what I'm using for Linux testing)

On macOS OXT also has ToggleFullScreen( windowID ) available, which applies macOS native fullscreen window setting to a stack window, and behaves slightly differently from the engine's built-in 'fullscreen'.
I'll have to do some tests with stacks in standalone on Linux. Are these 'fullscreen' problems that only happen with standalones and not in the IDE?

Big Chestnut:

https://forums.livecode.com/viewtopic.php?f=104&t=36739

A free Windows installer that might be useful. http://www.jrsoftware.org/isinfo.php

Whatever OS - I'd be willing to test. Only restrictionf or me: I might not be able to setup a toolchain for compiling myself. A "portable App" (zipped binaries?) for Windows, Snap (or something else) for Linux and "whatever a Mac expects" would be really helpful.

What about the "Debranding"? How's it done? Going through source code and do a search / replace or replace images?
Is there anything else, a computer afficinado with next to zero oXt knowledge could helpf with?

Testers, and or/people that could build install packages would certainly be welcome.

tergolap wrote: ↑Thu Feb 24, 2022 8:17 pm A "portable App" (zipped binaries?) for Windows,

Installer exe would be best for Windows I think, one that could set up the dummy registration file, and add the appropriate Registry keys and whatever else.
I'm currently looking to do the Linux bundle as an .AppImage, but if anyone wants to build a Snap, Docker, RPM, Deb, Pkg, VM or whatever and share it, that would be great!
One of the reasons I'm looking at AppImage is that I want to run OXT on a FreeBSD based OS called helloSystem that I've been playing with a bit.
MacOS X+ (and really classic Mac too, sort of) has always had a portable "bundle" (or 'bottle') format that it inherited from NeXT. The .app bundle. The macOS LC 'installer' is just a disc image with a .app bundle on it.
99% of the 'debranding' was done to IDE components, scripts, stacks, the Dictionary (which is made of xTalk, SQL, and HTML/CSS/JS) and graphic files. There's very few things that the engine needs to be recompiled for as far as the 'debranding' is concerned. The two that I'm aware of are:
- The LC custom LC window-class name on Linux shows up in certain (obscure) places in certain Linux Desktop Environments
- On all platforms there's an initial 'LC account registration' window that shows up on first run if it doesn't find a certain 'license' file in a certain directory (this can be a blank file as long as it's named correctly). This is actually a stack that's embedded into the Engine binaries. I'd want to remove that when recompiling.

I'm on Debian 11, so an Appimage would be highly preferable for me to test too. I tried flatpack, and others, but it seemed that an Appimage works in very much the same way as an app package on OSX. You just double-click it (okay, you have to mark as executable on linux), but it's that easy.

No other dependencies or stuff to install.

This is always what has attracted users to OSX over other platforms.
Likewise, a portable version for Windows would be better for compatibility too.

You mention old versions of Mac OS. I'm guessing this would be far far too much work to have OpenXTalk support Mac OS 9? ...and there would be a very limited audience I imagine, but it would still be cool - only for dinosaurs like myself I guess. I still have a bitter taste after Apple declared Mac OS 9.2.2 dead and had a mock-funeral, but I'm just holding grudges now.

Revolution / RunRev did originally have the option to save Mac OS PPC and Mac OS Fat application binaries, so I assume that code and ability is buried deep within there somewhere still.

so I assume that code and ability is buried deep within there somewhere still

I doubt it very much as RR/LC went through a refactor at about the same time they introduced full Unicode
capability.

richmond62 wrote: ↑Sat Mar 05, 2022 5:02 pm

so I assume that code and ability is buried deep within there somewhere still

I doubt it very much as RR/LC went through a refactor at about the same time they introduced full Unicode
capability.

MacOS 9 / classic / PPC, at almost a quarter of a century old) is a bit too old for the current OXT project of debranding and expanding on LCC 9.6.3, which has a macOS v10.9 minimum requirement. Perhaps some things could be back-ported to a debranded, older PPC (LCC v6.x) engine? AFAIK none of the MetaCard/RunRev engines that ran on macOS classic were GPL open source (only the MetaCard IDE was open sourced). But then there's plenty of freely available (if not legally 'free') xTalk environments for macOS classic, including the original xTalk HyperCard (see the "X-Talk implementations" forum section for links to some others).

tperry2x wrote: ↑Sat Mar 05, 2022 4:13 pm I'm on Debian 11, so an Appimage would be highly preferable for me to test too. I tried flatpack, and others, but it seemed that an Appimage works in very much the same way as an app package on OSX. You just double-click it (okay, you have to mark as executable on linux), but it's that easy.

No other dependencies or stuff to install.

That's exactly why I like the AppImage format, if need be you can basically bundle most of an entire Linux environment inside your bottled "App" bundle and it should run under virtually any distro (as long as the bare metal hardware is compatible, or it could include some sort of emulator), thereby permanently avoiding library dependency hell. I want really OXT to run on a FreeBSD distro (helloSystem) and this may be an easy way to do that. The alternative would be trying to build from source for the old BSD targets, which I image haven't been used in at least a decade and a half.

I went and had a look at helloSystem again, because it tripped the "I've heard that before" trigger. It's been months since I had a look.

That's gorgeously simplistic, and I'm not at all surprised that you want to get the project running there, as well. First thing to make me want to run xBSD since systemd (I didn't say that, nobody heard it, it's for a point of reference, not for flaming.) Also yes, I've used Devuan before.

(I'm downloading it to run it "live" right now via USB...)

overclockedmind wrote: ↑Sat Jun 04, 2022 6:48 am I went and had a look at helloSystem again, because it tripped the "I've heard that before" trigger. It's been months since I had a look.

That's gorgeously simplistic, and I'm not at all surprised that you want to get the project running there, as well. First thing to make me want to run xBSD since systemd (I didn't say that, nobody heard it, it's for a point of reference, not for flaming.) Also yes, I've used Devuan before.

(I'm downloading it to run it "live" right now via USB...)

Some builds of helloSystem will boot via Ventoy (which is a brilliant live-boot-from-ISO-boot-loader).

There's also a more ambitious related (they're cooperating) OS project called ravynOS (formerly AiryXos), that seeks to some level of actual binary compatibility with macOS, similar to what ReactOS does for Win32.
Here: https://airyx.org

At a minimum the xTalk called OpenXION should be able to run fine on those, provided some version of Java is installed.

At the risk of spamming this forum, which I'm not trying to do - please see my reply at:
viewtopic.php?f=10&p=2213#p2213

My only view is that we perhaps have a roadmap, or some kind of plan in which direction the development is currently headed.