OXT Community Sample Stacks, Extension & Resource Management

A place to discuss and plan OpenSource xTalk (not exclusively LCC based)
and Community Builds of LCC ...Ask NOT what xTalk can do for you...
Get involved you DO have something to contribute, no matter your skillset!

Forum rules
A place to discuss and plan OpenSource xTalk (not exclusively LCC based) and Community Builds of LCC
Ask NOT what xTalk can do for you... get involved you DO have something to contribute, no matter your skillset!
User avatar
tperry2x
Posts: 1737
Joined: Tue Dec 21, 2021 9:10 pm
Location: Britain (Previously known as Great Britain)
Contact:

Re: OXT Community Sample Stacks, Extension & Resource Management

Post by tperry2x »

OpenXTalkPaul wrote: Thu May 16, 2024 2:51 am ... rather have that XML UI markup so that I don't even need to write any scripts that create styled 'classic objects' on the fly
Worth mentioning that they are only 'styled classic objects' on MacOS and Windows. In Linux, they are reflective of whatever theme you might have installed, and are correctly referenced from the underlying OS. (This is the way it also needs to work on MacOS and Windows).

This is also why Linux picks up on the native window theme automatically, and MacOS and Windows do not.
User avatar
OpenXTalkPaul
Posts: 1787
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: OXT Community Sample Stacks, Extension & Resource Management

Post by OpenXTalkPaul »

tperry2x wrote: Fri May 17, 2024 9:47 am
OpenXTalkPaul wrote: Thu May 16, 2024 2:51 am ... rather have that XML UI markup so that I don't even need to write any scripts that create styled 'classic objects' on the fly
Worth mentioning that they are only 'styled classic objects' on MacOS and Windows. In Linux, they are reflective of whatever theme you might have installed, and are correctly referenced from the underlying OS. (This is the way it also needs to work on MacOS and Windows).

This is also why Linux picks up on the native window theme automatically, and MacOS and Windows do not.
Reflective of whatever theme is installed? I'm not so sure about that.

When I made Xtension Builder FFI to create a 'Linux Native" (GTK) Button with only default propertie, it didn't quite look exactly like the basic 'classic control' button, for one thing, unless you've changed it (I think I did at one point) then IDE has the name of Fonts to use as "(System)","(Menu)", etc. 'hardcoded' in the IDE script.

If by 'Reflective' you mean Linux controls inherits all their properties from the OS theme then that's great!

On macOS it seems to inherit only fore/backgroundColors for some controls but not others, which is why I changed some of the default properties to have textColor be black instead of empty, while on the 'tab-buttons control' the backColor is explicitly set to be black. Widgets that paint using 'my background color'/'my foreground color' however toggle between light/dark automatically (inherited from the OS).

I thought the Engine generated all of the 'classic controls' on all three platforms, and they're rendered by the Cairo Graphics library, and so are drawn by the engine rather then 'native' (assuming 'Native' means GTK) rendering them. That doesn't mean they can't still inherit properties from the operating system/UI toolkit theme, which could be GTK, or QT, or something else. There really is no 'Native' when it comes to Linux based OSes.

The reason I think the classic controls are all emulated (even if they do inheriting some properties from system UI toolkit theme) is because you can still set the old 'lookAndFeel' property to "Motif" and instantly change every control to look like 1980s-90s X-Windows theme. Likewise on macOS you can set lookAndFeel to 'Macintosh' and everything changes to look (somewhat) like macOS 8 -9, and a there's also a built-in Windows 95/98 style theme.

I'll try to take a look at the C++ source later to see if I find where it creates these objects.

As I've mentioned elsewhere, I'm in favor of having a set of widget extension controls that are based on the classic controls as far as properties, but theortically widgets could do either, use a truly native controls (as with 'Mac Native Button', 'Android Native Field', etc.), OR use custom rendering (by libSkia) and maybe adjust itself to a platform (as far as Font) but for the most part the later would be rendered a lot more consistent across all desktop and mobile/web platforms.
User avatar
tperry2x
Posts: 1737
Joined: Tue Dec 21, 2021 9:10 pm
Location: Britain (Previously known as Great Britain)
Contact:

Re: OXT Community Sample Stacks, Extension & Resource Management

Post by tperry2x »

OpenXTalkPaul wrote: Fri May 17, 2024 9:56 pm Reflective of whatever theme is installed? I'm not so sure about that.
Indeed it does:
classic-controls-linux.png
classic-controls-linux.png (78.89 KiB) Viewed 275 times
The only thing I found is it's really not a good idea to change appearance theme with the IDE running under Linux, otherwise it'll promptly crash (also implying that what it was reading from loaded ram is no longer available).

