OpenXTalk IDE DPE RC3 Test Release

[tperry2x]

A 'RC4' for Mac exists . . .

What chance a Linux version?

Not meaning to step on anyone's toes, just purely to help out.
Here's a linux version of RC4 - all Paul's files from the mac version of RC4, just the linux engine swapped.
You should be able to un-7zip it and run the program.

RC4-linux.png (322.74 KiB) Viewed 20141 times

I do hope I'm not crossing any boundaries with this, I mean - I know OXT DPE is your edition Paul, so feel free to ignore this completely. For me, it's just because I work in Linux - so having a linux version of your RC4 version is handy.
(Also, this being my 9.7.0-dp1 engine, you don't have any registration requirement either at first run). If you want me to take this down though, feel free to just delete this post & I'll delete the file from Mega.

[OpenXTalkPaul]

A 'RC4' for Mac exists . . .

What chance a Linux version?

Not meaning to step on anyone's toes, just purely to help out.
Here's a linux version of RC4 - all Paul's files from the mac version of RC4, just the linux engine swapped.
You should be able to un-7zip it and run the program.

RC4-linux.png

I do hope I'm not crossing any boundaries with this, I mean - I know OXT DPE is your edition, so feel free to ignore this completely. For me, it's just because I work in Linux - so having a linux version of your RC4 version is handy.
(Also, this being my 9.7.0-dp1 engine, you don't have any registration requirement either at first run).

I don't mind at all! I might just give it a test drive on helloSystem (FreeBSD with Ubuntu compatibility layer) because I think that check was the problem causing it to not fully launch.

Is it an AppImage (can't check at the moment), Installer. or just a zip of the IDE folder?

One problem is it looks like tools palette is style for darkMode in your screenshot there, while the rest of the IDE is light.
I think I changed that script to act differently on Linux after that. I really need to put out a newer update.

Thanks!

[tperry2x]

Thank you Paul, I'm glad it was well received.
At the moment, it's just a 7zip file that you unpack and run. No install, no appimage, just a folder that can be unzipped anywhere on linux and run from there. Although you *might* have to right-click, choose properties and 'allow executing as a program' - or however the distro of your choice phrases it of course:

execute-perm.png (3.58 KiB) Viewed 20102 times

I noticed about the tools colour mismatch, but this was only done to get things running in Linux - I've made no changes to it as I didn't want to tweak anything. - I've kind of got my hands full with 'Lite' and having free time to do stuff just with that can be difficult.

[OpenXTalkPaul]

Thank you Paul, I'm glad it was well received.
At the moment, it's just a 7zip file that you unpack and run. No install, no appimage, just a folder that can be unzipped anywhere on linux and run from there. Although you *might* have to right-click, choose properties and 'allow executing as a program' - or however the distro of your choice phrases it of course:

execute-perm.png

I noticed about the tools colour mismatch, but this was only done to get things running in Linux - I've made no changes to it as I didn't want to tweak anything. - I've kind of got my hands full with 'Lite' and having free time to do stuff just with that can be difficult.

OK I'll try to get back to working on some Linux stuff too. It would be cool to get Qt or GTK widgets working, I'd like to try to make some Universal-Native-Control widgets, that either use UI tooling in the OS AND can emulate various versions of them the way the old lookAndFeel syntax does for mid-1990s OSes, having the same (or close) appearance when in Edit mode as in Run mode and also allowing to see appearance for one OS target while using a different OS (or when running inside a web browser). I'm convinced such 'classic controi' as widgets could be made.

Let me explain further...
Take for example the Apple Native Field and Button Widgets, you can't even see what it looks like rendered natively until you are in 'Run' mode. That's because of the way 'Native Layer' of all 'Native' widgets work, that's the rect of the Widget that is passed (via FFI bindings) to the platform's API for them to draw on to. It only does this in Run mode, but you can also draw inside the widget when it's not in Run mode using the built-in libSkia canvas drawing. That is what its doing when you see That big SVG icon when the Browser Widget is in Edit mode. Exention Builder does include messages you can write handlers to handle when going in and out of Edit mode, so you can even do some custom behaviors there. So what I want to do is combine these all into Widget control set that you can set the lookAndFeel property of and they will also be able to use 'Native Layer' render if it's available.

[tperry2x]

So what I want to do is combine these all into Widget control set that you can set the lookAndFeel property of and they will also be able to use 'Native Layer' render if it's available.

So would that pick up on the MacOS accent colour?
What I mean is - in MacOS, you have modifiable accent colours - as in:

accent-colour-example.gif (53.28 KiB) Viewed 20080 times

So, instead of the standard MacOS blue, what about if a user has changed theirs to purple (or Orange as my Mac is set to)? Currently OXT does not pick this up and renders them blue (it doesn't seem to know about accent colours at all).

[FourthWorld]

As Scott Raney and Mark Waddingham have described it, control rendering is initially an OS thing, with final compositing done in the engine.

That is, where the default lookAndFeel is used, which most folks prefer because the emulated renderers built into the engine are ancient and look like it.

Of course customized appearances are possible with scripts setting properties.

But for those wanting standard appearances, the engine's interface with the OS is the key.

[OpenXTalkPaul]

So what I want to do is combine these all into Widget control set that you can set the lookAndFeel property of and they will also be able to use 'Native Layer' render if it's available.

So would that pick up on the MacOS accent colour?
What I mean is - in MacOS, you have modifiable accent colours - as in:

accent-colour-example.gif

So, instead of the standard MacOS blue, what about if a user has changed theirs to purple (or Orange as my Mac is set to)? Currently OXT does not pick this up and renders them blue (it doesn't seem to know about accent colours at all).

Yes exactly, try the Apple Native Button and Field widgets on MacOS and you'll see what I'm talking about.
Those get rendered with REAL Cocoa NSButton objects in the Widget's 'My Native Layer' (underlying that on macOS it is an NSView, might be a customized subclass of NSView).

Additionally, I did that walk-though Extension Builder thing a few months back, which showed how to use Builder's FFI to get the user's OS-wide highlight color (and all other dynamic systemColor's too) using macOS APIs.

[OpenXTalkPaul]

As Scott Raney and Mark Waddingham have described it, control rendering is initially an OS thing, with final compositing done in the engine.

That is not necessarily the case when using FFI in Extension builder. With FFI on macOS we can (and I have) create a new NSWindow displaying a new NSView that the engine knows next to nothing about (just NSObjects refs in variables).

With NON-'Native Layer' Widgets the composited rendering is done by Skia drawing library, and can be composited with the stack/card/controls behind it using a blendLevel property setting. That is NOT the case with a widget using 'Native Layer' which renders on top of everything else, knocking out (versus overprinting), anything underneath it regardless of any blendLevel setting (maybe they've fixed that 'over there'?).

When a widget uses the 'Native layer' and the IDE is in 'edit' mode, the Native Layer does not get rendered at all, but libSkia can still render something else into the Widgets rect (usually a placeHolder icon).

Unfortunately the included 'macOS Native buttons' were never completed enough to even have anything as a place-holder to be rendered, which is annoying and I want to fix it. I think those might have been hastily built only as an example of how to do it, rather than actually being useful to end users.

That is, where the default lookAndFeel is used, which most folks prefer because the emulated renderers built into the engine are ancient and look like it.

I think you meant 'most folks DO NOT prefer the 1990s OS emulated renderers'. I actually do kind of like them but that's because it gives me a nostalgic feeling.

For the Emscripten build, running with asm.js port of SDL, these are currently the ONLY choices for 'classic control' rendering. By default IIRC that is early-Unix 'Motif' theme. You can instead use widgets with custom drawing or a HTML5 'Native' button widget, which creates a separate html canvas from the one created for the stack/card canvas.

Of course customized appearances are possible with scripts setting properties.

But for those wanting standard appearances, the engine's interface with the OS is the key.

No, the 'Classic Controls' only let you style them so much, and what properties have any effect at all depends on the style of the control. It's also not all about color or font style either, there's custom behavior these can have. Try the macOS native field widget out, click in the native feild and you will see that it highlights with a little flash animation of the focus border around the field, and selected text in that feild will be the correct system wide hiliteColor. You'll get nothing like that with the engine's 'classic controls'.
Standard macOS buttons these days are gray with white text (in dark mode), the 'classic' control button does not do darkMode. Drop down menu buttons and tab-buttons are in even worse shape. The best you can do with the classic controls is try to style them to match the operating system and add scripts try to match things like that focusBorder 'flash'.
Classic controls are very much NOT native 'standard appearance'. Maybe they matched the OS at one time, but not anymore.

Those wanting standard appearances should NOT use the classic controls, they are NOT from the OS's UI kit, at least not in a standard way, and they do not match the system on recent versions of macOS.

Also, The ask/answer stacks don't match standard appearance on macOS any more. Alerts and other dialogs now are often square instead of rectangular, and have their buttons stacked vertically instead of horizontally, and the window might even be transparent with a blur effect.

[FourthWorld]

As Scott Raney and Mark Waddingham have described it, control rendering is initially an OS thing, with final compositing done in the engine.

That is not necessarily the case when using FFI in Extension builder.

True, if inclined one can rewrite chunks of the engine in a scripting language.

If the engine source is unavailable/unusable, I suppose there would be no better way.

Of course customized appearances are possible with scripts setting properties.

But for those wanting standard appearances, the engine's interface with the OS is the key.

No, the 'Classic Controls' only let you style them so much, and what properties have any effect at all depends on the style of the control. It's also not all about color or font style either, there's custom behavior these can have. Try the macOS native field widget out, click in the native feild and you will see that it highlights with a little flash animation of the focus border around the field, and selected text in that feild will be the correct system wide hiliteColor. You'll get nothing like that with the engine's 'classic controls'.

When did the hilite border stop working? Last time I noticed it it seemed to be working well, and if left to default would reflect the user's OS hilite setting.

As for the rest of it, seems we're in the same page. It's the dance between the OS and the engine the does most of the control rendering, and attempting to emulate OS things like Dark Mode in script without changing anything in the engine will run into limitations.

That's why the "Appearance Manager" option was added at the turn of the century. Raney got tired of trying to stay on top of all the OS changes happening, esp Mac, by rewriting OS routines in the engine.

Also, The ask/answer stacks don't match standard appearance on macOS any more.

Thank you, yes, another good example, since those are neither system dialogs nor in the engine, they're just stacks. As such, they won't take on new OS conventions automatically, and have to be maintained.

[tperry2x]

Those wanting standard appearances should NOT use the classic controls, they are NOT from the OS's UI kit, at least not in a standard way, and they do not match the system on recent versions of macOS.

Thank you, thank you, thank you!
I've been banging on about this for over 8 months!
We just need some way of rendering an approximation of the correct control in edit mode, then I'd like to substitute those controls (at least on MacOS) to more accurate ones.

Over on the windows side, we have the same issue with Windows 11 - control elements render as windows 10 ones.
So, that needs fixing in the same manner... but differently, using whatever method it's implemented with.

Not to go on about it (again), but Linux is the only platform which is representing these 'classic controls' accurately.

As we have the issue on MacOS and Windows, would it be best to utilise wxWidgets (dl,example)

[OpenXTalkPaul]

That is not necessarily the case when using FFI in Extension builder.

True, if inclined one can rewrite chunks of the engine in a scripting language.

You're loosing me here. I'm talking about hybrid controls written in Xtension Builder that can be used as either approximations of a particular OS look, or as an actual Native UI widget/control from an OS's UI Kit.
Not sure what "if the engine source is unavailable/unusable" means, it is about having a more useful standard set of UI elements that are native or adaptable and easily extensible, without involving the engine source code in any way.

When did the hilite border stop working? Last time I noticed it it seemed to be working well, and if left to default would reflect the user's OS hilite setting.

Did it stop working? It works but it doesn't match the native OS controls effect. These days macOS users can change several different system-wide control focus / accent colors, text highlights, plus darkMode. And 'backing store' on NSWindow/NSview objects can have special 'glass' like transparency effect.
I'm not certain that the IDE inherits the proper focus color from the OS but I am certain that can be fixed using the xBuilder code I mentioned, which uses FFI/objective c to retrieve the colors.

The IDE, like in 'Tools' palette, the highlight color comes from a handler in the IDE scripts, one that would (previously) check for 'edition' type and then set the colors based on that (such as previous 'neon green' color for 'community edition')

and attempting to emulate OS things like Dark Mode in script without changing anything in the engine will run into limitations.

You don't seem to understand what I'm getting at trying to do here, or how xTensionBuilder 'native'-widgets work.

This would only be an attempting to approximate various OS/versions as a stand-ins to render, when in 'edit mode', or in run mode on another OS, that is ONLY if the real-native controls are not available.
And the rendering will be done as with XB drawing the widget which is better sub-pixel rendering and offered finer graphical control than any of the Engine's 'classic' controls.

That's why the "Appearance Manager" option was added at the turn of the century. Raney got tired of trying to stay on top of all the OS changes happening, esp Mac, by rewriting OS routines in the engine.

'Appearance Manager' is no longer very effective, I think the original 'Appearance Manager' was part of macOS 8 and then 'Carbon', to the Engine now this seems to just mean a (custom subclassing of) default OS control style.

Also, The ask/answer stacks don't match standard appearance on macOS any more.

Thank you, yes, another good example, since those are neither system dialogs nor in the engine, they're just stacks. As such, they won't take on new OS conventions automatically, and have to be maintained.

Yes, exactly. In fact I think that was a motivation of mine for adding a fix for accurate macOS system version reporting in macOS 11+, I had been working a version of Answer/Ask stacks attempting to add script that matches that square / vertical stacked buttons dialog box style in newer macOS.

It's worth noting that OS do often have real native equivalent of these sort of dialogs, at least as far as Answer Alert form of Answer command, such as NSAlert https://developer.apple.com/documentati ... lert/style

With the Emscripten Engine Answer/Ask actually do use 'web native' (JS) dialogs instead of the stack versions. Likewise 'Answer Color' form uses the macOS system color picker (by default, it can be changed) instead of a stack based color picker, so 'Answer' is already a syntax with hybrid 'Native' and/or in-engine implementations.

The ONLY ways to get that 'glass' transparent window effect, however is to EITHER use XB FFI OS Native, OR add some more code to the engine. Personally I'd actually prefer it to be external from the engine. Which is one of the aspects of FFI I like, everything beyond the core interpreter language set could be external to the engine. Just like some implementations already are, like Externals (but XB is much easier IMO) such as revSpeak, revDB, revBrowser, etc. are. with FFI xtensions we can link to the original library dependencies without needing them to include them to compile our extension because of dynamic library linking and loading.

[OpenXTalkPaul]

Here's screens of native Mac button, versus some classic buttons styled to try to match the OS.
Hilited native (orange)

Screen Shot 2024-08-04 at 9.50.19 AM.png (30.19 KiB) Viewed 19884 times

Compared to 'classic control' which by default is simply tinted to a slightly lighter blue than non-highlighted blue:

Screen Shot 2024-08-04 at 9.50.32 AM.png (81.85 KiB) Viewed 19884 times

When IDE is in edit mode, the 'Mac native button' widget just disappears from view entirely if not selected, there's not even a placeholder SVG icon displayed (like there is with some other 'native layer' widgets)

Screen Shot 2024-08-04 at 9.47.45 AM.png (94.06 KiB) Viewed 19884 times

[OpenXTalkPaul]

Over on the windows side, we have the same issue with Windows 11 - control elements render as windows 10 ones.
So, that needs fixing in the same manner... but differently, using whatever method it's implemented with.

Not to go on about it (again), but Linux is the only platform which is representing these 'classic controls' accurately.

As we have the issue on MacOS and Windows, would it be best to utilise wxWidgets (dl,example)

Glad we're on the same page with having a more capable/adaptable OXT UI kit.

I have yet to run OXT on Windows 11 so I was unaware of a UI mismatch between Win 10 & 11 platforms.

platform toolkits, wxWidgets gives applications a truly native look and feel because it uses the platform's native API rather than emulating

wxWidgets might help make things easier, we would have to include the binaries for it for each platform it supports.
On macOS it might be best to just use Cocoa directly. Actually that may be the case for Win32/WinRT UI and Linux GTK as well.

[FourthWorld]

That is not necessarily the case when using FFI in Extension builder.

True, if inclined one can rewrite chunks of the engine in a scripting language.

You're loosing me here. I'm talking about hybrid controls written in Xtension Builder that can be used as either approximations of a particular OS look, or as an actual Native UI widget/control from an OS's UI Kit.

Seems we're on the same page here. Things like Dark Mode and some other UI nuances require tapping into OS calls. oxTalk alone can't do the job. But engine enhancement in C++ or add-ons in Builder will have the OS access those tasks require.

While object code will of course have less impact on rendering speed, it's easier to use Builder than C++ (and it should be), the performance difference is less important than not having it at all.

[OpenXTalkPaul]

Now I'm starting to think using Canvas drawing to emulate common OS controls, even if that means creating a bunch of slightly different versions of say 'Button' for a handful of OS and OS versions, might be easier than trying to create a hybrid Native+Canvas Custom drawn control.

This is because eXtensions do not behave as I expected they would when trying to mix the two (canvas draw layers and 'my native layer') into a single module. It's s real pain just to try to get it to consistently render the placeholder when it should while going in and out of Edit mode.

I know it is possible to do, I've done it before in my Apple PDFKit eXtension, but it is just such a pain to get through the context problems that I'm thinking about removing this macOS Native widgets all together, rather than spending any more time on it.
The only other thing I might try before I give up on it is making a 'Composite Widget' that combines two separate 'sub-widgets' with the parent eXtension module managing them.

But the thing is it's really not hard to create canvas-drawn buttons that looks like various macOS, Windows , or other system's styles, specially since all the big OS players have shifted to simple 'flat' style GUIs over the last 15 years or so.

[richmond62]

Is it just me, or?

I opened up OXT DPE RC4 on MacOS 12 today and had a funny feeling how far it has been outstripped by OXT Lite 1.07.

Now I am led to believe that work on OXT 'Heavy' progresseth, but as there NEVER seems to be any updated version of it, I find that both hard to believe and a sadness as I should like to see what its current state is.

[OpenXTalkPaul]

Is it just me, or?

I opened up OXT DPE RC4 on MacOS 12 today and had a funny feeling how far it has been outstripped by OXT Lite 1.07.

Now I am led to believe that work on OXT 'Heavy' progresseth, but as there NEVER seems to be any updated version of it, I find that both hard to believe and a sadness as I should like to see what its current state is.

I work on something just about every single day, so yes there's some progress, but it's certainly not been as much progress as OXT Lite.

Maybe I'm too 'all over the place', or too short on time, or procrastinate too much on the tedious tasks of testing on multiple platforms and packaging distributions.

But I'll try to get something together to upload for upcoming OXT 3rd year anniversary.

[richmond62]

But I'll try to get something together to upload for upcoming OXT 3rd year anniversary.

Aha.

[tperry2x]

Sounds an obvious thing, but I'd certainly recommend a system where you can patch things via an updates system. I've found it invaluable as people report bugs that really do need fixing as soon as possible.

[OpenXTalkPaul]

Sounds an obvious thing, but I'd certainly recommend a system where you can patch things via an updates system. I've found it invaluable as people report bugs that really do need fixing as soon as possible.

I've been meaning to look at your updater to see how I could incorporate that into OXT 'heavy'.

I'm sure that wouldn't work well with a containerized AppImage...not sure about Snap or Flatpack.

Probably would be best to package as a .deb or pkg installer that way things can be put into various areas of the OS where they need to be in (such as a dummy license file or libraries dependencies). That way I could use 'monkey-patching' for quick minor updates too.