What should OpenXTalk Lite 1.0 be like?

[micmac]

So this is my opinion


OpenxTalk Lite 1.0 should be an exact copy of 9.6.3 — with the branding taken out!

No alteration other than that.

Then after that there can be a 1.0.1 and 1.1.0 with all kinds of extras.

So if this opinion is taken to be true, then we must start the hunt for Livecode branding in all corners and finish that first.

Im sure that was why Terry started over of Pauls work (which diverted to much)

Opinion
Mic

[richmond62]

Oddly enough, my opinion coincides almost 100% with yours.

I would even argue that by changing the Tool bar icons and implementing dark mode that has already gone to far.

I will be working on a patcher containing 4 or 5 Tool Bar icon sets so people can have what they want.

[tperry2x]

I will be working on a patcher containing 4 or 5 Tool Bar icon sets so people can have what they want.

Better to not have a 'patcher', rather a preference so people can just choose from available toolset themes.
This is because on Linux, you'll need sudo / admin permissions if you start transposing files, and on MacOS and windows: for standard unprivileged users (guests / students), they won't have access to move files around.

If they had a series of options in the preferences where they could simply toggle between what they want, this may be better.

[richmond62]

The problem that if an IDE contains lots of icon sets for the Tools and the Menubar stacks will be one of bloat.

[tperry2x]

Perhaps just an option to select "new-mono" and "legacy-coloured" icons in that case.

[tperry2x]

I'd concur, as the original goal was to remove all branding.
The biggest location you'll find that branding is currently the resource stacks, and user guide.

I would even argue that by changing the Tool bar icons and implementing dark mode that has already gone to far.

Possibly, although I've not implemented dark mode in OXT Lite. "It just works" in Linux. Not so much in mac and Windows. All I've added colour-scheme-wise I guess is syntax colouring on the script editor, so as not to hurt my eyes when staring at script.

The "prettifying" stage can always come later. The biggest, most obvious thing where you can find Livecode now is in all the help material, so it's a case of wading through those stacks.

You could equally argue that all the handholding interface side of things can go on the back burner too, as it's not relevant until we've scrubbed OXT clean of all Livecode references as far as what a user will encounter (they may only see some legacy LC / Runrev / Metacard references if they start to dissect the code).

[richmond62]

(they may only see some legacy LC / Runrev / Metacard references if they start to dissect the code)

There has to be a statute of limitations on how much we have to remove: after all LiveCode haven't exactly fallen over themselves to remove MetaCard and HyperCard references.

Also, I would assume, somewhere in either the licencing or another notice it has to be made clear that OXT is derived from and built on . . .

[tperry2x]

I would even argue that by changing the Tool bar icons and implementing dark mode that has already gone to far.

