OXT Lite Moving Forward

[tperry2x]

I've decided to completely remove all attempts at theming, as this is not only slowing down OXT lite, but also producing weird behaviours (and it's inconsistent across OS versions).
https://www.openxtalk.org/forum/viewtopic.php?f=9&t=594

These changes strip everything theming-wise out, and reset all custom colour properties that might have been previously set.

The appearance needs fixing in the engine on MacOS and Windows, rather than me trying to bodge it into submission.
Linux behaves correctly, but if anyone wants to strip these changes out of their linux build too, it doesn't hurt (makes no difference), but just keeps the code cleaner.

[richmond62]

I would adopt another approach, and the first thing I would do is STOP being hypnotised by LC's claim that the IDE is COMPLETELY cross-platform, because, face facts, it just is NOT.

Therefore any attempt at theming has to be addressed on a per-platform basis.

[And, ultimately, until someone 'bakes' some new standalone engines, any theming is likely ONLY to effect the IDE while it is being used for programming: which could be potentially a bit misleading if end-users expect their standalones to look like what they see in the programming environment.]

Having just read this:

I don't think there are more "templates" buried in the IDE, the tool palette does this "on the fly"
by setting all these props for the templateXXX before the actual control is created.

Maybe you could create a library (or front or backscript), but be aware that you need to create e.g.
a button only via the message box or script, since the tools palette will always overwrite your settings.

posted 'elsewhere', I have "come over all queer" re theming, and will be off to knock out a few table legs for a small laptop desk I am in the process of bodging, and with any luck, being away from any computer my brain my de-addle itself a bit and work out a way to sort things out: possibly by hacking into the Tools palette so the button and field templates there are 'compromised' to work with a theme.

[richmond62]

Poking around in the stackScript of the Tools palette I have found these:

templategraphic

templateGroup

#Reset the templates we are going to use

templatebutton

templateimage

BUT no 'templateField'

So, it should NOT be beyond us to inject something into that stackScript re buttons at least.

AND, while there is no mention of a 'templateField' there, there may be elsewhere.

Considering LC Community is/was open source, the people 'up north' were bloody bad about documentation.

[richmond62]

And, thanks to the good offices of Bernd Niggemann there ain't no sh*t any more and ALL the object definitions have been located:
-

Screenshot 2023-11-08 at 14.50.27.png (408.16 KiB) Viewed 1928 times

-

Screenshot 2023-11-08 at 14.56.19.png (198.23 KiB) Viewed 1927 times

-

Screenshot 2023-11-08 at 14.58.19.png (349.66 KiB) Viewed 1926 times

[FourthWorld]

I would adopt another approach, and the first thing I would do is STOP being hypnotised by LC's claim that the IDE is COMPLETELY cross-platform, because, face facts, it just is NOT.

This depends on how one defines consistency, within the app across platforms or within the platform across apps.

The engine handles control rendering to favor the latter, which is more commonly what's desired.

More on this here:
http://lists.runrev.com/pipermail/use-l ... 71254.html

Most of that boils down to one question:

Which number is larger:

(A) Number of hours a given user will use one app across multiple operating systems.

(B) Number of hours a given user will use multiple apps on a single operating system.

[richmond62]

I would expect that the vast majority of users would fit into category B.

[richmond62]

Bernd has already proven that 'mucking about' with the Tab Delimited Text files here:

/Contents/Tools/Toolset/resources/supporting_files/property_definitions/

https://forums.livecode.com/viewtopic.p ... 7&start=15

CAN:
-

Screenshot 2023-11-08 at 20.43.41.png (97.2 KiB) Viewed 1915 times

-

Screenshot 2023-11-08 at 20.46.52.png (26.67 KiB) Viewed 1914 times

[richmond62]

The ONLY slight shag will be to work out how to load each TSV file into a table field (???), alter a cell, and then re-export the TVV to over-write the original one.

Oh . . . and, do we REALLY want to over-write the original one: that might be "storing up treasure in heaven" to cause all sorts of problems if we want to revert to default settings.

[FourthWorld]

I would expect that the vast majority of users would fit into category B.

Which is the use case the engine is designed to support.

[tperry2x]

I would expect that the vast majority of users would fit into category B.

Which is the use case the engine is designed to support.

