Skids wrote: ↑Tue Aug 13, 2024 10:19 am
on the parent forum
Do you mean on ex-MotherShip's forums? I think they have a separate forum for people that have been test using LC Create now. Your account looks activated here.
It appears to me that Livecode Create (LCC) may have issues running legacy stacks. I refer to this thread
https://discourse.livecode.com/t/my-fir ... -result/55 from September 2023. In it user Jehale writes
one of the first things to hit you when moving from the desktop IDE to LC Create is that fact that all the controls are widgets. So the “field” control is not the same as as a field in the IDE but is a widget.
So you can’t put “xyz” into the field, you need to set the appropriate property of the widget
to put “wyz” into your field (called say “f1”)
set the text of widget “f1” of me to “xyz”
Does anyone know if this is still the case? If true then it implies that even if one subscribes to LCC there will be quite a lot of work to get stack files written in Livecode to run.
This is actually what I've been thinking about myself lately, why not stop bothering with even trying to style 'classic controls' to be
look-a-like to 'naive' controls, or messing around with 'Native Layer' actual native controls for simple things like buttons, and instead use Widgets with properties set equivalent to it's 'classic' counterpart, but also with a theming system (macOS-11,windows-10,winows-11,android-ics,etc.). I believe that's where LC was headed with that too, way back around 2015.
For any Text-widget control I would want it to behave as close as possible to the classic text field control. Such a text widget should be click-to-edit text (or at least use a simple click-to-input in an 'Ask' style dialog), not to have to edit the text in property inspector (unless maybe the PI was given much better editing tools). And of course it
MUST able to render Styled RTFText and HTMLText besides plain text, and be used for List-Select fields, just like the classic field controls do.
As far as cross-IDE compatibility, it's like Richmond said we can't worry about what they're doing 'over-there', we're on our own. Yes, a widget based theme-able set of new-'classic controls'-as-Widgets,
could be added to OXT and theoretically those could be crafted to match a properties set of some other set of controls from somewhere else,
HOWEVER, there is an identifier used with widget controls that is it's 'kind' property. OXT uses org.openxtalk.widget.whatever while LC has used com.livecode.widget.whatever, so such a widget would have to be deleted and then the other version replacing it and given the same property attributes and script of the former.
If the lc file format remains the same, and widgets that are used in such an 'LC Create' stack are of the same 'kind', which it looks like they have retained widgets that were introduced as part of the LC Community Edition, for example the SVGPath icon widget, Header Bar, etc. then those should still work fine in OXT since the identifiers of pre-existing widgets were left as-is, with their original LC identifiers intact in OXT.
Basically as long as you can load a widgets module (lcm file) in the open source version of LC Community 9.6.3, then it should work fine installed in OXT as well. That means it
must be open-source, it can't be encrypted like LC commercial editions extensions/widgets are.
I've already been treating some of the 'classic controls', such as the slider/scrollbars, as if there are deprecated because their default attributes aren't good with macOS darkMode, and they don't really match native controls anymore, and SVG Icon libraries and Widgets like Tree-view (and dare I say my Piano Widget), can be so much more useful to me.
But just to be clear, I have no intention of removing any legacy classic controls or anything like that, and in fact I'm good with (and have) added new styles for 'classic controls.', such as 'filled roundRect button' or 'square bevel button', but when I finish Tools palette redo then maybe I spend some time getting a base set collected, updated and ready for prime-time.