(This is why under Preferences > Extras in OXT Lite, there's a note that explains appearance themes should be set in the appearance manager).
theme-note.png
theme-note.png (11.28 KiB) Viewed 247 times
This kind of links into what TerryL was just asking, so I'll link that here to tie things together.

I'll also add that some linux themes have transition effects - like when you click a checkbox or radio-button, they are animated. This is also exactly mirrored in the OXT IDE as well, so I believe it's loading the controls faithfully from a memory buffer. (That would be the most efficient way of doing it as the way these are all supposed to look is already pre-loaded in). Likewise, I'm not sure if this is going through the Cairo or LibSkia rendering thread.

Now some people might think that this is actually a pain, because you have to design your UI with various system themes in mind. While that's true to a certain degree, as long as you provide ample space between things, then it means there's at least a cohesive feel between OXT and the rest of the programs on the system when running in Linux.

And anyway, if you are targeting multiple OS's, you have to design your stack / application with how they might look in alternative appearances so...

This is why I have said that I wished OXT in MacOS and Windows were 'system theme aware' far more than they currently are.

I'll also mention the IDE in linux seems to pick up and render the theme correctly on various distros.
(Richmond's screenshot in Xubuntu on another post):
Image

Here's another example of how it renders correctly. This time on AntiX Linux, using the iceWM window manager:
Image
OpenXTalkPaul wrote: Fri May 17, 2024 9:56 pm There really is no 'Native' when it comes to Linux based OSes.
That was probably a bad choice of words I used. Yes, there's no "native" because it is totally flexible and customizable (much like the rest of anything else on Linux) - there's pretty much a way to change anything if you've got a mindset to do it (and to be honest, that's why I'm an advocate of it over anything else). I believe whoever put the linux version of the engine together had an understanding of this, and very much had that in mind when they were thinking about how to render 'Classic Controls' (and the entire IDE for that matter). For that, I'm hugely thankful, as it's much more 'unified' (would that be the better word?) with the rest of the OS.

An example of how MacOS is not consistent, I reference back here (ages ago now) with this comparison image.

Image
On the left, you have a classic control drawn on MacOS 10.15 within OXT. On the right, same machine - but Apple's System Preferences (which is a good yardstick because you know they draw their controls correctly) shows how it should render.

Similarly, Windows 11 draws it's classic controls as 'emulated' Windows 10 ones. (I don't have windows 11 at hand to demo that though at the moment).
User avatar
OpenXTalkPaul
Posts: 1787
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: OXT Community Sample Stacks, Extension & Resource Management

Post by OpenXTalkPaul »

This is why I have said that I wished MacOS and Windows were 'system theme aware' more than they currently are.
...Although in those macOS controls screens, you do see it does have the correct 'little arrows' appearance to the drop down menu, I believe checkboxes and radio buttons do too, so it seems the engine can adapt to Cocoa app appearance somewhat in a similar manner. When you run a stack on Snow Leopard 10.6, Lion 10.7, etc. and then I open the same stack on Big Sur 11 or Sonoma 14 you can see the difference in the way the controls look. This was goof enough for various macOS versions, until they started doing thinkgs like swapping the special adaptive System Colors foregroundColor and backgroundColors so that they could have 'darkmode' in Cocoa apps, which happened fully with 10.14 Mohave. My guess is that the engine doesn't pick up on the finer point changes, in the other adaptive colors secondaryCoolor, tertiary, etc. and doesn't use those colors for regular button fills the way it should.

My answer to these problems was stop-gap measures, setting default values that at minimum allows buttons (tab buttons, menu buttons, etc.) labels to be at least be readable in darkMode (even if they have incorrect fill colors for the 'theme').

It was also why I was getting interested in color palettes, in particular getting system colors from MacOS (via Extension FFI / Objective C), because it's not enough to respond to dark/light, things like control accent color and text selection color can also be dynamically changed by the Mac user (but the Engine currently doesn't get any notification of those more granular user changes).

And this was also why I created that NEW-classic control 'fillButton'. I was trying to match the newer macOSes system grays/whites fill colors for buttons with that. But even then these classic buttons just don't look as good for that purpose, as Widgets or Graphics objects do, the 'anti-alias' rounded edge-smoothing for 'classic buttons' is not very good (non existent).

IIRC, I also did some work on setting via the IDE library the correct font for a particular macOS version. The Mac System font has changed a few times in the past decade, which has been fairly subtle difference (you might remember that discussion on 'hard-coded' fonts, but it was quite a ways back).

Unlike Linux engine (or the others), the macOS engine does receive system notification of when the general 'systemApprearanceChanged' for general 'theme' changes but there's only really 2 themes; light/dark, unless you count different macOS versions.

You can also check 'systemApprearance' engine property on Mac which returns string "light or "dark", I'd like to try to implement something like that for Linux, even if it returns the full theme name like "‘Adwaita Dark".
That engine message is mac-only (maybe works on iOS too? not sure).
The property doesn't currently return accurate theme info for any on other platforms beyond macOS.

