OpenXTalk Forums

The last two weeks were a bit spoiled by the self-inflicted disaster of messing up the partition tables on my laptop SSD (which still seems to contain an Apple APFS volume container, I may try to image it and extract info from it at some point). Fortunately the majority of the interesting dev stuff that I've been working on for the past few years has been done OpenSource via GitHub, so that's safe! I had also recently done some backups so not all was lost.

I took the opportunity to give myself an early Christmas present and upgrade the laptop that is my main dev computer. I replaced the 500Gb with a 2Tb M2 SSD, and increased RAM to 40Gb (I like to load a LOT of Sound samples)! The extra space will really come in handy for trying to compile the xTalk engines, the current Mac build requiring component from multiple versions of Xcode (they're like 5 to 10 Gigs of disk space each).

Now I have plenty of room for multiple OS's, and I now have it setup with macOS (11/BigSur), Win 10, and Linux (the latest LTS release of Xubuntu) with other partitions reserved for other OS's (I may put 10.14.6 back on as an 32bit friendly alternate macOS boot, plus some others like Batoreca, LibreELEC, Android X86, and helloSystem).

So once my Laptop was a back up to speed after about a week of downtime, I got back to working on OXT.
That work has even narrowed down to try to meet a self imposed deadline of a Winter Holiday release.

This release will be a release candidate preview release.

The scope will be this:
1) Unbranding / Rebranded release as OXT. This release will not have recompiled engines, changes have been limited to what could be done without any recompiling. There is actually a LOT that can be done on top of the existing engines, enough to keep me busy for a long, long time anyway. Unbranding / Rebranded has been the main task all along, although it might not seem like it. Doing this work has led to editing all sorts of IDE components, the Start Center, The Dictionary, The Resource Center, Preferences stack, etc. Some things simply cannot easily be renamed because other things that use their identifier scheme name would break and so I would hope that is considered part of "respecting our open source legacy". I've made both the "Start Center", and "Resource Center" Stacks easily replaceable. I've been doing a lot of editing to the Resource Center because it's so old and neglected (like neglected for more then a decade), with some sample/examples no longer being functional.

2) The syntax Dictionary Unbranding / Rebranded AND expanded! Besides replacing an ecessive amount of instances of the name, I'm also including the syntax for the IDE itself! That is, I'm including the documentation of the handlers that do most of everything that the IDE does. I don't mean just the API meant for people making IDE Add-ons, which is the base of it, but I've also added handlers from menubar, menu toolbar, the property inspector, the tools palette, etc.

3) DarkMode! This has actually been a lot more involved then I thought it would be, because most of the IDE is not setup to look good reversed out (White/Light over Black/Dark, instead of Black over White) and elements have to look OK in both light and dark. I think this is mostly OK now, I've been using the IDE in macOS darkMode exclusively for a month or so, fixing issues as I see them. On Linux I've also tested this with a KDE DarkTheme and the two XFCE Dark themes that come with Xubuntu. Looks pretty good to me.
I'd like to change the revTools palette further so that it better supports toggling between light/dark theme, by changing the platform varying "classic tools" to be single platform-generic set of scalable vector (SVG) line art icons. I've created some of these vectors already.

To give window frames the system-level DarkMode look on macOS I've also uses my macTools Builder Library, which I've donated to OXT and is now called OXT MacOS Native Tools and will be included in the IDE (since the IDE now requires that on macOS). This Builder library includes support for a few other useful system level Mac specific things as well, such as the ability to badge your app's icon in the Dock with a short string of text (like the message count in the Mail.app) for example.
On Windows 10, I'm currently looking into making an equivalent "winTools" native library, to do the same (Dark Window Frames & Dark MenuBar) for Windows. Apparently in Redmond "darkMode" is still a work in progress with Win32 API Devs commonly using undocumented things, that can (and have) change from one OS version to another, to enable a dark theme. I seems like it should be easily doable, we'll see, at least I've tweaked revMenuBar on Win so that the menu text isn't white on white.

Having just spent some more time running the IDE on Win, I can understand why there are a lot of complaints about it performance wise, the IDE basically locks up for a few seconds here and there, and I know it's not my Windows Install because this is a fresh and clean install of Win 10. I don't know why it would be doing that, maybe the IDE is posting too many messages in the message queue and then it gets bogged down for a half-second to catch up? If I was looking to do commercial dev and saw the IDE do this, I'd probably stop looking at the IDE at that point. I don't know why it would be doing this, anybody have any ideas?

