OpenXTalk Forums

So . . . in a fairly bonkers move I decided to take a copy [NO, not THAT bonkers] of LC 9.6.3
and run a search and replace:
- -
and got slightly freaked about what would happen if I changed the name of button

com.livecode.interface.classic.DefaultButton

to something like com.openxtalk.interface.classic.DefaultButton

my legs went "all wobbly" and I chickened out at least until I get some sort of vaguely
reasonable reply to this post.

Huh, no takers . . .
- -
What a pox! Will not late me do a 'Replace'!

Aha, Got It! I am unable to replace any of the "All Other" list:
-

Having performed a 'search and replace' under all the other rubrics I wonder how
to effect that . . .

. . . fioch:
-

richmond62 wrote: ↑Wed Sep 15, 2021 12:17 pm Having performed a 'search and replace' under all the other rubrics I wonder how
to effect that . . .

. . . fioch:
-
SShot 2021-09-15 at 15.19.25.png

We have maybe conflicting things here? We must retain LC Ltd. copyright notices, we must also rebrand so as to not confuse LC's customers, but I'm not sure about renaming libraries, widgets and such. If you change any resources, there may be scripts that load some of these things by a specific name? If so that would also have to be changed in the scripts, Technically all of these things are copyright LC Ltd. ? up to 7/29/2021 with GPL3 Licensed granted and of course we should respect that copyright. LCB modules have their own copyright notices internally usually, but I guess renaming the files would be OK as long as we fix links that get broken. Any new libraries, images, widgets, can be named whatever we want: com.oxt.widget.mygog.paulmcclernan for example, that way we know what came from where. However any stacks out in the wilds that are already using widgets with those LC identifier names would also be broken for users. Stack authors using them would have to replace them in their stacks with the renamed widgets with the new identifier name. That's potentially a huge can of worms to open.
May need to keep open a line of communication with the mothership on some of this stuff.

richmond62 wrote: ↑Tue Sep 14, 2021 6:33 pm

3 chars

. . . XTC . . .

We're only making plans for xTalk yooohoooeww
https://www.youtube.com/watch?v=s29RKnB7l7o
As a bassist though I prefer the Primus cover version:
https://www.youtube.com/watch?v=kGoaQFXkbLM

We have maybe conflicting things here?

Indeed we do; my "steam shovel" approach (i.e automated replacement of every mention of 'livecode')
is obviously hopelessly naive.

richmond62 wrote: ↑Wed Sep 15, 2021 4:05 pm

We have maybe conflicting things here?

Indeed we do; my "steam shovel" approach (i.e automated replacement of every mention of 'livecode')
is obviously hopelessly naive.

Well I wouldn't say that! That's an approach I think we can use for certain things, just not everything, and maybe not the lcb widget stuff (unless we have to). Probably best to try that for one item at a time and then test to see if it breaks anything. I broke the start center when I tried to edit that because there's multiple versions of color schemes that get applied when it loads, when it thows the errors I just modified or commented out the line in it's script (but I might just replace that whole stack). I've been spending time redecorating and haven't really had a chance to get down to the nitty gritty things yet.

Drop these:

(Always work on a copy)
here: [on Macintosh]

app package/Contents/Tools/Toolset/resources

- - -

Delete the folders in 'resources' called 'commercial', 'communityplus', and 'professional'.

I just cloned out the old logos on some files but I didn't change any color scheme,
Not sure, do we need to have an official non-official color scheme? I know I don't want the neon greens that are there.

I suggest finding a good text editor like BBEDIt or Notepad ++ and doing a 'find in files" operation.

Or just running the text of the source files through a xtalk script and making changes there, maybe with a display of x number of lines to change, and a pause to wait for user to cancel/continue, so as to not batch bork the whole thing.

Then output a record of changes so that can be given a once or twice over to find mistakes made
something of an index like: file name, line number, text found, text changed

Then you can upload that to your git for back reference when needed.

xAction wrote: ↑Thu Sep 16, 2021 4:14 pm I suggest finding a good text editor like BBEDIt or Notepad ++ and doing a 'find in files" operation.

Or just running the text of the source files through a xtalk script and making changes there, maybe with a display of x number of lines to change, and a pause to wait for user to cancel/continue, so as to not batch bork the whole thing.

Then output a record of changes so that can be given a once or twice over to find mistakes made
something of an index like: file name, line number, text found, text changed

Then you can upload that to your git for back reference when needed.

Unfortunately not all branding is in text, some are images and binary stack files.
And I'm using Atom for that type of thing, has a workable LCS/LCB/revIgniter colorizing add on downloadable that is from within that app.

