Tools palette options

[mwieder]

I'm starting this specifically for my PowerTools plugin, but this may also be a good place for discussion about the tools plugin in general and also for other revTools replacements.

[mwieder]

Paul- I downloaded your darkmode/lightmode version and the screenshots look nice but it misbehaves here in several ways. I can't tell what changes you've made so it's a bit hard to debug. I can definitely say that the preopenstack handler is not fully completing its functionality, but haven't dug in any deeper yet.

[mwieder]

@OpenXTalkPaul-

Here's my proposed patch to fix the darkmode/lightmode thing with revTools:

https://github.com/OpenXTalk-org/OpenXt ... on/pull/26

[OpenXTalkPaul]

Paul- I downloaded your darkmode/lightmode version and the screenshots look nice but it misbehaves here in several ways. I can't tell what changes you've made so it's a bit hard to debug. I can definitely say that the preopenstack handler is not fully completing its functionality, but haven't dug in any deeper yet.

I'm pretty sure I only commented out a single line from PowerTools script that set a backgroundColor fill, the rest of it was manually inspecting objects and removing back/foreColor fills so that the stack will then inherit those colors from macOS.

[OpenXTalkPaul]

@OpenXTalkPaul-

Here's my proposed patch to fix the darkmode/lightmode thing with revTools:

https://github.com/OpenXTalk-org/OpenXt ... on/pull/26

Thanks Mark!

My response on Github:

The thing is the Tools stack I had always intended to swap out with something (hopefully) much better (see 'Tools redo' thread on the forums for example). I'd rather not put handlers for dealing with dark mode into IDE stacks, rather I think it should be handled in a separate library, one that we can then adjust for peculiarities in certain Linux themes or that can use a JS handler when run in a web browser environment to figure out if the user is in a dark theme / has light foreColor/dark backColor. We want a cross-platform 'darkMode'. Since this may involve evaluation of RGB triplets (because maybe the user is in a 'orange text on blue backColor' mode?), I think this should be put into an 'OXT color' library that covers the functionality of Quatram Color Library, tinyColor library, along with some handlers that I've created to RGB stuff and Read GIMP Color palettes.

The 'tinyColor' library I mentioned contains scripts for figuring out if the system is in a 'darkmode' theme on Windows and Linux. Additionally I have a handler that does that with JS when running inside a web environment.

The 'Tools Redo stack' thread is here:
https://openxtalk.org/forum/viewtopic.php?p=9016#p9016

Keeping appearance and color related handlers in a library would make it so that the functionality can be easily included within a standalone. I believe that currently the engine delivers a 'sytemAppearance pMode' message only on macOS, but a check for it on 'on resumeStack' could be added to such a library to make that happen on all platforms.

So...
This hypothetical 'OpenXTalk Color library' I was thinking could maybe also have some handlers that could do things to target object(s) like reverse-recursively strip all color setting from the object(s) (or text chunk(s)) passed to it, so that foreColor / textColor becomes 'empty', which is the bulk of the chore of making a stack that's been manually stylized in a way that looks bad when toggling light/dark to inherit it's colors from the revMenuBar, or Home stack, or engine, or macOS (in that inheritance order).

The other thing that I was thinking about a color/appearance library was this... when I was learning how the IDE gathers its default properties and things from mostly tab-delimited files, I inserted a new stack property 'darkMode', on other OXT or LC IDE this would just appear in the 'custom properties' in property inspector, but on my build it appears as a checkBox in the 'basic' tab of the property stack (because I altered my stack properties tsv file). So I was thinking that property would be used to indicate that any open stack with that property set to true would receive an a 'systemAppearanceDidChange' message, or maybe the library would 'auto switch' the stack's foreGround/backGround colors. I don't know.

[mwieder]

There are two things at play here:

1. Switching dark/light mode
2. The code that does the appearance switching
...and possibly 1a. recognizing when the mode is being switched

I'm attaching my latest build of PowerTools which implements item 2. All the code is at the bottom of the main stack script in the darkMode handler.

This allows for decoupling the stacks. From the home stack or the messagebox

Code: Select all