4) Extras...I decided early on that I wanted to include FluidSynth Builder Library along with my Piano Widget for use. That's pretty simple since that was already tested and working on Mac & Win platforms. I had to tweak FluidSynth a little but got it working on Linux (64bit) too. To go along with this, I'd also like to include some other Interactive Music/MIDI related libraries. UDI's venerable MakeSMF/PlayPMD Library converts HyperCard playSentence ABC-style notation into MIDI data. This library was first written in the late 1990s but it's every bit as usable now as it was then, the only thing that's changed are the platforms and underlying playback engines! (MIDI 2.0 just recently became the new official standard, 30+ years since MIDI 1.0 came out!). I also have worked on custom, live-editable x-y data grid control widget that I've been developing in order to edit and display on a MIDI piano-roll style grid.
Upon a request I've made the font size of revMenuBar toolbar into a preference, changing the font size and then refreshing the menu (via a new menu item) changes the size of the entire toolbar.
One other possible IDE extra that is on my short-list because I've found it very useful is the DevGuides extension, I would like to integrate that into the IDE with a menu item to toggle Guides on/off.

5) I'm working on an "encapsulated stack" file format, that I intend to tie-in with a lot of the other work I'm doing. Mainly using it as a sort of template system and possibly as the format of an OXT package manager. I'm using revTools palette as a test subject. I can already tag/wrap up most of the contents of a stack and now I need to get the reverse working, going from "ESTACK" (STACKML? Names?) back into an OXT Stack. This will be useful for making things like the "Resource Center" more easily updatable and extensible.

This is extremely impressive.

Please, however, can you manage a release with point #1 before you go further?

richmond62 wrote: ↑Sun Dec 12, 2021 10:35 am This is extremely impressive.

Please, however, can you manage a release with point #1 before you go further?

I am trying to reign it back somewhat now, since I want to release, at least for others to test/report problems, by Dec. 25th (or maybe Jan 1st).

The problem with Unbranding / Rebranded is that it involved editing most of the IDE. For example for the Resource Center I couldn't just do a search and replace for LC, that was still branded as pre-LC-name-change Revolution! To edit RC I had to disable it's elaborate menu mechanism and delete some outdated and pointless cards, so this is why I made a "Forwarder" stack so I could easily work on replacing it entirely. So since I'm doing all of those IDE edits now anyway, I figured I might as well do the darkMode edits too. Editing the Syntax Dictionary, for another example, involved rebuilding it from 'source' into Sql/HTML/JS, while doing that I realized there's some in-line documentation that wasn't being included in the built Dictionary (the IDE library) so why not include it, particularly since those docs are useful for making the IDE do new things. The point is that everything just balloons into more things. So I let it be an organic process that goes where it needs to (IMO). The IDE has been LONG neglected, that's not really an opinion (you can look at the activity graphs on gitHub) and so I think a couple of small new IDE features are long overdue. Anyway I'm already far in, there's not really any going back now. I could leave somethings unfinished just to get it out to people to try, but I'd rather not.

Oh I've also started rebuilding the Users Guide, which is created in a similar way to the syntax Dictiuonary. It's markdown .md converted to HTML/JS and then finally that gets converted to PDF. The command line tool to convert HTML to PDF needed to be updated (64bit version) but is still not working correctly, but I can use Safari to export the HTML/JS to a PDF file (but with PDF max-page height). This needs more work but at least now I understand the process that was used to build it. Maybe it would be best to just include the Guide as the HTML/JS displayed in a Browser Widget? I mean I doubt anyone is printing any saddle-stitched physical booklet copies from this large PDF anyway.

any saddle-stitched physical booklet

Years ago I restitched (on a frame) 3 books from the early 1700s that had collapsed!
-

richmond62 wrote: ↑Sun Dec 12, 2021 3:26 pm

any saddle-stitched physical booklet

Years ago I restitched (on a frame) 3 books from the early 1700s that had collapsed!
-
bStitch.jpeg

Interesting, I've never done any saddle-stitching myself, unless you count a saddle stapler, but I do appreciate that book restoration is like an art itself.

This weekend has been a wash for me, dev wise, I got the Pfizer COVID booster shot on Sat. and it wiped me out. I slept all of Sunday, but feeling better now.

I'm glad you recovered that quickly.

Having had 2 Astra-Zenica vaccinations I managed to get Covid (3 weeks feeling very bad indeed), and had a Pfizer booster 10 days ago;
so waiting to catch the Omicron variant.

Fantastic work Paul!

Why would we need recompiled engines, and what can we get from it?

Thanks
Michael

micmac wrote: ↑Mon Dec 13, 2021 10:48 pm Fantastic work Paul!

Why would we need recompiled engines, and what can we get from it?

Thanks
Michael

Well for starters, there's this annoying "User/Forum Registration" stack that's embedded into the IDE engines, that doesn't apply to OXT, and it's branded with LC logo. We CAN work around that by creating a dummy registration file ahead of time, which as long as that file is present the registration dialog doesn't appear. This is just a work around though, because the IDE is still doing a check for a pointless registration file every time the user launches the IDE! Sure the check probably only takes a few micro seconds, but I'd still like to remove it.

