yes, like solving the flickering on Windows
It was such an enormous change that it really needed that time
It wasnt “oh swap this Carbon function call for this Cocoa one”
Lots of reinventing the world to make things as “the same as always”
BUT it was a public beta if you recall
It was optional to use & test but a lot more people did so
It got a lot of testing in real projects before it was moved to as “the default” type of build
2 Likes
Yes, I don’t doubt about it. I mostly remember a lot of users not understanding it took that long, anyway (but they were possibly mistaken).
Right. Android isn’t really public, but anyone can try if they have a licence. And both take time, too. But complaints are always there.
THIS is exactly the question everyone should be asking
Does Desktopxxxxx controls “improve” things ? Or just shuffle deck chairs ?
Its annoying as hell to type DE and hit tab and OMG the list of stuff to wade through !!
Now I need to start naming my things in a way that WONT do this just to avoid autocomplete hell
API 2 ?
If you read release notes they’re fixing new bugs in all this new stuff that didnt exist or had been fixed in the things they replaced.
That to me sounds like deck chair shuffling
Do we have new language capabilities ? no ! Dont get me started on VAR and what a waste of time that was 
The String module actually makes it so you CANT do some things without more variables and MORE code
How does that help me ?
TBH I cannot name anything that has been added in recent years that is of significant value
1 Like
I’m sure glad Cocoa didnt take anywhere near the amount of time Android has
Xojo would have died if it had as no one would have been able to produce apps that ran on macOS
Fortunately Android ISNT quite so critical to their “success”
2 Likes
Exactly and that was the reason by so many were perhaps disappointed how long it took, but understood why and finally were happy to that Xojo made it possible. At that time they used the same slogan than today (“it is ready when it’s ready”) but I remember those days as having been far more transparent from the Inc.
I think one of the best things about that public beta was that as each release came out everyone who built Mac apps could see the progress
Not JUST the testers group
1 Like
adding issues (the tracker tool) was a positive move. Adding “issues” to Xojo not so much.
1 Like
Oh I meant in the tool itself
Moving to issues and away from feedback is a good thing™
Something I’d advocated for way back when
I didnt think it made sense to write our own and devote the time & effort to that instead of using something off the self and using all our efforts for the product we sold & made our livings from
Oh well
But then the DID move their docs to the new system - a step backwards I’d say
So literally one step forward one step back
1 Like
That’s something I never understood either. Why limiting the beta to a few testers?
Xojo is playing the card that the test release (aka pre-alphas) are kind of a pre-release, something like release candidates and valued users can be happy to adapt all the new shiny features ASAP. Please say thank you to us.
Though in reality it means: here is something, please test it for us, but stay humble and nice, as we don’t want to hear too much criticism. If you take the testing role seriously it is real work for everyone and most certainly extra work and lost time, as things usually still change dramatically.
Too many voices a to listen to ?
They got a HUGE pushback in beta testing over a couple issues and VOILA ! MVP’s so we only have a handful of people to “listen” to instead of all those whiny testers
YES they will tell you I’m full of shit on this but the timing was very clearly that way and appeared to be a direct response to hundreds of people bashing them and the messed up idea (I believe it was the first iterations of API 2)
So they stopped listening
Indeed
Cocoa, as a public beta, got LOTS of feedback and was actually altered based on that feedback
Sometimes in significant ways
That was a good thing as it got beat up and tested and tried in ways that a much smaller group might never have done
Current betas dont seem to benefit from that
I suspect downloads even for 2023r1 are a tiny fraction of their entire user base
But, heck, I’d test IF they’d just mark my account silenced so I can post but CAN actually log in and get to the testers channels
But even asking nicely they wont
Can you ever have too much feedback? Probably not. Will you get some weird feedback, trouble maker’s feedback, insane feedback? Sure, you’ll. But this applies to any developer and you have to deal with it, filter it and comment on it.
Alacritty is good an example, a rust terminal app. Tons of people asking for it to be a 1:1 iTerm2 replacement. But the main author was clear on it from day one: it won’t happen, it was never the purpose of alacritty etc.
Some people jumped off the wagon, the others quickly understood that the author is serious about it. THAT’s moderation, expectation management, transparency … ultimately a clear roadmap.
From a “citizen developer” standpoint, PDF support and now charts… but they should have been done a decade ago at least… but since I bought plugins to do those things , they don’t add value for me…
Updated graphics commands may fall into the category of significant as well.
-Karen
1 Like
“Manageable” 
- To act as an informal advisory committee. As we develop Xojo, we appreciate getting feedback in the early stages of a particular change we might be making, which is manageable with a small group. We are discussing our product planning with them and giving them very early access to features in development to get their feedback.
From: Xojo: Xojo MVP Program
Apparently yes ???
In part I think this is where Xojo falters
Expectation management
We cater to pros !
Then do things LOTS tell them NOT to because it will hurt them
And dont do things they do ask for
We cater to newbies
Then add things that make being a newbie harder (API 2 + Desktop prefixed controls) so none of the existing google searches will turn u useful code ? And move the docs to a less searchable and less indexable form so google will prefer to NOT show the brand new docs
Makes no sense to me as neither of those claims appear to be true
1 Like
Maybe if they didnt just change the syntax for existing things
They’re the API 2 variants of API 1 items
With all new bugs
Ah yes they did add those albeit with some pretty decent limitations
And bugs
Enough that I’ve not used them and just stick with plugins
But yes there are things that have been added
There ya go
We cant listen to everybody so we picked < 10 people
so the range of experience, usage, etc is incredibly limited
Well spotted, you are right. I forgot about those for 2 reasons:
- Not using Xojo actively any loinger
- Big disappointment for me living in Europe. Both not ready in the first release to deal with non US characters, different decimal point annotations etc.
and 2) is back to expectation management (@npalardy). No one can tell me that the Inc didn’t know about that, so why not telling clearly (even testers): only ready for the US market at the moment. I mean even Apple does this very often. Apple News doesn’t exist over here for year now. Same for so many features, which are rolled out only a later date to the outside of the US. Granted, Apple usually has better explanations and reasons than Xojo 
I for instance looked at pdf as a tester, but it took me a while to test with oüöéè etc. It is hard to believe that no one thought of this …
1 Like
yes, especially a they are not shy at all to raise expectations. Either I’m blind, deaf or dumb but I remember GP telling us: there will be a migration path to web2, web2 will have login / right management tools, etc.
Well on the latter he was right: just develop it on your own
On API2: all language changes are always debatable. I think many things do make sense in regards of aligning the language etc. At least I have encountered many changes in other languages too. Often additions which didn’t make sense to me, at least not at the beginning. But breaking changes (like Xojo implements them) happen very rarely and are announced clearly ahead of time. Swift for instance made some dramatic changes in their first release, but they did their utmost to help everyone with the migration. Dramatic change like 1- or 0-based index should ideally be customisable in the IDE for your projects for many releases to come.
Of course Xojo is right that no one is forced to use their newest release, but they forget that this statement is wrong for those who want to see some bugs solved. Plus (and that bothered me the most) other tools won’t force you to maintain x different flavors of their app, including different versions of plugins. At the end of my Xojo career, I had 20 different versions of Xojo / plugin bundles installed … that’s insane.
Not managing expectations IS a problem
The new pdf stuff is one - when anyone outside the USA tries to use it there are issues - esp if you need non-english character sets
Date formatting and money formatting and many other things that should just work dont outside the USA and its locale
There are far too many of those “oops we didnt think about …” kinds of issues esp outside the USA
Yes - unfortunately it ends up too often being over promise under deliver instead of under promise over deliver
Have to admit that this went on while I was there as well
The dev team DID try to reign this in with varying degrees of success
API 2 is exactly 0 “language” changes - VAR is at best the ONE actual language change
Its entirely FRAMEWORK changes - and they could have made that optional
We did that with the Xojo framework which still exists but is slowly being deprecated in favour of taking over more and more in the global namespace with every new change 
And their IDE’s DO, most often, assist you in updating
Oh gawd are we talking “option base 1” from VB ?
That was hell
Indeed - you can see in survey results there ARE people who use old versions and only build with new ones for almost EXACTLY this reason
Version management IS an issue with Xojo unlike many other tools