dispatch "darkMode" to stack "revTools" with true|false

will set the appropriate appearance.
The problem with instead putting the code into a colorization library is that the library is then tightly coupled with the stack(s). That's the problem I have with your home stack handlers that expect certain groups etc to be in the tools palette. Issuing just a dispatch lets the target stack handle its own colorization without the need for the sending stack to know intimate details about te targets.

I'll have a look at the tinyColor stack to see about win and linux mode switch captures (1a).

The code encapsulated in my tools palette:

Code: Select all

on darkMode pIsDark? pForeColor, pBackColor
   local tCardColor
   
   lock screen
   if pBackColor is empty then
      put "Black" into tCardColor
   else
      put pBackColor into tCardColor
   end if
   if pIsDark? then
      if pForeColor is empty then
         put "White" into pForeColor
      end if
      set the foregroundColor of group "background" to pForeColor
      set the backgroundColor of group "background" to pBackColor
      set the foregroundColor of group "Tools" to pForeColor
      set the foregroundColor of group "Graphics and paint" to pForeColor
   else
      if pForeColor is empty then
         put "Black" into pForeColor
      end if
      if pBackColor is empty then
         put "#E8E8E8" into pBackColor
      end if
      set the foregroundColor of group "background" to pForeColor #171717
      set the backgroundColor of group "background" to pBackColor #E8E8E8 
      set the foregroundColor of group "Tools" to pForeColor
      set the foregroundColor of group "Graphics and paint" to pForeColor
   end if
   set the backgroundColor of card "main" to tCardColor
   set the opaque of group "Tools" to pIsDark?
   set the opaque of group "Graphics and paint" to pIsDark?
   set the opaque of group "gpWidgets" to pIsDark?
   unlock screen
end darkMode

[OpenXTalkPaul]

The problem with instead putting the code into a colorization library is that the library is then tightly coupled with the stack(s). That's the problem I have with your home stack handlers that expect certain groups etc to be in the tools palette. Issuing just a dispatch lets the target stack handle its own colorization without the need for the sending stack to know intimate details about te targets.

Sorry if you already understand this but just to reiterate some finer points of supporting 'darkMode'...

The ENGINE already supports darkMode partially, it implements a message 'systemAppearanceChanged pMode' (pMode will be either dark or light) for macOS, iOS (and maybe Android?) engines, and there's also an engine level property 'systemAppearance' which will contain either 'light' or 'dark' but it is not accurate on all platforms, for example this always returns 'light' on Emscripten engine.

So I was thinking this would be an Extension library (and NOT the 'start using' old-style library) the kind that gets initialized on startup (the same way revIDELibrary and other IDE libs get inited). The library would have an 'on resume' handler so that when the Engine resumes, it checks if running on Linux or Windows and checks the theme, then dispatches 'systemAppearanceChanged dark' message to 'Home' stack of IDE or to 'the mainStack' (same message the Engine sends on macOS), if not it just passes the 'resume' message. The reason systemAppearanceChanged is in the home stack is because that's where the message already gets sent by the engine when running the IDE, but the message is actually sent to your project's mainStack in a standalone.

