It’s the future - you heard it here first! 
Awhile back someone was trying to organize such a project… I decided not to participate both because I did not think I had the skills to contribute significantly, and thought the project was too big to be realistic , as besides the huge amount of initial work, the OSes these days are too much of a moving target as well to keep up for any length of time.
-Karen
1 Like
I know who … 
I did not want to mention his name, as I did not know if he wanted it known… Did it ever get off the ground at all?
[happily we can still edit our posts after 10 min]
I don’t think so. I too felt he overestimated my abilities.
I’m used to waiting on the future
I work with Xojo 
3 Likes
Hi there!
I’m new here, from France (so sorry for my sketchy english) and new to Xojo.
I’m a great Pascal fan, but settled to Xojo instead of Delphi because of this dogfooding thing, the price tag when you want to target linux also, and no web target.
During my search of alternative for multiplatform GUI I discovered something i consider a true gem: Elements compiler from RemObjects. Sadly there is no GUI designer there, but a truly impressive compiler alowing you to write in any of 5 languages (Object Pascal, Swift, Java, Go, C# and soon VB.net) and target .Net, cocoa, android, java, webassebly,and windows or android native!
They move fast and created an impressive and very fast IDE quickly, but sadly, no GUI builder for now: you can do GUI but using code and/or the designer from Visual Studio or XCode.
I’m seriously considering to buy an Element license, but need to find a few bucks to buy that and… some time to spend on that + Xojo. Had some talk on their forum, and they treat their clients in the exact opposite way Xojo does. They listen. They answer. Just that makes me want to purchase 
Anyway… don’t kwnow if this is interesting for you, but I had to say it, as way to bring something on the table, to thank you for this place where i’m already learning a lot.
Thanks a lot.
I’ve looked at it
It is interesting
But as you note no gui builder and having to use Xcode or VS limits things to those platform
the other thing I’m not clear on is whether I can be on a mac and build a windows and linux app - or whether I have to take the project & code to those platforms to build
I’m not deep enough into it to know
Buy the license when you really have something that you want to sell. That way you know whether the environment supports what you want to do - there is no point in buying a license, trying to create your app, and then running into limitations or bugs that make it impossible.
The other solution that I find interesting and will keep an eye on how it is developing is the programming language Dart with the Flutter framework (all free, backed by Google, mentioned further up):
But first I’m diving into Swift …
I agree on the limitations about doing GUI with Elements, but that’s another aproach. And maybe there’s hope
I have not tried cross-platform building but look:
As for flutter it’s also interesting, but the point remains: it’s not native, so roughly in the same league as Java or .net for me. It’s not a bad thing, but it’s different.
Ah I’m using Fire - their macOS IDE
The thing that makes me wonder is when I select new project there is a “shared” type that is specifically for other projects to reference - which makes me think any cross platform code goes in there and everything else is platform specific
Maybe I have that wrong but thats what it seems like when I start any other kind of project
They seem VERY platform specific
In fact they intend to be truly cross-platform, and not based on a common denominator or an abstract GUI framework. So yes AFAIK they want us to separate GUI and “operative” code, so we can build truly native GUI for each target… at the expense of doing it one by one.
At least for now, as their core product is the compiler.
But they already made two IDE using their own tool. Promising…
But I agree to your point: it’s not suitable for me either for now.
Now nobody is forgiven to try to build an abstract GUI designer (and framework) on top of that 
After all, with covid19 confinement we all have plenty of time 
yeah … for those of you for whom this “work from home” thing is new … welcome to my world
my work days are no more or less busy than they ever were
I havent been to town in 5 days
Bought gas for my truck at the self serve so didnt have to deal with anyone
Yes I kept my gloves on - it was cold
Except for my wife havent seen anyone else in … uh … nearly 13 days
For me this is “normal”
I thought that was JavaScript. I believe React is still being used a bit more than Flutter.
Welcome @Ormente. Your English is absolutely fine. No doubt far better than my French!
I really, really like the look of Elements and it does seem very robust. What it’s missing is, as @npalardy says, a GUI builder. Maybe I should build one?..
3 Likes
If you can then YES PLEASE!
1 Like
Yes!
Seems to be some interest in this.
I love messing around with the guts of tool and programming languages. I’m trying to write a bytecode interpreter for my own programming language that is a simplified OOP BASIC-like language for kids. The current implementation is an AST tree-walker that is too slow for most uses but if I can get the VM working I’m going to use it to teach my kids to code.
I had an idea last year, which I think would eventually solve a lot of problems. My explanation is long winded (I am sorry).
It starts with Xojo creating a whole new compiler, that supports primitive types and an OSObject.
Methods could be tagged as being platform specific (I know that we have pragmas, but having a single method for macOS code, one for Window and so I think it easier to debug).
This way the compiler could create a simple console “Hello World” app that’s mere k in size, instead of mb.
Everything else is then built in pure Xojo code, dumping the heavy XojoFramework. Keeping applications lean and fast.
Fast forward a few years, and the entire IDE is built with Xojo 2.0, all the objects that we interact with are included as source code in the Xojo library, when they’re needed the compiler compiles them (of course it would need some caching and such). Xojo could choose to share some of the custom controls it created for the IDE with the community, say the source list from the IDE. Everybody can now use it, we don’t have to spend the time making our own (if we want/need a source list).
Now I come along and find a bug in the Listbox or a feature that needs a few more options than what Xojo provided. I can take the object in the library and access the Xojo code, I fix the bug or improve that feature and use it in my project. I also submit it to Xojo.
Xojo receives that modified object, evaluates my changes, and approves my fix. They tidy up my code and roll it into their library (after testing it of course). They also credit me for the fix, either cash or a discount amount on my renewal. But they decide that my improvement is not something that they need/want so they choose not to include it.
I’ve now got an improved listbox, without having to rewrite or replicate the whole darn thing. So I’m happy, I also got paid for my bug fix. Xojo gets a bug fix for a reduced rate, so they’re happy. All active subscribers get the bug fix, so for those it affects, they’re happy.
But it’s not just me, it’s a dozen other or so developers who’re doing similar things. Xojo is still in control, but we as a community are improving our apps, and the Xojo tool (and being rewarded for it).
Xojo could even run competitions, $5,000 (per platform) for a video editing frame work that has to meet certain requirements, or contract hire it’s own users to add / improve / fix certain functionality.
I didn’t suggest this to Geoff, because this can only work if Xojo is rebuilt from the ground up, and it’s a lot of work to do so, so it’s a pipe dream.
Importantly Xojo is not open source, so the compiler and the IDE (and other options) are closed source still, but everything that’s used has the source code available in pure Xojo, so it can be modified by Xojo users, yet Xojo are still in control of the library as a whole.
Heck this whole workers thing could have been added a decade ago when we as a community started experimenting with helpers. They could already have it with shared memory as I (and I’m sure I am not alone) have written the Sandbox safe shared memory code.
Everybody wins, except the groundwork is huge and must be done by Xojo.