OpenXTalk Lite 0.92 Download Links...

[tperry2x]

Please see:
https://www.openxtalk.org/forum/viewtop ... 3797#p3797
(please bear in mind that this software should still be considered a "work-in-progress", although it's getting better slowly ).

[richmond62]

Aha: Saturday will never be the same.

[richmond62]

Bathed, perfumed, and suitably charged with coffee . . .

1. 7zip & .dmg & an installer seems a wee bit long-winded . . .

2. OK, after a bit of a 'churn' installed the thing in my Applications folder.

3. Spoilt, snotty Richmond wants to be able to choose where to install the thing.

[richmond62]

Some stuff from "the dark side" still lurking in the undergrowth:
-

Screen Shot 2023-10-07 at 12.30.11.png (181.08 KiB) Viewed 2438 times

-
You'll be wanting to shorten your MenuBar as I demonstrated quite some time ago.

And this mun be yaisefu, as we say in Scotland:
-

Screen Shot 2023-10-07 at 12.38.07.png (753.12 KiB) Viewed 2437 times

[richmond62]

Holy Cow! Spoilt for choice and, frankly, a pain in the bum.
-

Screen Shot 2023-10-07 at 12.41.48.jpg (676.64 KiB) Viewed 2436 times

-
I'm buggered if I know my "Pansy Pink" from my "Gay Purple".

THIS is lovely:
-

Screen Shot 2023-10-07 at 12.44.55.png (1.7 MiB) Viewed 2435 times

-
If you could rejig everything like that, in my opinion at least, the thing would be much better.

[tperry2x]

I'm a bit confused by what you are seeing.
The menu bar stack looks entirely wrong.
Should look like this screenshot
https://www.tsites.co.uk/sites/openxtal ... ot-mac.png

Did you assemble your version you are testing from downloading afresh, or by mixing and matching various changes?

Point taken about the list of colours, I probably went a bit overboard with that. So I'll shorten and refine the list. Do you have a shortlist of favourites?

[richmond62]

The menu bar stack looks entirely wrong.
Should look like this screenshot
https://www.tsites.co.uk/sites/openxtal ... ot-mac.png

Did you assemble your version you are testing from downloading afresh, or by mixing and matching various changes?

No: that is all your work with the exception that I EXPOSED a window bar on the 'menuBar' stack so I could both drag the thing around, & see WHAT the MenuBar had as its label.

Umm: possibly my hack to give the thing a drag-bar also re-lengthened the stack: my bad.

Whatever my sins: the MenuBar stack should be labelled something like 'OpenXTalk'.

[richmond62]

Point taken about the list of colours, I probably went a bit overboard with that. So I'll shorten and refine the list. Do you have a shortlist of favourites?

Probably best to have a list of about 7 fairly primary colours . . .

In a Universe not that far away:
-

Screen Shot 2023-10-07 at 14.35.27.png (443.43 KiB) Viewed 2415 times

-
I really could not see any obvious reason to change that.

In fact I cannot see any obvious reasons to change a lot of things, and, while I am on a "being nasty" roll, I much prefer the original (or the original greyscaled) icons in the Tool Bar palette to yours.
-

cANDc.png (222.96 KiB) Viewed 2415 times

-
Every Primary teacher's wet-dream: a Compare and Contrast exercise.

[richmond62]

In every other respect, as far as I have seen so far, your 0.92 version works superbly, and, just because I really cannot resist being nasty, I prefer it to Paul's version just because it is not over-burdened with things that Paul has bunged in there without consulting with anyone.

That should not be seen as a 'big dig' [well, it is a small dig] at Paul, because without him we still be hanging around street corners doing disgusting things to raise unearthly sums to buy 'the other product'.

[tperry2x]

Whatever my sins: the MenuBar stack should be labelled something like 'OpenXTalk'.

haha, don't worry - I'm not playing the blame-game, or looking to point the finger.
I was just puzzled why the differences in what I've observed here and what you are seeing.

menubar-inspector.png (65.76 KiB) Viewed 2410 times

As you can see, the menubar name is supposed to be set from reading in the "about.dat" file.

sets menubar name.png (27.01 KiB) Viewed 2410 times

However, Paul has picked up on the fact that there's already a way to set this as variables should already exist.

Exactly when these variables get populated, I'll need to test, but hopefully it's before the revmenubar stack is loaded so I don't have to load from the "About.dat" file. I'm wondering if it can't find the about.dat file, this might be why your menubar stack title has remained the same. (and I don't know why that would be the case)

The argument for using these variables that are already loaded, I am fully onboard with. There's no point loading the same thing twice as it just results in redundant code, or inconsistencies.
However, LC have hard-coded the name "Livecode" in, so I'd rather this be more dynamic, hence why I chose my method.

lc-hard-code-name.png (17.88 KiB) Viewed 2410 times

Using their method (screenshot above), they've hardcoded the "Livecode" part and only dynamically load the 'variant' of Livecode (commercial, community etc), then the version number.
This is where they pull the info together for their title.
Running "put revEnvironmentEditionProperty("name") & " " & the version" gives:

message-box.png (8.83 KiB) Viewed 2410 times

So "Community 9.6.3" isn't ideal either. I'd have to find where this is pulled from and set it there.

[tperry2x]

I much prefer the original (or the original greyscaled) icons in the Tool Bar palette to yours.