DE-coupling is actually what I had in mind, these handlers would be applied to arbitrary lists of stacks, object and/or chunk list. So for example there could be a handler 'stripStackTextColors pObjCnkList', you would then pass this handler the long ID of any stack (or a list of stacks) and it would go through all the controls in the stack making all text field textColors be empty ('use owner's color') and from then on the operating system's theme sets those colors automatically (at least that's the way it works on macOS).

However, ideally all of the 'IDE stacks' will be ALREADY be styled in such a way that they inherit fore/textColor and backGround fills from the OS (compatible with macOS darkMode), so NO messages at all will need to be sent to those stacks. At that point this library's sole purpose would be in making life easier for stack authors who want to support dark/light theme switching (plus a bunch of other color related handlers). Make sense?

I was already looking to consolidate various color related handlers into a single cohesive library anyway, so this idea fits.

I'll have a look at the tinyColor stack to see about win and linux mode switch captures (1a).

Yes do look at that.

Also if you can take look at my 'Tools redo' stack on macOS 10.14 or better while toggling the dark/light appearance in the macOS System Settings, you'll see that the SVG Path Widget based icons I used automatically change from black to white. based on the OS theme, this is because in the Extension Builder code for that widget it's set to use 'my foreground paint', in other words 'inherit this color from the engine'.

[mwieder]

Paul-

OK - I do see where you're going with this. A few comments though...

I looked at tinyColor and the only insight I gained was the Windows registry location for darkmode. There is no equivalent as far as I know for linux since it would be dependent on a myriad of desktop managers, KDE vs Gnome vs xfce vs whatever. Also the tinyColor stack just looks at the current setting and doesn't respond to changes in mode. On osx the systemAppearanceChanged message is issued when the mode changes - I don't know of a similar mechanism for Windows or for linux.

I normally run dark mode on osx and a dark theme on linux and have never found the PowerTools colorization a problem. Inheriting the system colors/mode does work in your test stack, and I see what you did there, but while the main stack is mostly readable (and with a few tweaks could be even more so) the other panels (Graphics, Widgets) are much less so. The Widgets datagrid is all but unusable with the dark background.

In the IDE the systemAppearanceChanged message is received by the home stack, and other IDE stacks may inherit their colorization from it. Since the tools palette is only usable in the IDE I think it's a separate issue from your discussion of the lcb widgets that would change their colorization in standalone apps. I would prioritize usability over theme matching. Possibly a blend of inheriting the colorization theme and overriding it locally (for instance the text on the OK and Cancel button objects needs to be black to be visible).

[OpenXTalkPaul]

Paul-

OK - I do see where you're going with this. A few comments though...

I looked at tinyColor and the only insight I gained was the Windows registry location for darkmode. There is no equivalent as far as I know for linux since it would be dependent on a myriad of desktop managers, KDE vs Gnome vs xfce vs whatever. Also the tinyColor stack just looks at the current setting and doesn't respond to changes in mode.

Hmm, I thought there was a routine in tinyColor that looked at a "free desktop" file text color to determine dark/light, I would think any good Linux theming software would try to support FreeDesktop.org standards? Anyway, I believe we can make an invisible temp graphic and then check its effective color props see what fore/back colors the Graphic control inherited.

On osx the systemAppearanceChanged message is issued when the mode changes - I don't know of a similar mechanism for Windows or for linux.

Right, that's one reason why I think it needs to be in a library extension, that could check for it on resume / resumeStack and then respond or generate the same/similar message on platforms without any theme switch notification from the OS.

I normally run dark mode on osx and a dark theme on linux and have never found the PowerTools colorization a problem. Inheriting the system colors/mode does work in your test stack, and I see what you did there.

On macOS 10.14+ (Mohave+) if your OXT or LiveCode window frames are not in darkMode then the NSApp or NSWindow is NOT in macOS 'darkMode'. In OXT there is a XBuilder library I wrote called 'OpenXTalk.org macOS Native Tools" this has handlers that can toggle dark/light either on the entire App (NSApplication obj) or on a single NSwindow when passed the window ID of the stack window. Without that mechanism there's no functional support for darkMode. So my question is was your IDE REALLY darkMode when you looked at it?

but while the main stack is mostly readable (and with a few tweaks could be even more so) the other panels (Graphics, Widgets) are much less so. The Widgets datagrid is all but unusable with the dark background.

Yeah I meant to get to that, the snapshot icons that are generated to represent Widgets, that's clever but I would only use that as a (second to) last-resort for getting a Widget icon. One reason I say that is because some Widgets may not render anything at all until they're placed on a card or until they're viewed in run/browsemode which is the case with some 'Native Layer' widgets ( if you look at 'macOS Native button' widget in PowerTools it's completely blank. Other's may render but not render recognizably until they're placed onto a card (like the IDE's Palette Actions widget). Most Extensions should have either an SVGIcon path-string embedded into them and they can also include a .png icon and a .hidpi.png icon (for Retina / 4K + displays), so I would look for any of those before generating one from a snapshot of a place widget. For now what I have in my 'Tools redo' stack is SVG-only, if that's missing it uses a default SVG-path string (my vector version of ResEd Jack-in-the-box), but I will eventually add the png based icon support and maybe add your method as a fallback.

In the IDE the systemAppearanceChanged message is received by the home stack, and other IDE stacks may inherit their colorization from it.

Two clarifications:
1) On macOS in the IDE the systemAppearanceChanged is sent to homeStack, HOWEVER in a standalone .app it's sent to the mainStack.
2) While it is true that other stacks would inherit fore/back colors from Home Stack, the Home Stack doesn't have either property set, and wouldn't unless a script specifically sets them. The Home stack is a 'script-only' stack in OXT, so it has no built-in UI properties and I haven't added any script that sets them.

Since the tools palette is only usable in the IDE I think it's a separate issue from your discussion of the lcb widgets that would change their colorization in standalone apps.

I don't see what is to discussion about that. It's how it works, XBuilder extensions can inherit colors, and the SVG Icon widget does that, the same way graphic controls inherit their fore/textColor and backColor.

I would prioritize usability over theme matching. Possibly a blend of inheriting the colorization theme and overriding it locally (for instance the text on the OK and Cancel button objects needs to be black to be visible).

I do prioritize usability, and yes certain 'classic controls' don't look correct with the macOS system dark theme, that's because they are not realnative UI widgets (not an NSButton, NSMenu, etc. objects), I believe this can only be fixed properly in the Engine source. My stop-gap fix for now was to alter the default properties of certain classic-controls, like the plain button style which I now have with black as its default foreColor, I also added a 'new-classic' control 'Filled Button' that is a white-text on gray backColor button to make life easier in a dark world. Also, I just about have an entire alternative set of UI widgets that can serve as replacements for all of the classic controls and I think something like a universal-native-button could be made as well.

Lastly, who ever said you can only have a 'Tools' palette on desktop platforms?
I've already test MetaCard's Tool palette on Emscripten Engine in a browser and it works, I want my 'Tools redo' to do the same.
Here's some screen shots showing the difference in PowerTools depending on macOS dark/light mode. Notice how some of the text becomes unreadable from one to the other.

Screen Shot 2024-06-20 at 12.43.15 PM.png (160.29 KiB) Viewed 3828 times

Screen Shot 2024-06-20 at 12.43.28 PM.png (161.72 KiB) Viewed 3828 times

Screen Shot 2024-06-20 at 12.44.17 PM.png (110.84 KiB) Viewed 3828 times

Screen Shot 2024-06-20 at 12.44.26 PM.png (112.03 KiB) Viewed 3828 times

[mwieder]

Right, that's one reason why I think it needs to be in a library extension, that could check for it on resume / resumeStack and then respond or generate the same/similar message on platforms without any theme switch notification from the OS.

Nice. I like that idea. I put the following code into the home stack and it seems to be working out so far for PowerTools and could easily be extended to a more general approach.

Code: Select all

local sCurrentDarkMode
on resumeStack
   if the systemAppearance is not sCurrentDarkMode then
      put the systemAppearance into sCurrentDarkMode
      dispatch "darkMode" to stack "revTools" with sCurrentDarkMode is "dark"
   end if
end resumeStack

So my question is was your IDE REALLY darkMode when you looked at it?

No, it certainly wasn't. I was referring to the Mac option of dark mode itself, not the IDE.

Most Extensions should have either an SVGIcon path-string embedded into them and they can also include a .png icon and a .hidpi.png icon (for Retina / 4K + displays), so I would look for any of those before generating one from a snapshot of a place widget.

Well, I went the other way. I want users to see what they're about to drag onto a stack, so I create the controls and widgets on the native platform and show a thumbnail image where I can. The monochrome svg images don't give the same feedback.

Note that your screen shots are from an older build of PowerTools, not what I've updated for this purpose. Here's the latest build (v2.3.8)

Lastly, who ever said you can only have a 'Tools' palette on desktop platforms?

Not me. I said only in the IDE. Admittedly I haven't tried it on the web, but I don't have a lot of interest in a web-based IDE.

[mwieder]

I want to push back on the idea of having the IDE change properties of stacks, at least stacks outside the IDE itself.
Using the latest build of OXTLite *every* thirdparty stack in my plugins folder that has a visible component ends up on the other side of functional when their foreground and background colors are changed or set to empty.

This places an onus on thirdparty developers to design their stacks in a way that is usable in both light and dark modes. In addition it degrades the compatibility with LiveCode. Stacks designed using OXT will probably work with LC, stacks designed in LC have a lower probability of working without changes in OXT.

What I'd rather see, and what I've done now with the latest PowerTools and a small tweak to OXTLite, is place the visible mode changes in the stack itself, and then dispatch a message from the IDE to the stack to make the changes. That serves the purpose of decoupling the visible changes from the change message, leaves it up to the stack designer to support or not support mode changes, and if so what the changes should look like. As I've seen so far there doesn't seem to be a one-size-fits-all approach to mode changing unless you're working with a strictly monochrome world.

[OpenXTalkPaul]

This places an onus on thirdparty developers to design their stacks in a way that is usable in both light and dark modes. In addition it degrades the compatibility with LiveCode. Stacks designed using OXT will probably work with LC, stacks designed in LC have a lower probability of working without changes in OXT.

I can only speak for OXT DPE ('aka 'Heavy'), but the 'darkMode' property I've added to stack properties doesn't effect file-format compatibility at all, 'darkMode' just shows up as a custom property when such a stack is opened in LC CE or OXT Lite. Also I haven't actually implemented anything that does anything with the property. It was more of an experiment in adding properties via those tab-seperated-values props files. I'm still very much open to ideas about best way to implement supporting for auto-mode switching darkMode.

I'm all about supporting darkMode because I use it 24/7/365 now. I think in 2024 it would be a mistake for stack authors to not take that into serious consideration if they plan on sharing their work with others.
I don't know why you would think that OXT darkmode support would break compatibility in either direction? if LC were to really, fully implemented native macOS 'darkMode' support (have they in v10?), then I imagine their users will face the exact same same issues with preexisting stacks. Preexisting stacks looking bad in macOS' darkMode isn't OXT's doing, it's the combination of factors: the way that macOS implemented darkMode(s), the way 'classic controls' were implemented in the engine, and the way people have long designed their stacks assuming that the foreColor/textColor would always default to black.

Anyway I can't worry too much about what LC is doing, although I don't think they would break backward compatibility with v9 engine for no good reason. OpenXTalk here is a separate xTalk project now so I'm not going to worry too much if something I do breaks compatibility with LC, although I do want to avoid that if possible.

If a stack author doesn't want to support mode switching they don't have to. The simplest way to ensure WYSIWYG colors in either mode is probably just to explicitly set fore and backColor, on the stack level and then everything else in the stack inherits from that. Your PowerTools for example, most of it looked fine in Mac darkMode, everything except for the textColor looked the same in either light or dark modes because most of it had color properties explicitly set, there was only one line of script that set any color prop.

Sooooo... What about doing something like the IDE library messages (perhaps 'systemAppearanceDidChange') so that stacks can subscribe to the library in order to receive the message if they choose to?
I will say that my feeling about IDE messages is that there are already too many being sent too often.

[tperry2x]

...admittedly I haven't tried it on the web, but I don't have a lot of interest in a web-based IDE.

I find I keep pivoting between thinking that the Idea of a web implementation (if even only local to the machine, not requiring internet access - for use cases Richmond has pointed out where internet may be an issue) is a good one.
But then I encounter stuff like this, which reminds me how often web standard change, and are things outside our control - meaning that the entire IDE if housed in a browser could be dead with a browser update.

mega-compat.png (95.25 KiB) Viewed 3793 times

So for this reason, I'm a bit undecided if a web-app is the way to go or not.

On the topic of Dark mode et al...

...it degrades the compatibility with LiveCode. Stacks designed using OXT will probably work with LC, stacks designed in LC have a lower probability of working without changes in OXT.

As Paul mentions above, I don't think we honestly have to care at all about LC compatibility. Especially if they are dropping the stack term. How long before the compatibility is broken. As mentioned, it may already be that way to a degree anyway. We needn't worry about developing stuff for their format, just as they don't need to worry about supporting OXT formats in any way.

From our point of view, a new user to this could pick up OXT and start using it - saving as an oxtstack, and be none the wiser about using .livecode formats. We really only care about them using OXT right? We are doing our own thing here after all.

On the topic of Arm processors, which I'll go and find the thread on now... (I did mention I'd say no more about it), but this was the last post regarding that (at the time of writing this post)

[richmond62]

I feel that compatibility with LiveCode should right at the bottom of any OXT list of priorities. LiveCode has already drawn away from 963 (note that I do not want to say 'drawn ahead') in several ways, and has declared its intention to do that extensively sooner or later.

This might be seen as a demonstration of how it wants to dissociate itself from its open source period completely.

Anyone who has shelled out the largeish sum of money for a LiveCode licence is unlikely to want to 'port' their work to OXT: and the likelihood of anyone going the other way would seem increasingly unlikely.

[richmond62]

Not that that should preclude us doing the odd spot of reading from time to time:

https://livecode.com/release-9-6-12-stable/

[richmond62]

1. OK: let's be 'racist' and discuss a browser-based version of OXT and less-privileged types in places where internet is either 'NOT" or crap.

2. AND, the ever-changing nature of web-browsers.

Logically enough, I'll address #2 first.

On my Polycarbonate iMac running MacOS 10.7.4 I use 2 browsers called SeaLion and InterWeb with which I can access about 98% of websites.

So, I would suggest that any browser-based version of OXT target those browsers as anything more 'modern' will cope with anything they can cope with.

As SeaLion and InterWeb are both Open Source it might not be a bad thing to package any browser-based version of OXT with one of those web-browsers.

https://github.com/wicknix/SeaLion

https://github.com/wicknix/InterWebSnow/

OK: back to point #1.

By bundling a browser that 'will' with a browser-based version of OXT, would-be progrmmers with 'intermittent' internet should have no problem running the thing.
-

Ngorongoro.jpg (18.18 KiB) Viewed 3777 times

[tperry2x]

Not that that should preclude us doing the odd spot of reading from time to time:
https://livecode.com/release-9-6-12-stable/

The browser widget on Windows and Linux will no longer become unstable when used extensively

Good one.

The scrollbar will no longer cause a crash when the pageIncrement or lineIncrement property is set to a negative value

Does it? Not here. Or is that a MacOS / Windows thing?

does it.png (22.24 KiB) Viewed 3776 times

[tperry2x]

On my Polycarbonate iMac running MacOS 10.7.4 I use 2 browsers called SeaLion and InterWeb with which I can access about 98% of websites.

Try going to mega.nz or github on either of those browsers

[richmond62]

Try going to mega.nz or github on either of those browsers

What has that got to do with delivering a browser-based version of OXT?

Nothing.

I am just suggesting a bottom line for any browser-based version of OXT development.

[tperry2x]

What has that got to do with delivering a browser-based version of OXT?
Nothing.
I am just suggesting a bottom line for any browser-based version of OXT development.

Umm... did I miss something?

As SeaLion and InterWeb are both Open Source it might not be a bad thing to package any browser-based version of OXT with one of those web-browsers

From the SeaLion github page:

What is not included
Digital Rights Management (DRM) such as Encrypted Media Extensions (EME)
WebRTC
WebExtensions
Developer tools (some functionality can be added back via an extension)
Language Packs (English only)
MS Windows support

The glaringly obvious stuff is the DRM media, if we are going to play back various media formats.
WebRTC - How do we add video, voice and binary data write to a web app without it?
MS Windows support - Not cross-platform in any case, which is supposed to be the whole idea of a web implementation

I'm saying, as you mention above about including these browsers, that for those reasons - it may not be possible (or at least not something you'd want to do)

Why include a browser with a web implementation, as you may as well have a desktop app at that point?
Plus, why advocate either of them when they aren't as standards compliant as Edge, Chrome, Firefox or (recent) versions of Safari?