LiveCode Forums.

All,

Many years back I purchased the educational version of Runtime Revolution because I saw the potential for rapid prototyping which the product could provide, and more than that, the power to build the entire application in transcript/LiveCode.

Skip to the present and I was struggling big time with a uni assignment to make an android app using Android studio. That beast of a product takes more that a few weekends to master! Plus I soon realised that my Java skills were not up to muster. So in desperation I reached out and installed LC community edition 7.1, initially on a Linux machine. What a pleasant experience! everything seemed to make sense. Sure, I stumbled on a few matters like how pass variables between cards, and had forgotten the syntax, but it was quite easy to pick it up again. Self documenting code - the whole codebase reads like comments! I'm sure that if I revisit the code in a year's time it will be easier to understand than the equivalent Java code.

I managed to cobble together a half working app which was better than the vaporware which was likely to result from the android studio. As a newbie, or prodigal son, there were a few things in this experience which unsettled me, and led me to wonder whether to invest further time with the product.

1.Native look and feel. My app looked like a desktop app trying to be a mobile app. I could not get the demo version of MobGUI working. Its a problem that such an important feature is left to an indie developer who could abandon development or not maintain compatibility with all releases.
2. Lack of robust features in IDE. While the edit/run mode toggle is awesome, the lack of code completion and suggestions while entering the code is something I miss from the Visual Studios and Eclipse type of IDE. It's a shame the GLX2 editor features never made it into the product
3. Lack of current windows version support. I ran LC 7.1 on windows 8 in compatibility mode and it was AWFUL. On the second Windows 8 machine it would not run at all. Same on Windows 10. I would not advertise that you can run it on these platforms at the moment. I was waiting seconds for any GUI interaction to see the result. Simply not workable.
4. Genymotion emulator is not supported (at least out of the box). This is a terrific emulator and runs rings around Google's. The reason is it runs on x86 not ARM. After patching my Genymotion emulator with ARM support, I still could not get fields to work reliably (could not populate the fields with text)

On the whole the experience was very positive but I am worried that the product is trying to be a jack of all trades and will end up as a master of none. For example one of the demo apps did not run on Linux (the library database). The reason was the code made reference to the specialfolders (documents) property. The only problem is, Linux does not understand this. When I changed this reference, the demo app worked fine. It hints that the engineering team is struggling to maintain the ecosystem across this wide range of targets.

I hope that these issues can be addressed quickly. I would really like to see this product thrive and live up to its full potential. Please note, as a noob, I hope I am wrong about all of the points I have mentioned above.

Regards,

Supergrass

Welcome back.

2. Lack of robust features in IDE. While the edit/run mode toggle is awesome, the lack of code completion and suggestions while entering the code is something I miss from the Visual Studios and Eclipse type of IDE. It's a shame the GLX2 editor features never made it into the product

I've been holding off releasing a new version of GLX2 because with the new LC7/8 engine it grabs the entire CPU cycles on linux. Haven't yet gotten to the bottom of that. Also, I'm really hoping that we can use an external editor of choice and I won't have to maintain this thing any more. But yes, code completion, code structure folding, single-click navigation to handler declarations, refactoring support... I would stop maintaining glx2 in an instant if all these things made it into the built-in script editor.

The reason was the code made reference to the specialfolders (documents) property. The only problem is, Linux does not understand this.

