What I'm adding, and what I'm planning next...

A place to discuss and plan OpenSource xTalk (not exclusively LCC based)
and Community Builds of LCC ...Ask NOT what xTalk can do for you...
Get involved you DO have something to contribute, no matter your skillset!

Forum rules
A place to discuss and plan OpenSource xTalk (not exclusively LCC based) and Community Builds of LCC
Ask NOT what xTalk can do for you... get involved you DO have something to contribute, no matter your skillset!

What would you like to see in the next version?

You may select up to 5 options

 
 
View results

User avatar
tperry2x
Posts: 1840
Joined: Tue Dec 21, 2021 9:10 pm
Location: Britain (Previously known as Great Britain)
Contact:

Re: What I'm adding, and what I'm planning next...

Post by tperry2x »

Just a quick update on the properties inspector, which will appear in OXT Lite (at some point in the future).
This is what I'm working on currently, which is why things are a bit quiet. (Plus, I don't have a lot of time right now because lots of 'real life' stuff getting in the way).

Anyway...
Just been testing on MacOS and happily it works as it should with no bug fixes needed, which is nice (almost makes me feel that this might actually work!).

The goal will be to replace the original one eventually, which will have multiple benefits as mentioned. It'll also make adjusting it in future a lot easier too. Demo video here of it running on MacOS.
User avatar
richmond62
Posts: 3091
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Re: What I'm adding, and what I'm planning next...

Post by richmond62 »

Very impressive.

The thing I like the most is that one won't end up with a large number of properties palettes wallpaper one's monitor. 8-)
https://richmondmathewson.owlstown.net/
User avatar
richmond62
Posts: 3091
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Re: What I'm adding, and what I'm planning next...

Post by richmond62 »

What is a 'gfx'?
-
Screenshot 2024-06-08 at 9.42.53.png
Screenshot 2024-06-08 at 9.42.53.png (259.07 KiB) Viewed 615 times
https://richmondmathewson.owlstown.net/
User avatar
tperry2x
Posts: 1840
Joined: Tue Dec 21, 2021 9:10 pm
Location: Britain (Previously known as Great Britain)
Contact:

Re: What I'm adding, and what I'm planning next...

Post by tperry2x »

richmond62 wrote: Sat Jun 08, 2024 6:44 am What is a 'gfx'?
Simply a name for an object
Screenshot at 2024-06-08 09-06-31.png
Screenshot at 2024-06-08 09-06-31.png (44.07 KiB) Viewed 607 times
User avatar
richmond62
Posts: 3091
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Re: What I'm adding, and what I'm planning next...

Post by richmond62 »

Simply a name for an object
Erm? What type of object is that?

Are you introducing some new objects?
https://richmondmathewson.owlstown.net/
User avatar
tperry2x
Posts: 1840
Joined: Tue Dec 21, 2021 9:10 pm
Location: Britain (Previously known as Great Britain)
Contact:

Re: What I'm adding, and what I'm planning next...

Post by tperry2x »

richmond62 wrote: Sat Jun 08, 2024 7:38 am Erm? What type of object is that? Are you introducing some new objects?
No, as doing so would break stack compatibility. I'm still in 'fixing-mode', not 'adding-new-features-mode' at the moment. :D
User avatar
richmond62
Posts: 3091
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Re: What I'm adding, and what I'm planning next...

Post by richmond62 »

'break stack compatibility' . . .

Well, let's see:

1. LiveCode 6 can open MetaCard stacks without any serious problems.

2. With the change of capability of numToChar and charToNum, and the introduction of numToCodePoint and codePointToNum (in LC 7 as far as I remember - typing on phone in the garden), that mucked up some compatibility.

2.1. In fact that change cost me a month of sweat and curses re my Devawriter program, albeit the end result was a better thing.

3. Stack in LiveCode post 9.6.3 can contain features which 9.6.3 and OXT cannot cope with (e.g.polygrids).

4. There is no obvious reason why the inclusion of new objects in OXT should stop OXT's ability to import LC 963 stacks.

5. If LiveCode versions cannot cope with inclusions from OXT should that fuss us?

I don't think it is our job to pander to LiveCode: after all they are doing nothing re us being able to cope with any post 963 features, or the few features that differentiated their commercial offering pre- 9.6.4.

I also don't think we should be offering something that people can develop with up to a certain point and then port that to LiveCode, because at that point all we would be doing is providing LC with another revenue stream.

Were LiveCode to behave like MicroSoft and provide a way to save work on their platform to some common 100% cross-compatible file format (pace .ODT) then it would be reasonable to consider OXT doing the same.

