OXT Lite Moving Forward

[tperry2x]

...that's an idea, why not call it 'WTF'?

Haha, this tickled me. I like that suggestion. Wish I'd thought of that name.
I have my own fork of this (purely to satisfy an audience of one: me). I called it AXT (as in 'Another XTalk') - Doesn't really matter what the **** it's called really at this stage does it.

[richmond62]

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

Surely the thing is that 'over here' we should confine our programming discussions to anything we can do with code from the open source versions of LiveCode [last known version 9.6.3].

HOWEVER, what might be useful is discussing any NEW features we see in subsequent (i.e. non-Open Source) versions of LiveCOde and whether we think it night be a good thing to try and implement them in OXT going forward: and, quite obviously, that does NOT mean pinching code from LC 11.5 or whatever, but writing our own code to produce the same result.

Of course, 'naughty Richmond' very much doubts there will ever be an LC version 11.5 . . .

So, we CAN go on kibitzing anent LC's business "techniques" if we wish, as, to a certain extent, they may affect take-up of OXT.

[richmond62]

Haha, this tickled me.

A bit of 'tickling' is not a bad thing, as an awful lot of people hereabouts (and even more thereabouts, on the 'other side') seem remarkably humourless.

Or, as my wonderful History teacher used to sat circa 1976, "OK, boys, just remember that in 90 years we'll all be dead."

[TerryL]

I strongly urge re-thinking the draggable MenuBar and removing the program name/decorations from the program window. This is a drastic break from standard interface design. Users expect these things and I greatly worry the experiment will burn OpenXTalk Lite. This should not even be a preference option. I realize much effort was put into it. It's still wrong. Please return revMenuBar to what it was before, update the public release Lite .93 downloads, and turn focus to the excellent bug list posted. Those are the things that really need attention. Terry

Suggestions
o Test ask password on Mac & Linux to verify bullets "•" appear while typing/pasting input. Windows is ok.
o Preferences. The new Dictionary card might be renamed "Extra" providing room for extra preferences, like black/color toolbar.

More Bugs To Consider For List
All Platforms:
o SQLite library could be updated.
o Geometry Manager causes wild unexpected resizing. LC bug 23122. This longstanding problem has been solved by Brian Milby, but the fix has never been applied by LC. The workaround is: after adjusting the GM for all controls/groups, then adding new controls/groups or changing layout, in msg box: revCacheGeometry true. I'll contact Brian to see if he might assist us.

o Answer/Ask dialogs in Windows (Linux?) has a flash of "Answer Dialog" or "Ask Dialog" in the title area. I don't think it's a problem in Mac. This bug has been fixed in LC 9.6.7.

o Ask Password. This seems to have encrypted the user response in the past, but was changed to be the same as ask password clear (at least in win10). The dictionary does mention this, but could be clearer that there is no difference between the two forms. There is also an example using mcEncrypt which should be removed, as it is no longer usable. Most people would assume that ask password would encrypt too, so is there a way to do that, with dictionary example?

[FourthWorld]

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.

Thank you for the clarification. It wasn't obvious to me for the very reason you cited: we all know LC continues development on the engine, and after nixing the FOSS edition began adding support for dark mode. With no similar work having become affordable for this FOSS engine, I would not expect it to have had similar enhancement.

[FourthWorld]

I strongly urge re-thinking the draggable MenuBar and removing the program name/decorations from the program window. This is a drastic break from standard interface design. Users expect these things and I greatly worry the experiment will burn OpenXTalk Lite. This should not even be a preference option. I realize much effort was put into it. It's still wrong. Please return revMenuBar to what it was before...

When did revMenubar ever conform to common IDE conventions?

Most IDEs have a single window, but that only works in environments where you're not actually making software, but merely draw drawing pictures of software that is later run in a separate environment.

If we embrace multiple windows as perhaps uncommon but very useful for this engine's uncommonly productive way of working, that top palette poses a design challenge I've never found an easy answer for.

If we position that top palette so that it can't be moved on macOS (Win and Linux have no reason to hide that drag bar and many reasons to preserve it), what happens when it simply needs to be moved, such as when a user window submarines beneath it?