I've been thinking this over since earlier.
Paul mentions that it might just be a case of adding a craftily written extension, not a complete rewrite (viewtopic.php?p=4175#p4175), so I'm all for that if that's the case.

As I mention, I believe this to be 'a given' prerequisite these days that any program should be able to follow the underlying OS appearance.

[FourthWorld]

(they may only see some legacy LC / Runrev / Metacard references if they start to dissect the code)

There has to be a statute of limitations on how much we have to remove: after all LiveCode haven't exactly fallen over themselves to remove MetaCard and HyperCard references.

IIRC the MetaCard trademark has expired due to nonrenewal.

I don't know if Apple still maintains the HyperCard trademark, but I believe both marks are used in very limited ways in LC/OXT, in contexts where it would be difficult for the reader to construe claim of ownership or other misleading use.

You'll often see companies refer to other companies, and where the mark is used you'll see a disclaimer at the bottom noting who owns the mark.

Also, I would assume, somewhere in either the licencing or another notice it has to be made clear that OXT is derived from and built on . . .

The original GPL license from LC would seem necessary for all works derived from it.

Really, read the license. So many of the questions raised here are addressed there.

[OpenXTalkPaul]

Im sure that was why Terry started over of Pauls work (which diverted too* much)

I know some of you guys think that I diverted too much, but I felt I needed to go through the entire IDE, to really see what's what and where I could do things differently . But the OXT DPE IDE is like 99% debranded, including the dictionary (which was the first thing we edited, along with Seth Morrow who set up and hosts this site). I think we've found and removed every possible brand reference that was in the IDE, and there was A LOT of them, and now we need to move on to engine editing/recompiling for that last 1%.

With the exception of 'darkMode' support (which admittedly turned out to be a bit more involved then I originally thought) I didn't actually spend all that much time on the extras bits, most of them were preexisting projects. Like the Dev Guides feature for example was already written by the Ferrus Logic guys, mostly a drop-in addition. There's some things I've played around with seperate from working on OXT IDE, but those are either things I had just a little bit of time to work on something (and usually while away from my normal dev-setup computer) and/or it's what keeps me interested (otherwise I'd might get bored and walk away). If you wanted a mostly-debranded-only version of OXT DPE, that would be really easy to do, mostly just remove a few extension folders and take out a few minor revMenuBar/revPreferencesUI edits.

Anyway, I'm sure Terry and Tom or whomever else re-starting the same from the beginning will find out what's up with that (I think they already are). But I've also come to think that it's really good to have their alternative take on the project, I've already added a few OXT Lite changes to OXT DPE.

I agree with Tom that, at this point, there's an expectation of darkMode support in apps, at least on macOS. I personally always use the dark UI on Mac and Linux because it's easier on my eyes (and I have this theory that it probably uses slightly less electricity).

[richmond62]

LibreOffice doesn't go 'dark' on my 2 main Macs, and I haven't seen anyone grousing about that in their feedback section.

I wonder if anyone has any reliable statistics re uptake of dark mode?

In Ethiopia many, many pedestrians are killed on the road because lorry drivers turn their headlights off, because they believe (wrongly) that doing that will save fuel.

Yes, probably dark mode consumes less electricity, but probably not a lot less. Personally I prefer dark mode (and have had it ever since MacOS 10.15 when it became possible) just because 5-6 hours in front of a bright screen gave me headaches.

[micmac]

If you wanted a mostly-debranded-only version of OXT DPE, that would be really easy to do, mostly just remove a few extension folders and take out a few minor revMenuBar/revPreferencesUI edits.

Would you be willing to do that for us, Paul?
Then we could test that out and see if that should be the basis of a 1.0.0


Mic

[richmond62]

I, again, am seconding that.

First repaint the house, then build gazebos on the roof, and not the other way round.

My fairly feeble 'rmCode' was an attempt to stimulate exactly this.

[tperry2x]

LibreOffice doesn't go 'dark' on my 2 main Macs, and I haven't seen anyone grousing about that in their feedback section.

I use it all the time in dark mode, but perhaps that's just me

Screenshot at 2023-10-25 17-10-59.png (98.17 KiB) Viewed 484 times

[richmond62]

Sorry: mixed LibreOffice up with ApacheOpenOffice:
-

Screenshot 2023-10-25 at 19.42.47.png (407.89 KiB) Viewed 480 times

-
It is a bit like LC: 'The one that got left behind.'

[micmac]

In LibreOffice it looks like that all icons keep their looks.

Only fields and backgrounds change.

Maybe this is an idea for OpenXTalk

Mic

[richmond62]

I don't see why the icons should change.

Years ago there was a thing which allowed on to colourise MacOS 7.6: It didn't muck around with the icons at all. But it did allow one to turn window edges, menu bars and so forth any colour you wanted: my LC 475 had everything dark green.

[OpenXTalkPaul]

LibreOffice doesn't go 'dark' on my 2 main Macs, and I haven't seen anyone grousing about that in their feedback section.

Update your LibreOffice install.
https://9to5linux.com/libreoffice-7-5-1 ... an-90-bugs

Yes, probably dark mode consumes less electricity, but probably not a lot less. Personally I prefer dark mode (and have had it ever since MacOS 10.15 when it became possible) just because 5-6 hours in front of a bright screen gave me headaches.

I think it was macOS 10.14 Mohave that brought full darkMode.
If it makes my laptop battery stay on a few minutes longer, then that alone is worth it to me, but It's mostly that I find it easier on my eyes. LC CE was like ultra-bright-white mode, really bothered me, I'd preferred at least some 'off white' or the old macOS 'brushed metal' look (the 'set stack to metal' syntax does nothing on newer macOS versions).

[OpenXTalkPaul]

I don't see why the icons should change.

Years ago there was a thing which allowed on to colourise MacOS 7.6: It didn't muck around with the icons at all. But it did allow one to turn window edges, menu bars and so forth any colour you wanted: my LC 475 had everything dark green.

IIRC those classic macOS Appearance Manager themes (and the 3rd party Kaleidoscope themer) did actually allow for custom icon sets, and UI sound sets too.
Of course back then there was Resedit which made it easy to change icons (and mangle all sorts of other UI elements everywhere in the system files and most apps).

I don't care too much about the IDE's icons, just want them to be quickly recognizable and look just as good in dark or light modes. I've been thinking that means line-art (1-bit) icons or vector SVG based that would auto-toggle foreColor black or white, but lately I think going back to full variable color icons would work as well (but not be higher resolution / scalable, unless color-SVG was used, which could be doable)

But since all art is subjective, I think it would be fine idea to give users a choice of a few icon sets and make it easy to make their own custom icon sets.

I'm going to take some time, maybe tonight, to go through the IDE and make a list of IDE UI attributes, like the 'system' Fonts, that are currently 'hard-coded' in the IDE scripts, then later can use this list to change them to IDE properties ('the cIDEThemeBaseFont' or something like that) which a theming library would them manage.

I'm really not interested in devolving OXT DPE back into LC CE with some text/icon changes. I mean I've also various things along the way, and some things needed quite a bit more (and still do) work to make them relevant to OXT. These packages I've made really were for me to use as well as anyone else who wants to try them...

BUT, since I like you'ze guys, I guess I could try to spend a little time building OXT Lameo Edition ( ) and put it up somewhere.

[OpenXTalkPaul]

Looking at these closer the color icons have lighter edges and/or slight gradations, something like these would be fine (some of these look like those commonly found Linux SVG icons set(s) which we can use), and for HiDPI mode ("Retina"+), we could have a high-dpi icon names in each set (or just make high-ppi a separate set).

Screenshot 2023-10-25 at 8.31.45 PM.png (155.05 KiB) Viewed 459 times

Screenshot 2023-10-25 at 8.30.38 PM.png (137.21 KiB) Viewed 459 times