To be fair, documents is not documented as working on linux (although I'm not sure why not).
The workaround is to use $HOME & "/Documents"
I do realize that's not the point you were making there, and you're making a valid point.

I can't comment on the Windows thing because that's a platform I haven't used in a few years now.
And LiveCode does really have to be a jack of all trades by its very nature, so trying to be everything to everyone will always have some failures. Hopefully they can be addressed as they come up and won't be major rifts. For example, there are better database tools if that's all you're after, because LC isn't specifically a database tool. And better networking tools if that's all you're after because LC isn't specifically a networking tool. But for most purposes LC is a great database tool and a great networking tool. And on and on...

I've been avoiding messing with the script editor or GLX2 until 8's take is out. The SE could use a bunch of effort. I have a long list of things that I would like to see in it, like folding, bookmarking, completion, matching, etc. I was thinking that after we have something more definitive in 8, then it's time to really work on the SE.

Mikey wrote:I've been avoiding messing with the script editor or GLX2 until 8's take is out. The SE could use a bunch of effort. I have a long list of things that I would like to see in it, like folding, bookmarking, completion, matching, etc. I was thinking that after we have something more definitive in 8, then it's time to really work on the SE.

One of the most important goals of v8 is to retain full compatibility with v7 and earlier. Why wait?

Just because it's compatible doesn't mean that it isn't going to get worked on, a lot, first.

Mikey wrote:Just because it's compatible doesn't mean that it isn't going to get worked on, a lot, first.

I would hope that compatibility with existing code would be a priority. After all, without that v8 would be of very limited use.

Richard-

The script editor, like much else in the IDE can change at a moment's notice. Currently the IDE passes a lot of SE messages around. These have to be caught in frontscripts right now until the publish-and-subscribe mechanism in the engine is fully fleshed out. Once that settles down (assuming that it does) then it'll be less of a moving target.

Mikey-

I'm still holding off doing an actual release of glx2 until the linux thing gets settled http://quality.runrev.com/show_bug.cgi?id=15617, but I'm happy to send the current version to anyone who wants to look at it on osx or <ThePlatformThatShallNotBeNamed>. And, of course, feel free to grab any code in there that's useful if it can be grafted onto SE modifications.

You know where I live...

<g> I put a beta build of v19 in the usual place.
https://bitbucket.org/mwieder/glx2/downloads
Have fun.

mwieder wrote:Richard-

The script editor, like much else in the IDE can change at a moment's notice. Currently the IDE passes a lot of SE messages around. These have to be caught in frontscripts right now until the publish-and-subscribe mechanism in the engine is fully fleshed out. Once that settles down (assuming that it does) then it'll be less of a moving target.

I think we're looking at quite a while before the IDE "settles down", possibly late in the v9.x series. Or at least I hope so. There's too much to do, and I hope they wouldn't hold off on all of it until every IDE change could be done in one move.

And if they did hold off that would still mean the current setup would have more life than one might expect.

Personally, I just build stuff when I need it. I tend to build for the latest Stable and I try to capture as many previous builds as I need and/or is convenient. Anything I build for v6 will work in 7, anything in 7 will work in 8, and 9, and beyond.

LiveCode's pretty capable right now, and has been for as long as I've used it. We hope there will always mean new features, and with it new opportunities. But that means nearly constant flux, and that's okay since I like new features too. Constant flux has been the norm with many dev tools and most operating systems for as long as I can remember; I see no reason why this one tool should have some moment in its future where it'll be at a standstill.

Just keep the code reasonably factored, and have fun building cool stuff now.

Personally, I just build stuff when I need it. I tend to build for the latest Stable and I try to capture as many previous builds as I need and/or is convenient. Anything I build for v6 will work in 7, anything in 7 will work in 8, and 9, and beyond.

That's an interesting paradigm, and something I always stick to when possible. But I've been updating some things to take advantage of new LC8 features, and that has implications for backward compatibility. It's easy to do something like
but then you have to do
because it won't compile otherwise.

I see no reason why this one tool should have some moment in its future where it'll be at a standstill.

It's not that it will come to a standstill, it's more the wasted effort that would go into it now. Currently glx2 works as a script editor in all versions of Revolution/LiveCard, and I've only recently trimmed out some MetaCard things because I don't know of any MC users who are using it. But glx2 catches script editor messages in a frontscript, and any alternate script editor would also have to do something similar right now. LC8 is heading toward a system where a component would register interest in a message in order to receive it, and so all the frontscript message catching would have to be refactored to use the new system. Thus the amount of work that would go into something like this right now will soon become a waste of time, especially since everything except LC8 will soon be end-of-lifed.

Yes, things will always change, and hopefully the majority of the changes make things easier.

But if v8 maintains the backward compatibility we all need, it won't stop anything working in v7 from still working.