And where we do we toolbars on Mac they tend to span the full width - should we take that much space from the app designer?

At the heart of this is a philosophical question: are we drawing pictures of apps inside of a layout app, or are we inside of our app with tools available for further enhancement of the app as it's running?

This has implications beyond the toolbar. For example, macOS has only one menu bar visible at a time. Which one do we hide, the IDE's or the one we're working on?

Short term, I favor your proposal because it's easy and good enough.

But long term I think there's an opportunity to more fully embrace the "live" quality of making apps with tools available inside them.

This is the opposite of what LC Ltd in embarking on, attempting to limit the IDE to a drawing app and making it far more difficult to see how your app behaves while you're working on it, at least for desktop apps (this engine's only truly great strength).

I believe the uncommon productivity this engine delivers is best exploited in an IDE that embraces the uncommon workflow it supports.

Perhaps we can explore this in more detail down the road. This long-winded reply is just to say that I can understand why the title bar was made usable, and can understand the benefits of hiding it on macOS for now.

[FourthWorld]

Am I the only one who finds the requirement to post twice to have a single post take off-putting?

Will newcomers here think this is great?

[richmond62]

Plus all the fooling around to insert attachments.

This does need sorting out.

I realise this stuff has been done in an attempt to lessen spamming attacks, but it is a right, royal pain in the bum as well.

'Over there' Ican assemble a message with 2 embedded images and an attached ZIP file all in one go, instead of repeatedly submitting each stage twice: it probably takes about 25% of the time to send a message over here. And, unless one already knows, the system looks bust.

[richmond62]

A draggable menuBar . . .

Well, ever since I started using Runtime Revolution (about 2001 as far as I can work out) I have tweaked the Menu bar on MacOS so it can be moved around.

At one point I made a whole system to make the menus vertical, and all sorts of other 'nonsense'.

As I generally work with computers that have at least 2 monitors connected (and have done since 2003) I often 'park' the menu bar 'off' on one of my side monitors as I almost never use the thing, or I minimise it to the Dock.
-

Screenshot 2023-11-10 at 9.27.34.png (123.09 KiB) Viewed 2000 times

-

Screenshot 2023-11-10 at 9.27.58.png (41.86 KiB) Viewed 1999 times

-
Now I am sure Thy way of working is not My way of working, and that's a good thing as I cannot abide conformity: so to enforce conformity (as LC DOES on macOS unless the end-user hacks things) should, as far as I am concerned, be discouraged.

In the IDE there IS a preferences stack, and there is no earthly reason why the preferences on offer in that stack cannot be greatly expanded.

This is a drastic break from standard interface design. Users expect these things and I greatly worry the experiment will burn OpenXTalk Lite.

Nothing much is getting 'burnt' right now for 2 simple reasons:

1. There are probably about 5 people world wide messing around with variants of OXT.

2. As OXT is FREE and Open Source it is exactly like my Devawriter Pro: I keep churning new versions of the damn thing out: what the uptake is, if any, I just don't know (and, oddly enough, I don't care that much as my motives lie elsewhere).

standard interface design

Perhaps you'd like to tell that to the Haiku lot, or Apple (who have broken their own HUG several times - and their HUG was imposed unilaterally only as part of their hunt for market share, not because they give a flying "fffff" about Thee and me), or anyone else for that matter.

Personally I do believe Ease-Of-Use should be King, not conforming to someone's cooked up standard.
-

Drag bar.jpg (270.49 KiB) Viewed 1998 times

-
That one may end up in the 'dock' for something unmentionable.

[tperry2x]

To all of the above, I'll just make it a preference in the IDE. Plain and simple.
(then nobody has to get themselves in a twist over anything).

[richmond62]

That's marvellous!

Otherwise the argument could DRAG on for ages.

[tperry2x]

Otherwise the argument could DRAG on for ages.

Waaa, waaa, waaaaa.................. Very good.