But LiveCode do not produce MicroSoft Office, and OXT is not OpenOffice or LibreOffice.
https://richmondmathewson.owlstown.net/
User avatar
tperry2x
Posts: 1840
Joined: Tue Dec 21, 2021 9:10 pm
Location: Britain (Previously known as Great Britain)
Contact:

Re: What I'm adding, and what I'm planning next...

Post by tperry2x »

richmond62 wrote: Sun Jun 09, 2024 2:59 pm 'break stack compatibility' . . .
Well, let's see:
1. LiveCode 6 can open MetaCard stacks without any serious problems.
Is anyone still using metacard stacks?
richmond62 wrote: Sun Jun 09, 2024 2:59 pm 2. With the change of capability of numToChar and charToNum, and the introduction of numToCodePoint and codePointToNum (in LC 7 as far as I remember - typing on phone in the garden), that mucked up some compatibility.
Again, LC7 is a fair old way back in versioning now. Do we need to worry about supporting that? (although that wasn't a change anyone here made).
richmond62 wrote: Sun Jun 09, 2024 2:59 pm 2.1. In fact that change cost me a month of sweat and curses re my Devawriter program, albeit the end result was a better thing.
Some advances are a positive, but some tend to be a backwards step. It's worth thinking about what is worth keeping and what is worth discarding. If we drop any features, it's about making them fail "gracefully".
richmond62 wrote: Sun Jun 09, 2024 2:59 pm 3. Stack in LiveCode post 9.6.3 can contain features which 9.6.3 and OXT cannot cope with (e.g.polygrids).
That's where the 'Community' vision finishes, and we shouldn't worry about "trying to keep-up-with-the-jones's" over in LC-land.
richmond62 wrote: Sun Jun 09, 2024 2:59 pm 4. There is no obvious reason why the inclusion of new objects in OXT should stop OXT's ability to import LC 963 stacks.
There would be, if I add a classic control at the engine level, then save a stack using that object - LCC 9.6.x will either not include that object (best case), or crash spontaneously. (Already caused that with experimental mucking about here).
richmond62 wrote: Sun Jun 09, 2024 2:59 pm 5. If LiveCode versions cannot cope with inclusions from OXT should that fuss us?
probably not. It would mean that LC versions can't open OXT stacks, but I don't see this as a problem as you could argue LC10 stacks won't open in OXT - so I suppose compatibility is already broken to some degree.
richmond62 wrote: Sun Jun 09, 2024 2:59 pm I don't think it is our job to pander to LiveCode: after all they are doing nothing re us being able to cope with any post 963 features, or the few features that differentiated their commercial offering pre- 9.6.4.
Again, very true. This is where our OXT project definitely goes in a different direction.
Is this the point where we stop worrying about anything LC may/may not do with their product, because ultimately it does not concern us - and means diddly-squat to the OXT project relevance now? - Removing the 'card' terminolgy, is a good example. It has no bearing upon what we do with the OXT project. Again, that breaks compatibility even more in future - but it does more to draw a line between our OXT offering and the LC one, so it's a positive as far as I'm concerned. That isn't meant in a 'LC-bashing' kind of way, I mean that it will make the distinction between the two clearer for any new users (will we get new users - or do they expect everything on mobile/tablets these days?). **additional point to make on that.
richmond62 wrote: Sun Jun 09, 2024 2:59 pm I also don't think we should be offering something that people can develop with up to a certain point and then port that to LiveCode, because at that point all we would be doing is providing LC with another revenue stream.
This is kind of what I was on about once when I mentioned my 'concerns' about code being borrowed from here. Whether that's a genuine concern or not is still up for debate.
richmond62 wrote: Sun Jun 09, 2024 2:59 pm Were LiveCode to behave like MicroSoft and provide a way to save work on their platform to some common 100% cross-compatible file format (pace .ODT) then it would be reasonable to consider OXT doing the same.
Or to some degree, like Adobe with their 'interchange format' where you can save down to an older version. We kind of have that with a backsave to 'legacy' versions, but I suppose we have to draw the line somewhere with compatibility.
This is also what I mean when 'market-share' or similar terms are mentioned. Again, not something we have to concern ourselves with - 'we do us'. We should feel under no pressure to implement something if we don't feel it's beneficial to our project here. I certainly don't feel under any pressure because we aren't forcing anyone to use OXT lite / Heavy - that's their decision. There may be bugs, there may be some things we've made better... but we are working to our own timescales. It would be different if this project employed Paul or myself, but I'm not on the verge of being able to give up work or make this my full-time paying job any time soon.

What I mean though, is - is it reasonable to expect an .oxtstack to be openable in LCC9.6.x simply by changing the file extension back to .livecode? If so, then I can't add any engine changes (or changes to 'classic controls') as that will break stack formats (unless we don't care about oxtstacks being openable in LCC 9.x).
User avatar
tperry2x
Posts: 1840
Joined: Tue Dec 21, 2021 9:10 pm
Location: Britain (Previously known as Great Britain)
Contact:

