The benefit of having a real Roadmap

Another key to the success of this companies is that they have REAL roadmaps with actual release dates.


you mean like

oh look ways to get involved in planning even !

Would be good to see Xojo do something like those public discussions ahead of time instead of getting to BETA to “surprise everyone” with some new feature thats so far down the road the likelihood it could get altered/debated/fixed is effectively 0

< cough > API 2 … DESKTOP control renaming … < /cough >


Yes, the oposite of the “Maybe sometime in the uforeseable future but dont count on it” from xojo.

It actually surprises me the many times Xojo had said: yeah, it sucks but it is to late to change it.

actually for this where public discussions, many people said it wasnt going to work but (not for the lack of imput, but pure stupidity), they didt it anyway and had to retire a whole release LOL)

Cant understand why some people were so excited when they anouced the “new” controls when it was obvious that it was just the way to fulfill the foolishness.

1 Like

I’ve given up trying to guess at what motivates them to do the things they do since they seem immune to feedback from their user base

Unless of course its praise

1 Like

Roadmap is only a guide if you have real processes in place for software development. Xojo does not. It’s very much seat of the pants, let’s start down that road with our first idea and by golly, even if it’s a bad idea, we don’t have the time/patience/fortitude to change directions.

1 Like

I mean, Go debated for several years, before closing their loop variable ‘bug’. For more info on it see Fixing For Loops in Go 1.22 - The Go Programming Language. We don’t, and won’t, get anything like that with Xojo.

Go chose to remove some potential programmer errors at the cost of a little performance loss. Personally I am not sure that the change was necessary, it’s not that hard to make a copy of a loop variable.

1 Like


And here we go
More surprises! revealed in Germany
Copied from MBS Xojo Developer Conference: Thursday - Events - Xojo Programming Forum



This is much like workers which is frustrating as hell since what works in debug MAY NOT work at all in a build
Preemptive threads are hard enough
NOT being able to realistically debug them IN ACTUAL USE will be super shitty

This has been on the “coming soon list” for many many year
Since before I departed and that was 5 years ago


For a language that prides itself in being easy to learn and understand that change is absolutely a good idea. I mean, sure, the workaround is not hard but it should not have been needed in the first place. The only reason I learned about it was through a code review where I flagged the copied loop variable. My flag was wrong (and the explanation took me down the rabbit hole) and I got schooled by the architect on why it was correct but it’s not immediately obvious.

My point, is that the change involved hundreds (if not thousands) of comments from the community and the plusses and minuses of doing so. They thought carefully about it and added a new test so that existing code would at least be warned if it impacted them. Xojo does not think long and hard about changes. Doesn’t consider the impact to large existing projects. They write half assed implementations that don’t work like we’d expect and then spend years fixing said implementations.

1 Like

Threads - Swift has concurrency since years, Java has it since many more years…Xojo’s limping along well behind the crowd. Will be another eternal beta, like API2 and DBKit.

A shoutout to @MonkeybreadSoftware! Christian knows how to organise and run a conference! :+1:


Wow Xojo is getting closer to what VB had almost 30 years ago :clown_face:

The documentation sucks, cant trust an AI trained with that.

More half baked stuff just because is to hard to change the debugger for the current team?

Another BIG idea they had with no input from user. Kind of waiting the disappointment.


It’s all still vaporware until it ships. If it’s like other things, there will be no discussion about how the features will work before it’s baked in. Then it’ll ship and likely be half baked due to no dicussion.

Just like how API 2.0 had no discussion or conversion map before just “changing stuff”.

Nothing has changed. And nothing will get better until Geoff is no longer in charge.


Preemptive threading? Sounds like the 1990s have arrived. :slight_smile:


Multicore CPUs and Multithreading was more like a 2005 thing


yeah they’ve talked about this sine way before I started working there and the answer was ALWAYS “we need to make the entire framework thread safe” and that has always been such a huge undertaking that its just never happened

No idea what they think has changed enough to make it possible

For what I need I create a helper in Go, Rust, C#, Java or some language I can debug threads in and then just use Xojo as the UI

1 Like

Huh should tell that to my 1995 self writing Multithreaded code on Vaxes in PL/1 and other langs, or in Java on Suns

its been around WAY longer than what showed up in desktop OSes

Either way its been a LONG time coming and may still be :slight_smile:

1 Like

Clamoring for dear life.


Wherent those multi CPU instead of MultiCore? And in hardware not for consumer use?

some were multi cpu for sure