I wrote a little script to find and replace the word "LiveCode" in the dictionary docs. I am currently stepping though 657 changed entries to make sure all those changes make sense. So far I've done this in a personal fork, the changes I've made so far can be viewed here:

https://github.com/sethcmorrow/xTalkEng ... 958b52764c

I've also edited the guides. My edits can be found here:

https://github.com/sethcmorrow/xtalk-id ... ion/guides

Hope this is useful.

Thanks Seth! I'll take a look later today.
I think as long as it isn't a copyright notice and the wording makes sense, it should be fine, probably desired even.
I can edit existing PDFs too (something I've done a lot of at the "day job"), but maybe we should just start new release notes and such, leave the old ones in the archive?

Again, I would just like to keep any un-branding changes to generic if at all possible, instead of replacing with "OpenXTalk". I'm not even sure about logo images that I changed to OpenXTalk early on (with an already old version of a logo). My thinking on that is that way anyone can change the "brand" easily in the future, making it far more "Open" to change.
I hope everyone can agree on that?

I actually created a little stack to help me with editing the dictionary docs, so going back through to change "OpenXTalk" to something more generic like "the software" or "the engine" should be pretty easy. Whatever seems best. I can only really dedicate weekend time to this, but I am open to any and all suggestions. In my mind, the first thing we need, before adding anything new at all, is to have fully debranded and functional versions compiled. To that end, I will be attempting to compile and test a version with my edited docs on (64 bit) linux this weekend and then Windows when I have the time. I have no illusions that we will in anyway be able to keep up with or compete with LC, nor should we want to. I just want to see a living open source version remain available to educators and hobbysists. This certainly isn't going to happen overnight, but I think it's well within the realm of possibility to keep this thing alive.

SethMorrow wrote: ↑Tue Sep 28, 2021 12:22 pm I actually created a little stack to help me with editing the dictionary docs, so going back through to change "OpenXTalk" to something more generic like "the software" or "the engine" should be pretty easy. Whatever seems best. I can only really dedicate weekend time to this, but I am open to any and all suggestions. In my mind, the first thing we need, before adding anything new at all, is to have fully debranded and functional versions compiled. To that end, I will be attempting to compile and test a version with my edited docs on (64 bit) linux this weekend and then Windows when I have the time. I have no illusions that we will in anyway be able to keep up with or compete with LC, nor should we want to. I just want to see a living open source version remain available to educators and hobbysists. This certainly isn't going to happen overnight, but I think it's well within the realm of possibility to keep this thing alive.

I Agree. I plan to keep working at this for as long as it takes (forever), if that means I have to become a C++ pro, study programming language design, assembly language, etc. whatever it takes, I'm going to keep trying to do it. I'm in for the long haul.
There's basically a community of three people here so far, dedicating our limited spare time for the love of it, along with some curious visitors. Anyone coming here looking for a free alternative to a commercial product with commercial support is mistaken.

a community of three people here so far

Well, only 2 and a half if you include me in that list for the very simple reason that while I can
hack an existing install of LiveCode to bits I cannot do that sort of thing over on git hub and then
turn the result into some sort of installer.

richmond62 wrote: ↑Wed Sep 29, 2021 10:53 am

a community of three people here so far

Well, only 2 and a half if you include me in that list for the very simple reason that while I can
hack an existing install of LiveCode to bits I cannot do that sort of thing over on git hub and then
turn the result into some sort of installer.

You might want to give github desktop a whirl. Between GitHub Desktop, xTalk, and Atom (or BBedit or whatever), making changes is a breeze. With GitHub Desktop, you can operate on the files/stacks/folders from within LC or your favorite text editor/IDE, and then when you save, GHD will automagically find all your changes and ask if you want to push them to your project on GitHub. It's pretty nifty.

SethMorrow wrote: ↑Wed Sep 29, 2021 12:43 pm

richmond62 wrote: ↑Wed Sep 29, 2021 10:53 am

a community of three people here so far

Well, only 2 and a half if you include me in that list for the very simple reason that while I can
hack an existing install of LiveCode to bits I cannot do that sort of thing over on git hub and then
turn the result into some sort of installer.

You might want to give github desktop a whirl. Between GitHub Desktop, xTalk, and Atom (or BBedit or whatever), making changes is a breeze. With GitHub Desktop, you can operate on the files/stacks/folders from within LC or your favorite text editor/IDE, and then when you save, GHD will automagically find all your changes and ask if you want to push them to your project on GitHub. It's pretty nifty.

I've found that there are quite a few Git GUI's that are pretty good (such as SourceTree), so there's more cross-platform options to try for that. GitDektop is an official GitHub app though.

https://www.sourcetreeapp.com
https://git-scm.com/downloads/guis