Not so when all other apps draw the UI consistently, (assuming scenario b where you'd be spending time also using these), whereas Livecode / OXT can't render the appearance of UI elements correctly - thereby creating a noticeable disparity.

[tperry2x]

Bernd has already proven that 'mucking about' with the Tab Delimited Text files...

Changing the properties in these tsv files is akin to just setting the same thing in the inspector. These are just the properties that are set as default on the new object types. It does not change the actual base appearance of an object that cannot normally be tweaked through the inspector.

For example, you won't be able to change a popupmenu button object from what's shown on the right to what's shown on the left by tweaking the properties of the tsv file.

control.png (9.75 KiB) Viewed 1906 times

On the right is what Livecode / OXT incorrectly renders the control as in dark mode (because it's not natively dark-mode aware, as the engine hasn't been coded with that in mind).
On the left is the native control, as it's supposed to appear - screenshot from Apple's System Preferences.
Of course, this changes by MacOS version - much the same as in Windows it changes between Windows XP, 7 and 10.
Another way to test that these controls aren't being drawn natively is to theme your Windows XP / 7 using a custom appearance theme with custom buttons. The buttons in LC/OXT remain blissfully unaware.

[FourthWorld]

I would expect that the vast majority of users would fit into category B.

Which is the use case the engine is designed to support.

Not so when all other apps draw the UI consistently, (assuming scenario b where you'd be spending time also using these), whereas Livecode / OXT can't render the appearance of UI elements correctly - thereby creating a noticeable disparity.

The C++ engine maintained by C++ engineers does a pretty good job of keeping as current as practical with OS appearance changes. There's probably room for further refinement, but dark mode is there, and after considerable work in v9 most of the control label anomalies were addressed.

[tperry2x]

Added the feature I was talking about earlier in the week.
https://tsites.co.uk/otherstuff/snippets.mp4

This adds the option for script-presets (snippets) to be placed on newly created objects.
You can toggle this option on or off in the preferences.

To apply this change, please use the files attached and add them to your build.

tool-snippets.7z

(134.77 KiB) Downloaded 70 times

[richmond62]

Changing the properties in these tsv files is akin to just setting the same thing in the inspector.

I am well aware of that.

Think of the following situation:

Chummy wants to build an app that has 500 buttons that conform to a common standard, Chummy's standard, not the one imposed by the IDE.

Chummy, during the software development cycle(2) will quit and restart the IDE any number of times.

So:

1. Chummy does NOT want to make each button individually the way s/he wants it.

2. Chummy does not want transient preferences that do not 'stick' between sessions with the IDE.

Wouldn't it be "rather jolly" if Chummy could make up a single button to their requirements, and at the click of a button have the settings for that style of button 'automagically' saved in the IDE so that, until Chummy decides s/he wants to change the settings, the IDE will keep producing buttons with the same settings as the 'master' button?

Obviously, the same could be true for fields, graphics, and so on.

To effect this a script somewhere (probably in a preferences substack called something like "set up your button design") would have to read the properties of the end-user's button template and write them to the relevant .tsv file.

By way of example, imagine having to set up only 20 buttons in this style:
-

SShot 2023-11-09 at 13.12.14.png (13.3 KiB) Viewed 1886 times

[tperry2x]

I'm talking about the creation of standard interface buttons.
Things that look like they should be part of the OS.

I think I'm speaking about the exact inverse of what you mean.
User-created buttons (custom styles like your picture shown), should be the exception, not the norm. So if a user wants to create loads that look l ike that, that's down to them.

(Photoshop macro for button creation for example) - but that's down to whatever interface choice they make.

If a user wants a standard-looking button set that looks like it mirrors the OS scheme, then the IDE should be providing that 'somehow' by means fair or foul.

[tperry2x]

The C++ engine maintained by C++ engineers does a pretty good job of keeping as current as practical with OS appearance changes. There's probably room for further refinement, but dark mode is there, and after considerable work in v9 most of the control label anomalies were addressed.

But not all of them, obviously.

[FourthWorld]

The C++ engine maintained by C++ engineers does a pretty good job of keeping as current as practical with OS appearance changes. There's probably room for further refinement, but dark mode is there, and after considerable work in v9 most of the control label anomalies were addressed.

But not all of them, obviously.

Are you referring to the OXT engine last updated years ago, or the latest LC engine?

[FourthWorld]

@Paul: may we please turn off the spam blocking thing requiring us to post twice?

[tperry2x]

Are you referring to the OXT engine last updated years ago, or the latest LC engine?

Well, obviously the one we have access to. The community build. As far as I'm concerned, what LC does from this point onward is neither here nor there and is irrelevant to me.

[richmond62]

I think I'm speaking about the exact inverse of what you mean.

Yup!

AND, I have no objection to what you want to do at all.

But why not have a facility inwith the IDE where end-users can, should they choose, play as "silly buggers" as they like with buttons, fields, and so on.

I am all in favour of offerng the end-user the maximum customisability possible.

Somewhere 'down the line', if LC wake up and smell, not the coffee, but how to keep their heads above water (i.e. produce a cut-price, crippled version of LC), OXT or WTF it is then called (that's an idea, why not call it 'WTF'?) will find itself up against LC (after all, there is not much satisfaction in doing all sorts of clever stuff with the IDE if, ultimately, no one cares or is interested), and the way for OXT/WTF to shine will not just be the fact that it is 'Free', but the fact that it offers buckets more customisability (saving hours of developers cosmetic work) than LC.