Inheritance

All flavors welcome.
Forum rules
Be kind.
Post Reply
User avatar
richmond62
Posts: 2776
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Inheritance

Post by richmond62 »

Today, 'over there', I found out that everything does not inherit everything, and even amongst the mages of the language there is some confusion.

It might be a good thing to work out which objects inherit what from what, and then document that.

https://forums.livecode.com/viewtopic.php?f=7&t=38670
https://richmondmathewson.owlstown.net/
FourthWorld
Posts: 281
Joined: Sat Sep 11, 2021 4:37 pm
Contact:

Re: Inheritance

Post by FourthWorld »

"Everything" is broad enough that the statement can only be true. ;)

But in the case of fields, the default favors readability, with the backgroundColor of the object set to provide a light color against what is usually dark text.

Clear that backgroundColor property and see what happens once it's no longer overriding the inheritance for that property.
User avatar
OpenXTalkPaul
Posts: 1574
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Inheritance

Post by OpenXTalkPaul »

FourthWorld wrote: Mon Oct 16, 2023 3:22 pm "Everything" is broad enough that the statement can only be true. ;)

But in the case of fields, the default favors readability, with the backgroundColor of the object set to provide a light color against what is usually dark text.

Clear that backgroundColor property and see what happens once it's no longer overriding the inheritance for that property.
Text Fields (both the Engines and of course the macOS 'native' fld widget) and some other controls/parts, at least on macOS (and it seems on some Linux(es)) with v9.6.3, if they are not set or they are set to empty (or 'use owners color' in the IDE menus), will inherit their foreColor and backColor properties all the way up the chain, group, card, stack, app (engine), and then even from the operating system. This includes builder Widgets IF they are set up in a particular way; by shadowing one of the standard color property names (for example in extension builder: 'my background paint' = backColor ) and using it as a fill in a drawing operation. You can see this with the SVGPath widget which will toggle a glyphs fill fore/back colors on darkMode mode change just like text fields do.

If you toggle OpenXTalk DPE's darkMode preference or change modes in the macOS control panel, it toggles the native darkMode/light-normal modes effecting the IDE on the NSApplication level, which effects all open or newly opened Stack windows (NSWindow objs) that don't explicitly have dark/light mode individually set... so with this you can see the effects, exactly what inherits what color wise, instantly. In regular fields darkMode automatically changes un-styled text to white and background fill to black for. Other things that have had no properties set, such as the card background color may also automatically change from light/dark (grey) fills. Additionally with macOS native darkMode there may be 'vibrancy' (whatever that means) added, which seems to add a bit of contrast to some objects.

To make matters tricky, macOS changes from version to version. The macOS selection color global property in newer macOS can have transparency (RGBA) in like a 'color only' or 'darken only' paint mode, and it doesn't seem to auto-change it based on the light/dark mode, which has thrown me off... if it's set to a light highlight color in darkMode, the highlighting basically disappears. This is a macOS bug I guess, but easy to fix by changing the highlight color in the macOS control panels.

Color inheritance generally works fine for plain text fields but NOT for buttons, those do not seem to behave the same way. A standard button will inherit it's foreColor (textColor), but NOT change anything about the backColor fill for you and so in darkMode you wind up with White text on a light background and becomes unreadable. You need to set the textColor to black, and for 'Tabs' Buttons you need to set the backColor to black to achieve readability. My (hopefully temporary) fix for these has been to change the default button textColor property to be Black (which the IDE pulls in from tab-separate-values files) and also creating an new 'classic' control that is White Text on Grey (simply by adding some rows to those tab-separate-values files and making an icon for it).
User avatar
richmond62
Posts: 2776
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Re: Inheritance

Post by richmond62 »

That's an interesting read.

I have never really taken inheritance seriously before EXCEPT with regard to buttons and their fonts going wonky on end-users' machines.

Because of this concern my Devawriter Pro contains NO buttons at all, only images made of buttons I have set up to look the way I want them.

Similarly, the standalone requires my bespoke font to be installed to guarantee how things appear in text fields.

The fact that 'bog normal' buttons will go wonky if a Mac end-user has dark mode on (I have had dark mode on since the day I installed Mac Catalina) is a real pain in the bum.

Of course LC 963's GUI does not react at all to Mac dark mode (stays the same as ever).

Obviously your decision to implement dark mode in your variant of OXT has much farther ramifications than I had realised.
https://richmondmathewson.owlstown.net/
Post Reply

Who is online

Users browsing this forum: No registered users and 27 guests