Re: What I'm adding, and what I'm planning next...

Post by tperry2x »

** here's the additional point, mentioned above.
I was speaking to a visiting IT lecturer last week. Started off as quite an informal discussion, but then really got into the crux of why we might not see many new users.

If we look at how we came to know the language we know (and love?) - did we learn about it through schools, or did we find out about it purely by pottering around by ourselves?

I know for me it was a bit of a mixture. Our science teacher in high school had Hypercard on an iicx, and this was really my first in-road into hypertalk. It wasn't really mentioned at school, even back then - and this IT lecturer hit the nail on the head as to why.

Back then, if you were a teacher - you could go 'off-script' a lot more. You could really tailor the lesson to your own teaching style, and to an extent, you could kind of cover what you wanted - because it wasn't as regimented. As long as you were teaching the fundamental approaches (variables, functions, handlers, loops and the like), it didn't really matter what language you were doing it in.

(This is where I might upset Richmond :lol: )
I'm sure you have a lot more freedom Richmond in how you teach, and what you teach in your lessons.

Increasingly 'over here', teachers are being very much dictated to as to what they MUST teach in. It HAS to be Python, or is MUST be Rust. It cannot be something that is not on the curriculum. This is what this IT lecturer was mentioning: however good we make OXT (and he was hugely impressed with it btw), the likelyhood of it ever being used in an education setting is likely zero - because it's not something that any teacher will be expected to teach (or part of their performance metrics) (where's the yawn emoji?) - but this is sadly what teaching is becoming. A scripted approach, dictated down from above. The 'good-old-days' of teachers actually being able to do their own thing is certainly a rarity. (I remember for CDT classes, we actually rebuilt most of the CDT teacher's hillman imp on the playing field.) This undoubtably taught us more about engineering than any 'ergonomic study covering the fundamental design principals of office and home furniture' - and I can still clean and reassemble a carburettor to this day. He drove it off the field, fully working at the end of year 11. (Made us all smile to think we had a hand in getting it working, but the crafty so-and-so got free car repair with the use of all the metalwork machines in the CDT department).

To use a direct analogy: It's why English teachers might want students to read H.G Wells, George Orwell or John Green, but have to stick to Shakespeare or Emily Bronte. They might wish they could go 'off script', but ultimately because they know the students won't be tested on this other material - teaching them that is a waste of time and there's only so many hours in the day. Why spend ages recommending something when the student might fail on what the examiner expects them to know? This then comes back to the teacher if a certain threshold of non-passing students are reached, and the teacher's teaching methodology comes into question - and a 'performance review' kicks in. (Which is sad, but very unfortunately true).

If 'scripted teaching' is indeed the case, what I'm getting at - where do we think our 'new users' would be coming from? Is YouTube likely to be our only way of gaining extra audience? - would this mean that we are relying on only one source for our prospective new audience. (All our eggs in one basket?) - Or, do the young'uns expect EVERYTHING to be on tablets and phones these days (if that's the case, are we barking up the wrong tree and should be focusing our efforts in updating the mobile device app-building capabilities?)

*this can probably go in the 'education section'
User avatar
richmond62
Posts: 3091
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Re: What I'm adding, and what I'm planning next...

Post by richmond62 »

The people at SuperCard didn't get fussed about compatibility: I recall just having got 'somewhere' with Hypercard when someone shoved SuperCard at me: couldn't make it out at all: still can't. 8-)
https://richmondmathewson.owlstown.net/
User avatar
richmond62
Posts: 3091
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Re: What I'm adding, and what I'm planning next...

Post by richmond62 »

'Freedom', Yes: takers for this year's programming classes: ZERO, with about 20 days to go.

I very much doubt anyone will bite.

Schools here are now fully completely Pythonised, and parents ONLY are prepared to pay for something that will get their squabs better grades in the 'Coke Town' school system.

My Dad, a Chemistry teacher, took early retirement at exactly the age I am now, because he said he wanted to teach kids Chemistry, and not just teach them to pass exams: England. 1994.

If I did not have about 3 years on a wadset (erm: mortgage) to go I'd be poking round rockpools in Galloway right now!
https://richmondmathewson.owlstown.net/
User avatar
OpenXTalkPaul
Posts: 1835
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: What I'm adding, and what I'm planning next...

Post by OpenXTalkPaul »

3. Stack in LiveCode post 9.6.3 can contain features which 9.6.3 and OXT cannot cope with (e.g.polygrids).

4. There is no obvious reason why the inclusion of new objects in OXT should stop OXT's ability to import LC 963 stacks.
Polygrid is a widget by those Ferris Logic guys. It's a nice widget that was very nearly donated to the open-source community. Any widget that isn't installed but was used in a stack is going to be a "compatibility issue" when opened. This is true of LC CE v8 and v9 too. There was actually 2 versions of the Extension Module Format as well. Even Widgets that just get updated but include new properties or a new rDNS Identifier or version number that the previously placed version didn't have will cause that problem of being a blank or grayed out box.

But none of that prevents you from opening a stack with a missing Widget. What I'd really like is a way to update the old-placed version (which stores all of its properties as array) to use a new version that may be slightly different. The stack file format itself (which stands at version 8 in LC CE v9), is not really the problem here.
5. If LiveCode versions cannot cope with inclusions from OXT should that fuss us?
Again, I don't think LC 9.6.4 (or 10) can deal with missing widgets, the same way OXT can't, but if you install them they should be good (unless the widget was significantly changed).
I also don't think we should be offering something that people can develop with up to a certain point and then port that to LiveCode, because at that point all we would be doing is providing LC with another revenue stream.
Anything we develop for OXT is subject to GPLv3 (or compatible) licensing, so anyone distributing work that uses part of our work would be legally required to be released with GPLv3 (or compatible) license as well.

Personally I don't have a problem with people using it up to a certain point and then switching over to commercial LC, so long as they don't use anything from OXT without releasing their source code too (in accordance to the GPLv3 license agreement)

Speaking of compatibility file formats, I've mentioned this sort of thing quite a bit in the past. I actually want more ways to export things to other useful formats, including for example graphic UI / layouts to HTML or better yet to HTMX+_HyperScript or some encapsulated 'HyperSim' format (both of these I beleive are completely doable).
User avatar
tperry2x
Posts: 1840
Joined: Tue Dec 21, 2021 9:10 pm
Location: Britain (Previously known as Great Britain)
Contact:

Re: What I'm adding, and what I'm planning next...

Post by tperry2x »

richmond62 wrote: Sat Jun 08, 2024 6:17 am The thing I like the most is that one won't end up with a large number of properties palettes wallpaper one's monitor.
That is exactly my thinking, and the fact that I want to banish the 'sliding'.
inspector-colour-tests.png
inspector-colour-tests.png (115.52 KiB) Viewed 360 times
colour-drag.gif
colour-drag.gif (350.38 KiB) Viewed 330 times
Progress continues, now onto the business of sorting a redesigned FX inspector out (one that doesn't glitch out after a couple of uses!)
User avatar
richmond62
Posts: 3091
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Re: What I'm adding, and what I'm planning next...

Post by richmond62 »

Looking very nice indeed! 8-)

And how can we we get our sweaty paws on it right now?
https://richmondmathewson.owlstown.net/
User avatar
tperry2x
Posts: 1840
Joined: Tue Dec 21, 2021 9:10 pm
Location: Britain (Previously known as Great Britain)
Contact:

Re: What I'm adding, and what I'm planning next...

Post by tperry2x »

richmond62 wrote: Fri Jun 14, 2024 1:26 pm Looking very nice indeed! 8-)
Good stuff. I will add in the ability to set patterns / icons too. At this initial stage, I was just testing setting colours of various properties.
richmond62 wrote: Fri Jun 14, 2024 1:26 pm And how can we we get our sweaty paws on it right now?
Patience young padawan :lol:
User avatar
tperry2x
Posts: 1840
Joined: Tue Dec 21, 2021 9:10 pm
Location: Britain (Previously known as Great Britain)
Contact:

Re: What I'm adding, and what I'm planning next...

Post by tperry2x »

tperry2x wrote: Sun Apr 07, 2024 6:07 am
TAK1974 wrote: Sun Apr 07, 2024 1:38 am Could GLX2 be used as a model for the script editor?
Hi Tak.
Ah, do you mean https://github.com/mwieder/glx2ScriptEditor and https://github.com/mwieder/glx2ScriptEd ... umentation ?
I didn't know these existed. It certainly looks very good.
Do we have MWieder's permission, before we can even think about using it?
I've just had a message from Mark, granting us permission to use it. I just wanted to get direct confirmation of permission first. Thanks Mark - much appreciated.
Using this would be an advance over the original script editor, so @Paul - how feasible do you think it is to replace the built in script editor with this one in our OXT project?
mwieder
Posts: 44
Joined: Sun Jun 04, 2023 3:32 am
Location: Berkeley, CA, US, Earth
Contact:

Re: What I'm adding, and what I'm planning next...

Post by mwieder »

The glx2 script editor (latest version is v4.3.3 (2023.04.21) seems to work fine for me on linux in the AppImage build.
Also note that my debugger and tools palette replacements are open source now on github. The tools palette works fine in the same OpenXT build, and PowerDebug works as well with the exception of an initial minor tsNet dependency (the debug screen harmlessly pops up on IDE launch), which I hope to address soon.

https://github.com/mwieder/PowerTools
https://github.com/mwieder/PowerDebug
User avatar
OpenXTalkPaul
Posts: 1835
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: What I'm adding, and what I'm planning next...

Post by OpenXTalkPaul »

mwieder wrote: Fri Jun 14, 2024 6:05 pm The glx2 script editor (latest version is v4.3.3 (2023.04.21) seems to work fine for me on linux in the AppImage build.
Also note that my debugger and tools palette replacements are open source now on github. The tools palette works fine in the same OpenXT build, and PowerDebug works as well with the exception of an initial minor tsNet dependency (the debug screen harmlessly pops up on IDE launch), which I hope to address soon.

https://github.com/mwieder/PowerTools
https://github.com/mwieder/PowerDebug
VERY COOL! Thanks Mark.
I happened to be working on my own replacement for Tools currently, so I'm very interested in taking a look at "PowerTools" code!

I did try out glx2 script editor a few years back, but I couldn't get into using it full-time. I can't remember why. It did seem to work fine running as 'IDE Add-On', in addition to the 'built-in' ScriptEditor. I think there was some UI glitches or it didn't play well with the 'darkMode' enabled on macOS. I am most interested in 'code-folding' and auto-complete functionality, perhaps we could merge and have best of both script editors? Tom you don't need permission to do whatever you like in your OXT lite builds, as far as replacing ScriptEditor just go for it! At this point I'm following behind you! Trying to catch up, integrating fixes from your builds into mine!
mwieder
Posts: 44
Joined: Sun Jun 04, 2023 3:32 am
Location: Berkeley, CA, US, Earth
Contact:

Re: What I'm adding, and what I'm planning next...

Post by mwieder »

Feel free to cannibalize anything from PowerTools. I do have to say that there is some unfortunate coding in there that is required by interactions between LC stacks, most notably in object naming. I tried to compartmentalize that as much as possible.

Re the script editor, much of the code folding scripting is thanks to Bernd Niggemann. He has a patch for code folding in the builtin script editor as well. You can find it here https://forums.livecode.com/viewtopic.p ... 71#p229971 . Autocomplete might be more difficult to extract - I can take a look in a few days. The basic idea is to capture all the possible handlers and parameters from all open scripts on startup, then all handlers when you load a script. Then when typing you filter the handler list, showing only the resulting matches: commands if at the start of a line, functions otherwise.
mwieder
Posts: 44
Joined: Sun Jun 04, 2023 3:32 am
Location: Berkeley, CA, US, Earth
Contact:

Re: What I'm adding, and what I'm planning next...

Post by mwieder »

Hah! I found why the debugger comes up harmlessly on LC launch. In your home stack script in the IDEToLightMode handler you now have several lines of the sort

Code: Select all

set the opaque of group "background" of stack "revTools" to false
set the backgroundColor of group "background" of stack "revTools" to White
set the foregroundColor of group "background" of stack "revTools" to Black
and so on, which fail because these exist in your version of the revTools stack but not in PowerTools (which renames itself and replaces the existing revTools stack. Solving this would just be a matter in the home stack of

Code: Select all

if there is a group "background" of stack "revTools" then
	set the opaque of group "background" of stack "revTools" to false
	set the backgroundColor of group "background" of stack "revTools" to White
	set the foregroundColor of group "background" of stack "revTools" to Black
end if
or better yet, place a command "setGroupParams" in your revTools stack that handles the property settings and then in the home stack

Code: Select all

dispatch "setGroupParams" to stack "revTools"
Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest