[quote=483405:@Dave S]So for those of you wishing to support Xojo in this at any cost… to you I wish good luck
For the rest that will be cutting back, remaining with 2019r1.1 or leaving completely… to you I wish good luck[/quote]
Actually my shipping code is still based on 2019R1 and likely will be for awhile yet. And it could be that I will never ship anything using a release from my annual subscription that came after 2019R1 and before 2020Rx. But that is not to say I should regret the interim subscription. We’re not talking a company with deep pockets from other resources.
Mine isn’t either – I’m an independent programmer whose client base is COMPLETELY shut down by this virus. My major income comes from sporting events which does not exactly have a good short term outlook. But long term I hope sports will again hold events, and long term I hope Xojo not only survives but thrives. If sporting events do not come back, then I won’t care as much about my existing Xojo code because my existing customers won’t either.
To me this is not Kool-Aid; it is a reality pill. Short term I am WAY more affected by this virus then by any delays in Xojo features.
[quote=483406:@Douglas Handy]
But again to their credit, they listened again and probably some of the delays we are seeing on other fronts reflect the time it takes to right a ship and stay the course. [/quote]
AFTER they’d been told repeatedly during beta that releasing 2019r2, as it was, would be a disaster
AFTER they shipped it and got exactly the same feedback from a much wider audience than what they had had during beta
They eventually shipped 2019r2.1 with the event renames removed
And they removed 2019r2 from distribution
This is - to my knowledge - the FIRST time this has ever occurred
That says something
And now we’re not having “beta” any more - just build
It stretches credulity to think that the revolt (?) during the 2019 beta cycle and this change arent related
I guess we’ll see how this pans out
Some are hedging their bets by also looking at other tools and figuring out an “exit strategy” if such a thing can be said to exist when moving from one code base to another
As I said in beta, Xojo should have 2 operational preferences in the settings, legacy (api1), modern (api2), so the autocomplete of “new shine things”, and new components, would be enabled only if in modern mode, to offer people an incentive to migrate. In Modern mode, an autocomplete magic of api2 with api2 help and its events; in legacy, pure api autocomplete of api1 with ap1 help and api1 events. This will take a bit of work to implement but will be frozen for ages, as api1 is frozen. An api1 conversion tool should exist to try to help people to migrate. In fact, if using the api2 mode, when loading an api1 code, a warning and an auto conversion (saving into another folder) should start. That means things like having 2 plugin folders, plugin and plugin_legacy, loaded when switching modes. Why not just to use 2019r1.1 that is pure ap1? Because bugs. Many correct later in the common core and framework.
As a hobbyist, my opinion can be discounted as such, but I’m very happy with new changes. It is taking me some time to get used to the new syntax, but I’m getting there. Nothing is perfect. Over the years, I’ve constantly had to change my code to suit changes in Valentina, Xojo, Windows and Mac OS, and, most importantly, my own stupid mistakes due to sloppiness and/or ignorance.
It’s no big surprise that some are unhappy to the point of leaving. That’s been going on since I’ve been using RealBasic twenty years ago. Evidently, more people are coming in than leaving. I hope that continues, but it is out of my control. YMMV.
I meant, new projects, started using a new incompatible syntax and code is not a problem. The purpose of my ignored request, of maintaining an legacy compatibility mode, was just to keep the support of legacy code. Code that can be compound of thousands of LOCs people can’t risk touching without spending months of rewriting. Time that many can’t afford anytime soon. API2 has upset people whose products became impossible to maintain using a broken IDE/compiler whose later fixes they can’t get to fix problems the old compilers/frameworks introduced in their products.
First thought that came to my mind when Xojo announced its PDF class, that they bought your gPDF code
As a customer of gPDF… I completely support your decision Dave and understand the pros and cons in your decision. I have always enjoyed reading your threads over the years and truly want to thank you for being an extremely helpful Realbasic / Xojo contributor to the community.
I do hope that you will continue to post here as a lot of your feedback to threads has been very helpful in my own code troubleshooting.
Thanks Rich… I appreciate the comments… and sigh, No… nobody from Xojo ever even acknowledged that gPDF existed.
But if the syntax/concept is similar, I will be pissed of course… but it won’t be the first time a software company would have stolen a design concept I created. SAS Institue did it back in the late 80’s. They had a forms creation app, but no way to create documentation without tedious screen prints… and since I worked in the Aerospace Industry at the time, documentation was required for everything. So I reverse engineered their storage format, and wrote a documenter (similar in fact to XJPrint for Xojo). They did give me credit in the next edition of the Users Manual, and a year or so later, the next release had built in documents… imagine that.
you send the announcement to dana she posts it
not quite “acknowledgement” in the same vein as getting a note from geoff saying “hey great I see you made this really cool thing for Xojo!”