Another BIG reason to recompile is hardware support.
Recompilation is needed to have a build that runs natively on the new Apple Silicon CPUs. That's not likely to come from me anytime soon as I don't (yet) own any mac with an M1/M1Pro cpu, but eventually this will be essential for running on Mac.
I'd also like like a 9.x build that runs on Raspberry Pi because the last RPi build was 7.x, which doesn't have support for Builder Libraries and Widgets. I no longer own a RPi, but I would buy another (newer) one. They're really great little, low-powered (a USB port provides enough electricity), single board computers. I'm a big fan of them!

Down the road if we want to make changes to script syntax, the core syntax is interpreted by the engine(s) so any changes to the core script language would require recompiling.

Still there's lots and lots that can be done without recompiling, so I'm going to primarily keep working at that, while at a lower priority looking into how the engines are constructed / compiled. Maybe someday some super C++ guru gets involved (or maybe we could do some fundraising to pay one to) and then the lower level stuff gets done sooner, I don't know.

richmond62 wrote: ↑Mon Dec 13, 2021 4:19 pm I'm glad you recovered that quickly.

Having had 2 Astra-Zenica vaccinations I managed to get Covid (3 weeks feeling very bad indeed), and had a Pfizer booster 10 days ago;
so waiting to catch the Omicron variant.

Oh Sorry, bad luck, but imagine how bad it could've been if your immune system wasn't prepared for it ahead of time!

Omicron variant showed up in the state next door, so that's what prompted me to finally make an appt. to get the booster.

Most of my family works in healthcare so this has been one long nightmare. My eldest son was been working on his RN (Nursing) when COVID hit. Trial by fire! He finished his RN, working on his BSN (Bachelors Degree) now. We never went into "lock down", and none of us have gotten COVID (as far as we know). We've been as careful as possible.

imagine how bad it could've been if your immune system wasn't prepared for it ahead of time!

As my favourite doctor (and you'll see by his remark why he's my favourite) said, "Without the vaccinations you'd have a new job growing
flowers in the cemetery."

We've been as careful as possible.

Good: even post-vax, the Covid my wife and I had was not something I would wish on anyone: at least we avoided having to go to hospital:
ate a vast "cocktail" of pills the doctor prescribed and spent nearly 3 weeks as high as kites on something called Declamethasone which is
prescribed to make you as high as a kite so you don't get sluggish and develop blood clots: but at about 1 hour of sleep a night the
recreation of the "Summer of Love" lost its appeal pretty quickly.

Now my antiboody count is sky-high: but whether that will see off the Omicron thing is something only God knows.

Hi Richmond62

I just wanted to register on here to thank you wholeheartedly for your efforts and your, quite frankly, amazing progress.

I've used hypercard back in the day (started on a mac classic when I was 11), through to Supercard, Revolution, and what is now livecode.

I'm more than happy to help test anything, on Intel mac, Linux and Windows 10. I'm not much of a c++ programmer, but I'm full of ideas and improvements ideas if that would be helpful.

Mainly though, as your last post was back on the 14th, I hope you are doing okay.

Your efforts are definitely appreciated, and if you want to send me anything to test, I'll more than happily be a guinea-pig.

Perhaps linux users would be closer to an appimage version one day - something that Livecode themselves would never seem willing t to offer previously.

tperry2x wrote: ↑Tue Dec 21, 2021 9:22 pm Hi Richmond62

I just wanted to register on here to thank you wholeheartedly for your efforts and your, quite frankly, amazing progress.

I've used hypercard back in the day (started on a mac classic when I was 11), through to Supercard, Revolution, and what is now livecode.

I'm more than happy to help test anything, on Intel mac, Linux and Windows 10. I'm not much of a c++ programmer, but I'm full of ideas and improvements ideas if that would be helpful.

Mainly though, as your last post was back on the 14th, I hope you are doing okay.

Your efforts are definitely appreciated, and if you want to send me anything to test, I'll more than happily be a guinea-pig.

Perhaps linux users would be closer to an appimage version one day - something that Livecode themselves would never seem willing t to offer previously.

Welcome!

Jolly nice to be thanked; especially for something I have NOT done.

I'm the cynical, lazy slob who lurks in the background.

PAUL is the one who does ALL the work and deserves ALL the thanks!

Haha, okay - thanks for clearing that up
Sorry Paul, but seriously, it's just great news to see some progress happening with the open xtalk version.

If I can help at all, then I'm more than happy to.
Thank you - both of you, for making this happen.

I'd love to see the standalones or binaries that are built run more efficiently and be smaller. Hopefully this will be possible as open xtalk evolves.

I'm sure there's a lot of legacy cruft left over from revolution, and livecode that isn't used anymore.