All done, just to keep people happy. (For future reference, it's really not worth getting stressed about - just ask me!)

tweaked.png (71.83 KiB) Viewed 1991 times

Changes are in the usual place, on my site (https://www.tsites.co.uk/sites/openxtalk/changes).
If you don't want to download the entire list of changes, I attach just this change for you as well.

2023-11-10-1300.7z

(212.56 KiB) Downloaded 76 times

[richmond62]

it's really not worth getting stressed about

I know, I know, I laddered my tights.
-

SShot 2023-11-10 at 15.18.52.png (7.46 KiB) Viewed 1984 times

-
Although I still favour the 'standard' Mac window bar at the top.

[tperry2x]

I've added something else to OpenXTalk this evening.
It's only a little something.

Because OXT doesn't always detect the systemversion properly (particularly on MacOS "Big Sur" and upwards), I've added in this property (which you can inspect via the message box):

tSystemVersionNumber.png (18.95 KiB) Viewed 1764 times

It's based on Paul's MacOS systemversion fix, but expands upon it to correctly detect the systemversion more accurately on pretty much any linux distro and also in Windows.

You can refer to it by using:

Code: Select all

put tSystemVersionNumber

In the screenshot above, it returns 12 because I'm on a Debian 12 system.
Please can someone test on "Big Sur" and "Sonoma".

edit: I've also just added the tSystemVersion option:

Screenshot at 2023-11-21 12-32-15.png (10.62 KiB) Viewed 1720 times

(which essentially combines the platform and the updated version-getting-command together) - links updated too.

That change is here, if you don't want to download the larger changes file:
just this change:

System-Version-Number.7z

(35.63 KiB) Downloaded 70 times

or, all the changes: https://www.tsites.co.uk/sites/openxtalk/oxt-changes.7z
(if you download all the changes, please also make sure you have my latest changes stack too)
https://www.tsites.co.uk/sites/openxtal ... s.livecode

Why?
Because I'm trialling a github-esque changes-tracking thing:

changes.png (93.59 KiB) Viewed 1764 times

The thing in yellow would be what to look for in the file you are changing.
The thing in red would be what you are pasting over.
The bit in green is the new bit you'd be pasting in.

Yes, I've been a bit busy this evening as I felt bad for my "outburst" and potentially rash decision of exiting this forum. I don't want to as I do enjoy contributing to this project. As I say, I have my faults, and have never really been good at "social skills", although I've never been good at criticism.

A long walk with the dog will do wonders sometimes.

I aim to release 0.94 of OpenXTalk lite soon, with these up-to-date changes all applied.

[richmond62]

I have my faults

Sorry to disappoint you, but you are not alone in that!
-

SShot 2023-11-21 at 12.08.23.png (51.26 KiB) Viewed 1746 times

-
Ooooh: Look at that!
-

SShot 2023-11-21 at 12.14.02.png (38.93 KiB) Viewed 1745 times

-
De rigeur bitchy comment follows:

Default is useless in Darkmode:
-

SShot 2023-11-21 at 12.15.27.png (10.83 KiB) Viewed 1745 times

[richmond62]

"Revolution Classic" sorts thing out:
-

SShot 2023-11-21 at 12.15.56.png (11.27 KiB) Viewed 1743 times

-
LC 963 still propagates bollocks:
-

SShot 2023-11-21 at 12.20.40.png (53.79 KiB) Viewed 1740 times

-
Damn good show, that man!
-
Mind You . . . . . . Mind You:
-

SShot 2023-11-21 at 13.32.33.png (48.65 KiB) Viewed 1732 times

-
It would be very 'sexy' if on put systemVersion it initiated your new thing.

[tperry2x]

It would be very 'sexy' if on put systemVersion it initiated your new thing.

That would be really good, but I'm puzzled how to replace that old function with my new one. I don't know where it calls it from. It may possibly be from the engine?

[richmond62]

Here's something very "chewy" which would be super if it could be combined into one command:
-

SShot 2023-11-21 at 14.06.06.png (17.33 KiB) Viewed 1729 times

-

SShot 2023-11-21 at 14.07.50.png (17.36 KiB) Viewed 1727 times

[tperry2x]

Oh, okay - no problem.
Leave that with me.

[tperry2x]

Done. See above, but I'll put it here too:
https://www.openxtalk.org/forum/downloa ... hp?id=1668

Screenshot at 2023-11-21 12-32-15.png (10.62 KiB) Viewed 1720 times