Yes, well, other people 'keep talking' and have yet to produce what they are talking about . . .They keep talking about it
Who said, "HTML5", oh, it was me, time to smack myself on the hand.
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
Yes, well, other people 'keep talking' and have yet to produce what they are talking about . . .They keep talking about it
HTML5 is a very big project. They're working on it, and we have the FMP initiative to thank for that -- something else you've disparaged. Much of that work gets incorporated into LC so we all benefit.Yes, well, other people 'keep talking' and have yet to produce what they are talking about . . .
I wouldn't dispute that: my Devawriter Pro has been "on the go" for 12 years and is only about half the way I want it to be.Ambitious things take time.
You may want to look closer: https://www.great-white-software.com/bl ... /heads-up/richmond62 wrote: ↑Wed Mar 31, 2021 5:11 pmXojo just sent me an e-mail:
...
1. Xojo IDE now native on Apple Silicon Macs.
...
Doesn't seem to go anywhere from here ? heh.(check out www.ifnotnil.com to get an idea...)
...and here I thought I was close to the only one I started with RB 5.5 and stopped updating it shortly after RB 2006, because it seemed like every release after that was coming up with a new problem, or a re-write of functions that worked perfectly before it. The real show stopper for me moving up was when the IDE started moving in slow slow speed despite my computer being fairly medium end hardware wise at the time.
sorry... i made a mistake in the URL, there is no 'www.'. The correct URL is https://ifnotnil.combogs wrote: ↑Mon Apr 19, 2021 10:35 pmDoesn't seem to go anywhere from here ? heh.(check out www.ifnotnil.com to get an idea...)
And it's only got slower since... dragging a control around on a busy layout goes at like 2 fps (or at least that was the case by the time i unsubbed)
Yah, I kept thinking it would speed up eventually, but it hadn't up till 2015, sooooo....... heh. If I recall correctly, at the time I had been thinking of cross porting my wife's db program, I had stepped up to RB 2012 to stop having to write my own rig to put pictures into the db. That was a complete disaster, going from 2006 (rock stable) to 2012 (crashed every few lines of code)... ugh.
Gonna guess that rather than a minority, you're in a majority of 90% of users (but probably the minority of companies, especially those where profit margins are very narrow).
It looks like LiveCode now wants the benefits and advantages of something that Xojo has had for many years: a code compiler to generate native, faster and more secure code for each platform. Congratulations to LiveCode for finally recognizing and adopting one of Xojo’s long held strengths.gperlman wrote: ↑Sun Apr 04, 2021 1:05 amHi. I’m here just to answer your question and clear up any confusion.
From you description of how LiveCode works, yes, Xojo is different. Xojo compiles your code to machine language for all platforms. The underlying Xojo framework is a combination of different languages depending upon what is needed including a fair amount written in Xojo itself and nearly all compiled to native machine code. The client side of our web framework is JavaScript of course. Xojo has no interpreter nor has it ever had one.
Side note: XojoScript is NOT the code in your app. It is a way to compile Xojo code at runtime. This would allow you as a developer to add a scripting language to YOUR app. Of course the syntax is Xojo. It could also be used if you needed to create math calculations or have your user enter them at runtime. The Xojo code you send to XojoScript is compiled at runtime. This is not the same as the code you wrote as part of your app. That’s compiled by the Xojo compiler when you build.
Side Note 2: Behind the scenes, Xojo uses LLVM, the same optimizing compiler that Apple uses with XCode. We just use it to compile for all platforms rather than just MacOS/iOS.
The one platform we don’t compile all the way down to machine code ourselves is Android. We are writing that framework in Kotlin because that’s the recommended language to use for Android. The code you write in Xojo for Android is also converted to Kotlin (for the same reason) and then compiled into byte code. It is that byte code that is then delivered to the device where Android then compiles it to machine code optimized for the device. That machine code is cached so it doesn’t have to do this every time.
Your Xojo source code is never part of the compiled app you deliver because we compile to machine code or in the case of Android, intermediate byte code.
Our goal with Xojo is for it to be as native as possible on all platforms. That means native machine code, native controls, etc. We do this to provide the best overall user experience possible via the speed of native code and the use of native controls. This is a lot more work of course but we feel it creates the best end result.
I hope this helps. I’m happy to answer any other questions.
Um, well, that can be taken in 2 ways (as the heffalump said to the centaur),and whichever way it is taken it is NOT (as far as I can tell)Congratulations to LiveCode for finally recognizing and adopting one of Xojo’s long held strengths.
Are they really?the benefits and advantages
No. It's an engine update and will be a available to everyone as a replacement for the current engine. You will also be able to turn off the final compiling step if you prefer to keep the current behavior.richmond62 wrote: ↑Wed Mar 16, 2022 12:31 pmit is NOT (as far as I can tell)
going to be rolled into the standard package, but an add-on with a kicker (more money) . . .
You chose that as your first post here?
While we're raising the cup of disingenuous kudos, congrats to Xojo for finally recognizing more than a decade too late that Android is the most popular OS on the planet.Congratulations to LiveCode for finally recognizing and adopting one of Xojo’s long held strengths.