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

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!

Post a reply


This question is a means of preventing automated form submissions by spambots.
Smilies
:D :) ;) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :!: :?: :idea: :arrow: :| :mrgreen: :geek: :ugeek:

BBCode is ON
[img] is ON
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: What I'm adding, and what I'm planning next...

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

by mwieder » Sun Jun 16, 2024 5:17 pm

Might be PowerTools is assuming that the pre-existing Tools palette filename is 'revTools', currently in my OXT DPE ('heavy') this stack file is actually named 'oxtTools.oxtscript' and there is no file with the name revTools.
Yes, that's correct. And it does the right thing in the OpenXTalk-x86_64.AppImage you posted a cou[ple of years ago. I'll cobble together an experimental version that checks that out and send it your way. Can I assume that 'oxtTools.oxtscript' is the filename and 'oxtTools' is the stack name? Have you renamed the Preferences stack as well? Here's the proposed code:

Code: Select all

function getIDEStackName pRevStackName
   if there is a stack pRevStackName then
   else if there is a stack "MetaCard Menu Bar" then
      switch pRevStackName
         case "revPreferences"
            put "Preferences" into pRevStackName
            break
         case "revTools"
            put "Tools" into pRevStackName
            break
      end switch
   else
      # neither rev nor metacard. now what?
      switch pRevStackName
         case "revPreferences"
            put "Preferences" into pRevStackName
            break
         case "revTools"
            put "oxtTools" into pRevStackName # added for OXT
            break
      end switch
   end if
   return pRevStackName
end getIDEStackName

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

by OpenXTalkPaul » Sun Jun 16, 2024 4:12 pm

I'm getting that issue where there's two stacks with the same name with PowerTools 'revtools' and my modified OXT 'revTools' and the IDE goes all loopy.

Might be PowerTools is assuming that the pre-existing Tools palette filename is 'revTools', currently in my OXT DPE ('heavy') this stack file is actually named 'oxtTools.oxtscript' and there is no file with the name revTools.

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

by OpenXTalkPaul » Sat Jun 15, 2024 9:06 pm

tperry2x wrote: Sat Jun 15, 2024 4:49 pm Between other jobs, I'll probably add this as an option (last on the left, of the preferences window).
Inspired by Firefox's about:config page, or Chrome's chrome://flags page
Just as a way to verify prefs are set correctly if nothing else. (might be helpful if anyone is debugging stuff).
I put this together (link here).

screenshot.png

It also times how fast it does the data fetching, the sorting, and the colouring - so I suppose you could also use it as a kind of benchmarking tool too.
This is something very similar to a stack I threw together that uses the Tree View widget to display that Array:
View revPrefs.oxtstack
(69.39 KiB) Downloaded 1 time

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

by mwieder » Sat Jun 15, 2024 8:30 pm

I never would have considered replacing an IDE stack In-Memory with a different stack (seems like maybe could be security issue).
Heh. Yeah - I had to brain my way around how that mechanism was gonna work. Renaming in place was/is necessary though because of the unfortunate interactions with other system stacks: set the blah of stack "revTools" to blah. For instance the control-tab toggle between edit and browse modes not only explicitly references the revTools stack by name but also references the names of the controls used to display the current mode, so I'm stuck with those.

I tend to use the "dispatch" command a lot (a LOT) in order to avoid that kind of coupling. If the command was handled then the proper recipient handler was in the target. If not then no harm, no foul.

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

by OpenXTalkPaul » Sat Jun 15, 2024 8:14 pm

mwieder wrote: Sat Jun 15, 2024 6:30 am 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"
Yes, as you could probably see there was lots of code I commented out too, from when I was trying different things to make revTools look OK in macOS 'darkMode', once I got it to look OK on all desktop platforms, I moved on to other things without adding any sort of error checking. At minimum those should be wrapped in try/end try structure to ignore errors like that. I never would have considered replacing an IDE stack In-Memory with a different stack (seems like maybe could be security issue).

The 'darkMode problem' is common with a lot of community made stacks where authors applied a light color background but didn't apply a foregroundColor / textColor, assuming that the default foregroundColor will always be black is a bad assumption as, at least on macOS, the Engine inherits the defaults for fore/back colors from the operating system, which toggling between light/dark mode changes these colors and then all that text becomes white 'on the fly' if the text chunk is at its default ('empty'), which of course is much less readable when its a top a light background color.

I've been thinking I'd like to have unified Color Library, to which I would facilitate detecting 'dark' mode on ALL platforms (including web), and that GIMP Color Palette file reader (there's even Pantone color match sets available for Print pros) that I posted months back, plus some functions from OXT Color Swatches Palette (like web hex<>RGB triplet). Additionally there's two open-source color libraries on gitHub, Quatram Color Lib (LGPLv3) which has handlers for converting RGB<>CMYK (printing), HSL, etc., and also TinyColor ported from a JS lib by the Ferrus Logic guys (MIT license) (includes 'darkMode detection' on Win/Linux). Both also nice for making color variation sets, get complimentary colors, etc. I would however prefer one unified library for all these color related things.

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

by tperry2x » Sat Jun 15, 2024 4:49 pm

Between other jobs, I'll probably add this as an option (last on the left, of the preferences window).
Inspired by Firefox's about:config page, or Chrome's chrome://flags page
Just as a way to verify prefs are set correctly if nothing else. (might be helpful if anyone is debugging stuff).
I put this together (link here).
screenshot.png
screenshot.png (71.86 KiB) Viewed 39 times
It also times how fast it does the data fetching, the sorting, and the colouring - so I suppose you could also use it as a kind of benchmarking tool too.

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

by mwieder » Sat Jun 15, 2024 6:30 am

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"

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

by mwieder » Sat Jun 15, 2024 6:06 am

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.

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

by OpenXTalkPaul » Sat Jun 15, 2024 1:33 am

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!

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

by mwieder » 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

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

by tperry2x » Fri Jun 14, 2024 1:47 pm

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?

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

by tperry2x » Fri Jun 14, 2024 1:44 pm

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:

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

by richmond62 » Fri Jun 14, 2024 1:26 pm

Looking very nice indeed! 8-)

And how can we we get our sweaty paws on it right now?

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

by tperry2x » Fri Jun 14, 2024 12:55 pm

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 84 times
colour-drag.gif
colour-drag.gif (350.38 KiB) Viewed 54 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!)

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

by OpenXTalkPaul » Tue Jun 11, 2024 12:55 am

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).

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

by richmond62 » Sun Jun 09, 2024 6:30 pm

'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!

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

by richmond62 » Sun Jun 09, 2024 6:24 pm

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-)

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

by tperry2x » Sun Jun 09, 2024 4:32 pm

** 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'

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

by tperry2x » Sun Jun 09, 2024 3:14 pm

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).

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

by richmond62 » 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.

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.

Top