Who should write about that crap? Nobody. Look how often a programming language is mentioned and you can get how active it is in use. So simple. Nobody writes about? While nobody cares. So simple. And Xojo has no real chance. It is an old language structure, it has many problems, it has a bad update structure. For me: only to look on projects of customers. At least being fair: they had never a real chance without investing much more money in devrlopment, QA and marketing. So this ends up.
Strout or Ranieri?
Ranieri
I never worked there with Joe Strout
He had departed by the time I joined
2 Likes
I have been an RB/Xojo customer since day one. Geoff even mentioned that, when I met him at the Xojo conference (their last one) in Nashville. But I intend to let my Pro license lapse when it ends in January. The Pro benefits are few now (consulting leads are now next to nil.) Also, my focus has always been desktop; I’ve only played with iOS and web. The savings to me will be a car payment.
Perhaps I’ll pick up a Desktop license later, during a sale–when I find something compelling in an update. Most recently, I was happy to get preemptive threads (welcome to the 1990s.) 
3 Likes
Have there been any recently ?
Last one I was aware of was in early Feb this year and none since
Yeah they’re usable IF you dont push too hard but I’ve blown up a clients app badly with them and I like to think I know what I’m doing there. I’ve written plenty of preemptive code in my lifetime but still managed to crash hard. And because of the nature of preemptive code it’s almost impossible to reproduce so there is no way to report it in a way Xojo could do anything.
Most recently I actually opted for a Worker that I start when the app starts that perpetually does a bit of work and notifies the main app when its found anything of interest.
It runs all the time. Thats worked quite well so far and Is a decent use case for a worker.
A preemptive thread was my first thought but I switched after several trials that all managed to crash the app in one way or another.
Does really anybody believe that they will get to the point that all showstoppers are away? No. I guess not. Why should they. For them it is good when and if more than 95% of the users are statisfied. Why should they even pump money in this product to fix all of this bugs?
And again: no product is bug free. They can’t get rid of theese Bugs. Never. Not in this universe. And others also not.
It is a poor sign for them that even the threading is not what it promises to be. Comparing to Java threading or C# threading it is nothing. Should be better and I am sure there are better ways to do this. But in this case people thinking that they can sell liker they want to.
In my case there is no problem to stay without any support. I need Xojo only to rewrite older Xojo apoplications so the logic behind is simple to read for me. New projects: will not be happened. Why? While they are not even thinking for one seconf what’s with the pro developers. You could see this already with the Web 1 to Web 2 upgrade. And the API 2 … there is no way to be in. Only to leave.
1 Like
Looks like ‘Xojo Bot’ is working hard adding the ‘Needs Review’ to old and not so old cases (2 years or more).
Not sure about the logic on this, they can’t review that many cases before they are 2 years old and Xojo bot add the ‘Needs Review’ again.
Either way appropriately staffed is very suspect
If the bot takes 2 years to put the needs review flag back on and they havent looked at it in 2 years is there any point to the report ?
2 Likes
I’m seeing this like they were overflown by old reports and they told the bot to remind of reports that are two years old, to trigger an alert to review them periodically.
Still if its 2 years old and NOT reviewed ?
If its 2 years old and not even been looked at it might as well be closed as “unactionable”
Otherwise they just clog the system
Staff has 200 workdays. On one workday he could solve one bug if it not too complex. Would mean: if you have a staff only doing this. They have staafs that are doing this from time to time. This is the result.
Yes, I’m not saying they do it right, or in an expected way. Just that, since keeping reports open for more than 10 years is an habit they took, possibly one way they try to cope with that now is to review each bug every two years. 
Feature request should have an almost unlimited lifetime
but after a while bug reports go “stale” since the state of the framework, compiler, IDE has probably changed enough that if it wasnt review, verified & a means to reproduce it found within a short time it gets to be pointless
Bug reports from 2019 are probably useless today
Esp since Xojo flat out tells us to try in the latest version to see if its already fixed
So they probably shouldnt live much beyond a year or 2 before just being closed as a status that indicates very clearly it was never verified and might need to be resubmitted (which will piss a lot of people off I’m sure)
That their staffing cant keep up is indicative of two things in my mind ( and this was a true today as it was when I worked there)
- there isnt sufficient staff to handle the incoming reports
- there isnt sufficient staff to fix the incoming bugs
- there isnt a culture of creating fewer bugs so the flood of reports goes DOWN not stays flat or goes up
Although we did get better at #3 when Joe Greg & I worked there it was never perfect.
But trying to limit the # that got into the wild was our PERSONAL goal. Not a corporate one & not one that was enforced beyond our personal commitment to it.
And that still seems to be the state of things
1 Like
I’d say this list
(needs review not a feature request ordered in reverse date created)
should just be closed
They’re never going to look at them now (some are 5 years old) and its way too late to look at them as so much has changed in 5 years
Again they’re NOT looking at them when they are current
And that is the issue
Always has been
1 Like
IN yet another punch yourself in the face moment just read the replies to these cases
https://tracker.xojo.com/xojoinc/xojo/-/issues/79228
TL;DR
person finds that with new beta a build of the SAME app is more than 2x as large on disk
The reply ? Dismissive of the concerns
That the app is now, when unzipped & uncompressed, more than 2x as large
So a new request is put in to ONLY use these huge aggressively compiled frameworks when aggressive compilation is used
https://tracker.xojo.com/xojoinc/xojo/-/issues/79266
And this is once again dismissed
The just DONT listen, or care, about what their users are telling them
And dismiss them
2 Likes
Compress Size is unimportant except for bandwidth required to DL it… it takes up >2X the space when it is all said and done (not sure where Travis came up with the OP saying 3x)
What Xojo REALLY needs to do (in addtion to everything else they should be doing), is to make the framework a shared file system, and NOT embed it in every app, that could save Mega if not Tera bytes on most end-users systems… but that will never happen
1 Like
yeah theres no way they can share a single one across many different versions of xojo
so an app would initially have to
- check to see if the framework for the version its compiled with is present
- if it is do nothing
- if not install the shared framework for the version it was compiled with
for a single app from a single version of Xojo no savings
IF you had several then it could start to add up
for me, moot point, since any compile Xojo apps I still have are old, but useful, and few
Agreed
I was just surprised by the totally dismissive reply given by Travis
Might as well have given the “We know better than you do what you want” type reply
1 Like