The greyscale icons, I personally hate / despise / loathe - but that's down to personal preference. I think it was yourself that mentioned you prefer coloured icons if possible and I could not agree more at the time. Perhaps I can set this as a preference to use coloured icons or greyscale ones.

I'm receptive to ideas of course, so I think it would be fairly simple just to have a mono and coloured folder option for representing the tool icons. I was going to have another go at the mac versions anyway as they look far better in dark mode than light mode, but ideally they should work for both. That is just a matter of me redoing those with this in mind.

The tool icons you show are button controls circa Mac OS 10.6 I believe. They are using old interface styles, not representing ones from recent MacOS versions. I can't say much about this, as mine aren't much better, but I do want to sit and make better versions of these when I've got [several hours?] free.
Once they are okay'd, I can then go through making greyscale ones. (Shame there's no ink mode in OXT to change the saturation of a graphic?).
Please correct me if I'm wrong - I'd be gladly using that instead to toggle between coloured and greyscale tool icons!

[richmond62]

OK:

I like the coloured icons in the MenuBar stack.

I like greyscale ones in the Tools.

People are contradictory buggers who are rarely consistent.

[tperry2x]

That should not be seen as a 'big dig'

Same here. I'm not looking to have a dig at anyone in any way. As I say, I'm open to suggestions and all feedback is welcome (both positive) and what I could perceive as being a 'pain-in-the..' to fix, but I'm keen to not just stick stuff in there that only appeals to me. It has to work for everyone.

Which is the great thing about making things a toggled preference. If any changes I make (interface look/feel) can be toggled via a preference, then I'll go that route.

I don't necessarily want to inflict my design choices on other people.

That brings me back to the revmenubar stack.
I'd hidden the close/minimise/maximise buttons to save screen space. The negative being that you then can't drag it around. So, what I'd wondered is a compromise:

tool-idea.png (124.68 KiB) Viewed 2394 times

This way, you still save screen space vertically (window title bars can add a surprising amount of wasted space on some operating systems, - depending on what visual theme & style is chosen). This way it's also still moveable. I'd ideally like the position (instead of being hard-coded to topleft, to be remembered in the preferences - which I can set).
This is saved upon quitting OXT, then restored upon opening OXT.

[tperry2x]

...because without [Paul] we'd still be hanging around street corners doing disgusting things to raise unearthly sums to buy 'the other product'.

Haha, I'm not sure I would have ever resulted to those methods to raise some cash.
I'd probably have to pay them, not the other way around

[OpenXTalkPaul]

Running "put revEnvironmentEditionProperty("name") & " " & the version" gives:

So "Community 9.6.3" isn't ideal either. I'd have to find where this is pulled from and set it there.

In OXT DPE I changed this section to simply be:

Code: Select all

--- put "LiveCode" && revEnvironmentEditionProperty("name") into tTitle
   put "OpenXTalk" into tTitle 
   

and then commented out the if/then stuff that followed.
As you've said revEnvironmentEditionProperty("name") yields 'community' which there's no point in including in its current form, since for us there is only a 'community' edition.
I suppose you make this stored in an external file and load the name from there, but that seems like unnecessary disk file read operation to me.

revAppVersion() or 'put the version' = 9.6.3, the Engine Release version number
Not much point to listing "9.6.3" in OXT, but elsewhere I called my version "0.963.1"

put the buildNumber = more precise Engine build number
put the environment = development (for IDE engine)
Not used here but just a reminder that : put the systemVersion, may not return correct info, on Mac BigSur+ it returns 10.16) in OXT. In macOS Native Tools there is a replacement: macOSversion() that is accurate (returns 11.x on BigSur).

[tperry2x]

put the buildNumber = more precise Engine build number
put the environment = development (for IDE engine)

That certainly looks interesting. I'll likely use one/all or a combination of that instead.

Not used here but just a reminder that : put the systemVersion, may not return correct info, on Mac BigSur+ it returns 10.16) in OXT. In macOS Native Tools there is a replacement: macOSversion() that is accurate (returns 11.x on BigSur).

Sorry, I'm being incredibly dense - whereabouts would I find that?

[tperry2x]

I suppose you make this stored in an external file and load the name from there, but that seems like unnecessary disk file read operation to me.

True, although it could be argued that the about file is being read anyway to populate the text in the about stack, so that is when it sets this variable. So, no additional disk-read and it takes less than 500 milliseconds. (in fact, there were additional & unnecessary waits in the home stack which I've removed, so it more than compensates for this).

[richmond62]

(funny, because this is already a reduced set from what is available)

Jeepers-Creepers!

You could, of course [what a weasel phrase] give us something like this:
-

Screen Shot 2023-10-07 at 20.20.28.png (273.1 KiB) Viewed 2352 times

[tperry2x]

Hmm, looks a bit too "kids-colouring-box" and is a bit patronising perhaps.
I mean (when you eventually get to it), choosing Other at the bottom brings up a system colour selector anyway.

[richmond62]

Sorry, old fruit, but as I live, breath, and move among Primary Children [permanently infantilised ], and as Apple seem fine with that sort of thing {That's probably Craig-with-the-perm's coloring box), I can see nothing obviously wrong with that (the colouring box, not Craig's revoltingly campy hairstyle ):
-

HoHoHo.png (715.64 KiB) Viewed 2329 times

-