But yes, I agree. macOS hasn't really been UI theming friendly since the 1990s / OS8 Appearance Manager, and while there were some hacky theming things for OS X they all seemed to be gone now, 'Carbon' became defunct, and OS security sandboxing has gotten tighter.

The hackery friendliness of Linux is exactly the sort of thing that attracts me to it.
For quite a while there I was working with OXT on Ubuntu Studio with KDE Plasma, and stack UIs did largely follow the theme there too.

But on Linux are they rendered by the engine and not GTK/QT?
I kind of still think the Engine must do the rendering in order to be able to add effects, shadows, control the blending, etc.
User avatar
OpenXTalkPaul
Posts: 1787
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: OXT Community Sample Stacks, Extension & Resource Management

Post by OpenXTalkPaul »

Yeah, It's non-trivial to try to match the macOS dark drop-down menus using the classic controls. I could actually get closer by switching the 'lookAndFeel' to classic macOS, because that enables a few more colorizing options for the controls (but introduces other retro-look problems of course).

A pop-up menu extension widget could work better (if we had one).
User avatar
OpenXTalkPaul
Posts: 1787
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: OXT Community Sample Stacks, Extension & Resource Management

Post by OpenXTalkPaul »

There's some interesting notes on the IDE's 'package' format used with extension in the source C++ comments:
https://github.com/OpenXTalk-org/OpenXT ... C1-L157C86

I'll add my own emphasis and responses here in an attempt to correct some no-longer accurate or updated things:
// Packages are a collection of modules which share a common set of foreign
// code and resources.
Just to be clear here, package modules don't necessarily use any foreign code or other resources.
Library modules don't even need to be written using XTension Buider, they can be written in regular XT script so long as they have the extension initialization/uninitialize handlers (a few examples script-libraries-as-extensions already come with the IDE)
// When a package is loaded into memory, all its modules are loaded also making
// them available in the module namespace and accessible through the module functions.
I remember reading somewhere that you could have main-module and sub-modules but I've still never seen a package that did this
// A package loaded from a particular file, or with a particular name can only
// be loaded once - if an attempt is made to load a package from a file and that
// package has the same name as a loaded package it is an error. If an attempt
// is made to load a package by name and such a package is already loaded it just
// returns that package.
Good to know how conflicting extensions module names are resolved.
// Packages can be unloaded from memory, however they are not completely removed
// until it is possible to do so - i.e. until there are no instances of any module
// within the package in use.
I've hit up against this many times (a bug in Extension Builder stack probably) where I've left a widget demo stack opened, then 'unloaded' the widget's module and then tried loading a recompiled version of the same module, only to have it error loading, because the first build never really unloaded. If you're letting Extension Builder stack manage the test stack generating then this isn't a probably, but I usually wind up with a separate custom tester stack.
// Packages are a zip archive with the following structure:
// <root>/
// manifest.xml
// module.lcm
manifest.xml, module.lcm get auto-generated by extension builder stack
// support/
// <files for the IDE / store etc.>
This is where the module's PNG icons can (optionally) go, there can be two bitmapped icons, old-school regular size and plus one for HiDPI screens. These icons can represent the module in the IDE when no SVGIcon is included in the module.

This is also where a _defaultScript file can (optionally) go, which is a file that can contain multiple pre-written script handlers that can be use with the module, these with appear in the available handlers list in script editor.
// modules/
// <compiled submodule files>
Ah hah! This is where linked sub-modules should go!
// symbols/
// <compiled module debug info>
I HAVE NO IDEA WHAT THIS FOLDER IS! I've never seen it. Maybe it has something to do with debugging symbols/name space? In Foreign Code libraries?
// resources/
// <shared resources>
You can put images that go along with your module or whatever sort of files you want to include here.
OXT SVGIcons loader thing stores tab-sep-value files here where the module can always find them.
// code/
// <compiled foriegn code>
This is where foreign code library binaries go, they go in a sub-folders name by platform+architecture.
// source/
// <original source code>
Usually I have a single source file at the root level, but maybe this is meant for source for any sub-modules?
// docs/
// <docs tree>
This is where the 'guide' folder would go for your module.
// There is either a widget or a library node. Widgets can have properties and events,
// libraries only handlers.
There's also a third kind for language modules ( the Builder language can be expanded)

This info should be in the XT Builder guide.
User avatar
OpenXTalkPaul
Posts: 1787
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: OXT Community Sample Stacks, Extension & Resource Management

Post by OpenXTalkPaul »

NOT listed in the above source file comments is the 'samples' folder, that's where you can put demo stacks to show off the capabilities of your extension.
Also apparently 'Snippets' can apply to extension packages, not sure if they're supposed to go in a 'Snippets' folder. I have no example for this to go on so I'll have to sift through the libraries and see if I can find any more references to them.
Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests