Could there be a parallel effort on the Community Edition...

[SethMorrow]

This explained, I understand that we have quite different opinions & goals, and that I don't really suit in here. So my best wishes for your project, may it (and you!) live long & prosper!

hey axwald, don't go. This nascent community needs as many opinions and thoughts as it can get, even if they don't always align. There's so far only a few people actively participating, we'll see whether or not this leads to anything. It will be a long road. I am definitely going to use as much of my limited spare time as I can trying to help.

I don't know what I think about this "serious coder" business, but I DO know that I am not a C++ programmer, and so we will NEED some of them. I also know that I have no idea how to attract them. I'd assume if there were any pro C++ coders out there who cared about xTalk, that they would already be familiar with LC and would have been contributing to the community edition already.

Right now, this project (in my opinion anyway) is still very much in the brainstorming phase, and as such there are no bad ideas.

EDIT: and for the record, I don't think a fork of 6.x is a bad idea at all, whether or not LC, ltd were to agree or not. I think for most educators and hobbyists out there, it would have all the features they needed without all the widgets and bugs.

best-spock-leonard-nimoy-star-trek-episodes.jpg (51.62 KiB) Viewed 16004 times

[richmond62]

Erm, "Axel Zwingenberger", who on earth is 'Richard'?

And my son's music are not "random" youtube clips: far from it.

I don't have time nor indulgence to burn my hours on facebook.

And I don't have time or indulgence to be snotty . . . and as I use Facebook only as an educational
tool . . .

[richmond62]

I don't think a fork of 6.x is a bad idea at all

I do as the major leap with Unicode and other features happened post 7.x, and
the stagnation set in with the 9.x series

[SethMorrow]

The stuff I am currently doing is with the most recent build from LiveCode's now archived GitHub project, but I certainly wouldn't discourage anyone from working on a 6.x fork.

[axwald]

Hi,

[...] don't go.

No wrong hopes, I plan to continue lurking, at least. I'm much too curious to leave this alone ;-)
Dunno if there's something to contribute for me. But if it's desired, I'm able to point at some more or less serious bugs in the new Win/Linux versions - that may be unnoticed because they don't exist in the Mac version, and are sometimes not obvious by the occasional glance in a VM. My (few & slowly) ongoing changes to my 6.7.10 ScriptEditor & palettes will not be of much use, I guess.

I don't know what I think about this "serious coder" business [...]

Me neither. I'm still baffled.
For me it's just a descriptive term, w/o any value judgment. But then, quite some terms of language have become "forbidden" now, especially among the "serious social media folks". Maybe I just stumbled onto someones lawn, unwittingly?

[...] I DO know that I am not a C++ programmer, and so we will NEED some of them. I also know that I have no idea how to attract them.

This is a main problem IMO, especially for the new versions, where quite some work may be required to create something worthwhile. As far as I can remember there were some few of these on the other forum, but quite a lot of good ppl have vanished during the recent years. I don't know if there's someone left.

and for the record, I don't think a fork of 6.x is a bad idea at all, whether or not LC, ltd were to agree or not.

There was an opportunity over at the other forum, so I threw in this proposal there, too - in a more elaborate form, recycling some drafts I had around. I'm convinced that, from all variants talked of as yet, this is the one that had the best chances to succeed.


Ouch! There's one more thing:

Erm, "Axel Zwingenberger", who on earth is 'Richard'?

Grrmml, I mixed up your name. Such shouldn't happen, see me ashamed! I took the liberty to correct it, and apologize! Btw., I'm not 'Axel Zwingenberger'.
A peace offer: https://www.youtube.com/watch?v=dQw4w9WgXcQ

Have fun!

[richmond62]

Cripes: Rick Astley . . . give me Axel Zwingenberger any day.

People are always getting my name wrong, because, let's face it, it is unusual:
but my Grandfather was called Richmond McIntosh, and, oddly enough,
my best friend's grandfather was called Richmond Singh: and Scotland and Bengal
are not natural neighbours.

I am never offended when someone calls me Richard by mistake: actually it is rather fun
as it gives me an excuse to pull their leg a bit.

[OpenXTalkPaul]

"serious coder" here is the equivalent to the mailing list's "cheese"? Didn't know, apologize!

I don't know what that means, but OK? I've mostly use the use list via This Week In LiveCode and via search. I've never been a fan of mailing lists, I like/need ability to correct/edit my posts too much. My defensiveness in response to "serious coder" is mostly based on attitudes of certain pro-programmer's that I've personally know, and the fact that there weren't really any C++ pros donating code to Community Edition in the past so perhaps not too many of that C++ pro type of contributor has not been attracted to the concepts of xTalks... although it looks like a few independent projects such as StackSmith have gotten fairly far on their own, so maybe there's some other reason they didn't want to be involved with LCC. I'm willing to at least try to learn more C++ and whatever else it takes to keep this thing alive.

• For me a "serious coder" is someone that does its coding with love & considerable time & labour, and has fun doing it. Someone who, for instance, spends most of the time coding by choice - no matter if payed for or not.
• In contrast to someone that only codes for money, and wouldn't touch an IDE in private.
• In contrast to someone that occasionally does some coding, but has many other, more important, things occupying his time.

Too be honest, I felt a bit startled by your reactions. It really seems as if I triggered a reflex.

It did, people have reflexes, no biggie. To be honest I've gotten a little irritated on occasion because, while I do appreciate the diversity of ideas, we've gotten advice on what we should do or shouldn't do but not much help doing any of it.

Your bullet points are conflicting. In the first one I'm a "serious coder" in the last one I'm not, because I have a full time job (in the graphic arts) that doesn't have much to do with coding, and I also have a family that takes priority over everything else... I also have other hobbies (music composition for example) but they've become intertwined with coding.

This explained, I understand that we have quite different opinions & goals, and that I don't really suit in here. So my best wishes for your project, may it (and you!) live long & prosper!

I'm agree with the big tent thing. The more goals and more opinions the better... I just think if you're looking for a commercial quality product, commercial level support, and timely updates that may be an unrealistic expectation.

Paul: Obviously you have just skimmed the links I provided. Additional hints:
The libURL problem was observed in Win, too - but only randomly!
The "Windows not being good at expanding it's buffers/memory allocation" is noticed as solved in LC 9.6.4
Both Win & Android show unpredictable fonts & sizes, different from any other apps on these devices.
SQLite on newer Linux versions doesn't work - code-created dbs fail with "invalid database type" ...

I did only skim through those, because I'm trying to do 3-4 different things in a short amount of time.
libURL is a Script library if I'm not mistaken? Not sure... but I'm pretty sure I could find other URL libraries on every platform. In my Mac LCB projects I've use NSURL (NS as in NeXTstep/Apple Cocoa/GNUStep), and I've rolled my own in xTalk at times (going back to my Tarantula HTML editor project way back in the 90s). I could wrap a substitute URL library, It would probably be best to keep the amount of foreign libraries down to a minimum if possible, particularly with something like URLs are just strings.

If the buffer/allocate problem is an engine problem that's solved in 9.6.4, then it should also be in 9.6.3 because my understanding is that they basically admitted that there wasn't really any changes between those two versions beyond the new licensing schemes.

"Win & Android show unpredictable fonts & sizes, different from any other apps on these devices."
This is a mysterious problem, obviously font files don't change (unless they have, which sometimes Font vendors do)... so it must be changes in the rendering engine. I can't imagine why it would be unpredictable? Are you saying fonts look different from one launch to the next with no modifications to the stack?

SQLLite on Linux probably needs a newer build of that library as a driver for the revDB external.
Personally I've become very interested in Linux over the past few years, and will be installing some Debian distro to test/build OXT on.

[susan]

I certainly wouldn't discourage anyone from working on a 6.x fork.

Agree. Not needing unicode, 6.x most of the time I am attracted by the "solidness" of that IDE version and the general zippiness.

Of course, if unicode is essential for someone then that path is a dead-end.

I might download version 6 from the github and see how difficult it is to compile. If it doesn't work "out of the box" I expect to immediately give up as I don't have the skill (or time!) to figure out such things. But it would be interesting to try.

Happy to share my experiences, if there is anything to report.

[OpenXTalkPaul]

I certainly wouldn't discourage anyone from working on a 6.x fork.

Agree. Not needing unicode, 6.x most of the time I am attracted by the "solidness" of that IDE version and the general zippiness.

Of course, if unicode is essential for someone then that path is a dead-end.

I might download version 6 from the github and see how difficult it is to compile. If it doesn't work "out of the box" I expect to immediately give up as I don't have the skill (or time!) to figure out such things. But it would be interesting to try.

Happy to share my experiences, if there is anything to report.

If you're on macOS I can tell you that it's not going to work out of the box, unless you're still running macOS 10.9 with the XCode version from back then. There is a script around that can symbolic link newer versions of Xcode to older versions of the macOS SDK, and then it should compile. I haven't gotten back to trying to it compile yet, I needed to clear a bunch of space on my laptop first.

I've been thinking of mixing in parts of the older versions of the IDE, like the preferences UI or StartCenter stacks for example, and also I want to take a look to see why is it that HyperCard Stacks can't be imported in v7 and higer versions. I know there's not much use for that these days, but it something that attracted me to LC when I first saw it about 7 years ago. Another thing I've noticed, looking at the installers all in one place, is how much larger, file size wise, that LC has grown since v.6, the Mac version 9.6.3 installer is literally 10 times the file size that v6.0.1 was! From all the digging into the IDE I've been doing I can tell you there's lots of old unused files / images that are still in there, I'm guessing most of that is for backwards compatibility reasons?

If you just want to download an old community pre-compiled versions they're all up on Archive.org
https://archive.org/search.php?query=cr ... 2C+Inc.%22
As well as still available here:
https://community.livecode.com/6_7_11/

[susan]

If you're on macOS I can tell you that it's not going to work out of the box

Thanks for the time saving heads-up. I am primarily a Windows user (am I the only one here? ) so I am going to try that build. I suspect that my experience will be the same as on the mac, but I will still give it a try and let you know what happens.

My biggest fear is getting a cryptic C++ compilation error. And if that happens, it's game over for me. I also have no experience with sophisticated build tools, but if it is a .bat file that would be awesome.

Yeah, I don't have the 6.7.11 executable, so that might be good to get!

[OpenXTalkPaul]

If you're on macOS I can tell you that it's not going to work out of the box

Thanks for the time saving heads-up. I am primarily a Windows user (am I the only one here? ) so I am going to try that build. I suspect that my experience will be the same as on the mac, but I will still give it a try and let you know what happens.

My biggest fear is getting a cryptic C++ compilation error. And if that happens, it's game over for me. I also have no experience with sophisticated build tools, but if it is a .bat file that would be awesome.

Yeah, I don't have the 6.7.11 executable, so that might be good to get!

Seth is a Windows and Linux User so you're not alone. I'm mostly macOS user (since 1987), but I've done a lot of playing around with various Linux builds too. I currently have both macOS and Windows 10 on my laptop, and I'm about to try for a triple boot setup, adding a Linux.

One thing I just found out that's a deal breaker for me for LCC 6.x base is that it's a 32bit only build! I had thought that it was 32bit and 64 bit, that was wrong. Which means you can't run 6.x on the last two major macOS versions (10.15 or 11).
Though we might still be able to use older pieces of the 6.x IDE since that's all built with scripts/stacks.

[susan]

One thing I just found out that's a deal breaker for me for LCC 6.x base is that it's a 32bit only build!

I have the opposite problem. I own a couple of 32 bit Windows laptops that are aging, but still work fine. One of them runs Windows 10 under 32 bits quite effectively.

So when software moves to a 64 bit only build, I am sad.

Shotcut went 64 bit only which was a shame, and there have been some steam games and software that I wanted to run on those machines, but couldn't because they no longer support Win32.

[OpenXTalkPaul]

One thing I just found out that's a deal breaker for me for LCC 6.x base is that it's a 32bit only build!

I have the opposite problem. I own a couple of 32 bit Windows laptops that are aging, but still work fine. One of them runs Windows 10 under 32 bits quite effectively.

So when software moves to a 64 bit only build, I am sad.

Shotcut went 64 bit only which was a shame, and there have been some steam games and software that I wanted to run on those machines, but couldn't because they no longer support Win32.

LCC 8.x on macOS was 63 & 32 bit (but default is 32bit mode), 32 bit only on Windows until 9.x. I think Linux had separate builds for 32bit & 6bit. It looks as though like they removed some externals like revVideoGrabber in 8.x, maybe because they were 32bit only? LCC 8.x does have LCB middleware so that (AFAIR, LCB in 8 have Foreign Function Interface?) might be useful to restore some functionality like that, and a lot more!

I completely understand/respect the desire to not want to toss perfectly good older hardware into a landfill, it's just don't know what could be added or fixed to those existing older versions 6/7 that would be worth putting in the effort to try to do? Other than maybe removing some now-pointless commercial version related things and perhaps trimming the size down a bit? With LCB in 9 there's plenty that could be added, even without ever recompiling the core engine!

[susan]

it's just don't know what could be added or fixed to those existing older versions 6/7 that would be worth putting in the effort to try to do?

For me any effort is motivated solely by finding out is it possible, and will it work? That is the reward.

I promise not to co-opt anyone from the main goal here!

[richmond62]

ALL the versions of LiveCode Community "work".

At present that is not the problem (after all I use both 9.6.3 and 8.1.10 on a daily basis right now).

What IS the problem is how to remove all the references to LiveCode that need to be removed while
keeping things running so that there can be on-going development.

I, for one, have almost NO intention on doing anything beyond taking the originl source code of an LC
version and attempting to remove those references, quite independently of anyone else's effort, mainly
because I am 100% useless at working in a team.

IFF I manage the above, I will post it somewhere so it is available for anyone who wants it,
and who may or may not choose to "muck about with it" further.

[susan]

ALL the versions of LiveCode Community "work".

Yes, but what I was meaning was could I get the building from the source to work? (I can see that was not clear.)

I understand, that there is no need to rebuild the binary engine, to remove all branding and make a fork.

All I am interested in doing is spending an afternoon, to see if I can build v6.x it from the source as an interesting exercise.

I won't waste time on it, and of course most people here will want a 64 bit version (especially the users on macs that can no longer run 32 bit) with all the extras of 9.x

But on Windows, around the world not everyone has modern machines, and the way it has continued to run such win32 apps is quite useful.

[OpenXTalkPaul]

ALL the versions of LiveCode Community "work".

Yes, but what I was meaning was could I get the building from the source to work? (I can see that was not clear.)

I understand, that there is no need to rebuild the binary engine, to remove all branding and make a fork.

All I am interested in doing is spending an afternoon, to see if I can build v6.x it from the source as an interesting exercise.

I won't waste time on it, and of course most people here will want a 64 bit version (especially the users on macs that can no longer run 32 bit) with all the extras of 9.x

But on Windows, around the world not everyone has modern machines, and the way it has continued to run such win32 apps is quite useful.

I'm not yet entirely sure that there is no need to rebuild the binary engine to remove all branding. Mainly because they integrated the installer into the main binary in later versions.

Personally, I don't have a problem with co-opting.

I do think it would be cool to back-port v9 to 32bit. Personally I'd even be interested in back porting to PowerPC 32/64 bit. Just that not right now, as Re/De-Branding has to come first.

I'm also still looking at the startup chain a lot. A lot of interesting things there, like a few calls to what seem to be non-Script, internal engine commands/functions, such as revInternal__SetAppIcon.

Particularly interesting is revInternal__StackFiles(), which returns a list of stack files used by the IDE. What is interesting (pain in the ass) about it is that if you try to use that outside of the beginning of the startup process, like from the message box or even later in the start up chain, it completely disables EVERYTHING in the IDE!
I think this is related to this engine function in the C++ file called exec-interface-stack.cpp:

Code: Select all

 MCStack::GetStackFiles(MCExecContext& ctxt, MCStringRef& r_files)

particularly the MCExecContext part, ctxt param needs to be something particular, not yet sure what exactly or how it checks for the 'starting up' execution context.

I was able to work around that revInternal__StackFiles() in the Home script in order to make it so you can now put a stack called "Start Center.oxtstack" in your "My OpenXTalk" folder and if that is present it will load that as your "Start Center" stack instead of the one in inside the IDE directory (which mine is currently a blank stack because it was loaded with branding and links ). Now if you want you want a start up stack that looks exactly like HyperCard, you can do that, or have one that looks like NASA Mission Control if you'd prefer! And this user "Start Center" is opened as a regular editable stack (instead of as a palette)! That IMO is the best part of the Open in OpenXTalk!

[OpenXTalkPaul]

If someone could figure out the process used to get the individual .lcdoc files that make up the dictionary packed into a SQLite API db file that is what is actually included with the IDE (and then subsequently extracted and cached in a users directory), that would be helpful.

Seth already did a bunch of editing the docs files to remove brand references, but they're still in the raw lcdoc format.
Additionally, I think we could remove the dictionary entries for commercial only things such as tsNet.

[susan]

If someone could figure out the process used to get the individual .lcdoc files that make up the dictionary packed into a SQLite API db file that is what is actually included with the IDE

Am I correct in understanding that there is a sqlite file somewhere, and you are hoping to retrieve the entries in that file that are from individual .lcdoc files?

Is this because the .lcdocs are not part of the github, and so need to be extracted to be able to work with them?

[susan]

If someone could figure out the process used to get the individual .lcdoc files that make up the dictionary packed into a SQLite API db file that is what is actually included with the IDE

Am I correct in understanding that there is a sqlite file somewhere, and you are hoping to retrieve the entries in that file that are from individual .lcdoc files?

Is this because the .lcdocs are not part of the github, and so need to be extracted to be able to work with them?

Oh, okay. I re-read your question. I had it back-to-front didn't I!

You want to figure out how to turn the individual .lcdoc files into the sqlite file, right?

Coming to the problem side ways, can the database entries not be packed/encrypted, and instead the OpenXTalk API viewer be altered to take the plain text .lcdoc format, so not need a decoding step?

Or am I still misunderstanding?