Oh I doubt they’d do code conversion
That IS terribly hard
Do they convert anything from web 1.0 to web 2.0 though ? (I honestly have never tried this)
But the JSON object exposed using the new engine (JSONItem) is bugged and silently destroying data. The case seems fixed, but the r21r1 should be retreated just because of it (and more bugs, but this one is very serious because it causes silent corruption). Any release doing bad math, damaging in memory data or in some storage or database, should be immediately retreated, fixed and re-released.
2 Likes
I didn’t.
In fact, I don’t hear much complaining about Web 1 vs 2 except from you. Usually when there is a big upsetting change that will cause developers a bunch of harm, there are a flood of messages about it. It’s the only thing discussed on the official forum for a while. I don’t see that in this case. Sure, there was a lengthy thread about it over there, but you were the primary driver of that thread. So when you make such broad statements, you’re really hurting your argument because it’s just not true.
You’re bothered by this change. I get it. Your options are to adapt your projects, stick with an old version, or move on. You’ve made it clear which decision you’ve made.
They didn’t make this change on a whim. Not only has web development changed a TON in the 10 years since I wrote the initial version, they’ve taken a new direction for web edition. Rather than shield the user from web development, Web 2 seeks to embrace it. It’s not the direction I would have taken it, but it is what it is. So they had to break things. They try VERY hard not to break things. URLConnection.SendingProgressed parameters are named wrong and will probably never be fixed because it’ll break code. Side note, this demonstrates the farce of API2: there will always be issues like this take an API imperfect.
Back to my original point… you need to move on. It didn’t work out the way you intended, but it’s not going to change. There is nothing gained in dwelling on it.
And don’t even try to argue that we don’t hear about this from other users because the official forum shuts down any negative opinion. I know their moderation has become more… marketing friendly… but they let dissenting opinions stay as long as they are civil AND their mods are not so fast that the public never sees the threads.
Now to go find my fireproof pants…
1 Like
First of all you don’t need fireproof pants! There is your point of view and I have mine and I have it while I am in the middle of a bigger group of people which are not the “forum writers” in which forum ever. Maybe it is stupid or it is not. But they have their fundamentals for it.
Secont: I moved on. I changed not only my entire toolchain from xojo to Java (Web with Cuba platform, Mobile with Gluon, Desktop and headless with Graalvm and a very few deployed as jar file while the platform is not vovered by gralvm but by openjdk vendor, all based on IntelliJ Idea IDE). So you can see: I moved on, changed the language and redeveloped the applications.
I am not alone bothered by this change. But many people do not want to write about while they tried to ssay something and where giving up much earlier. While Feedback Answers are also not really working and if then they are mostly long time ignored.
I have to see my customers cause I do an OEM PLM Business means that in most cases the Software, the Gui, the Firmware gets changed by the customers. So they also bought xojo licenses. They stop to buy and that’s it. But it is not so that it is okay how they where handling this issues. For example: changes are not plannable before deprecation. Compare it to Java or C++…!
So I don’t see that I am overdoing it.
To the question of another direction: there was not that much communication. The only one was: same futures and importing of API1.0 projects possible. What was coming out in the resulting Release 2020R1 was everything else than that.
If it would be foreseeable we would not in 2018 decide to use Xojo for the new project development and where not developing and certificating with FDA, Canadian and European authorities. We would immediately say: no, that’s not the way. But there was no sign that - within two years there will be this kind of deprecation.
And I would not say ONE word if there would be still the 2019R3.2 supported. But it was the other way around: even the documentation for 2019R3.2 was disappearing for the 2020 Release with the result that authorities where rejecting the allowness to use the language. The result was that all of us had lost years of development time. In my case three Man years of development in fulltime and the certification and the product tests and laboratory tests cause changing the software brings the electrical tests, emc tests, usability studies and much more. Only for information: one ems test for a 60601 medical device Class IIa or IIb costs between 15000 and 20000 Euro. We had five devices out at that moment, my customers even more.
So maybe you see that we are only a few but I see that we have a maximum effect from this politics and I see that every developer MUST know that he can not develop Software with xojo following to ISO 62304, ISO 9126, ISO 25010 and a few more while there is a break when a deprecation comes like this time. While deprecated compilers are not allowed at all for life cycle following to the standards.
And yes, it is a blaming fact that it could be handled different. Look for example how Cuba Project is managing that. With long time support after deprecation.
In that case I do not want to come to close to you but maybe you do not know that - between the developers which have no authority controlling their software - there are many developers which are under strength control of authorities like FDA, like Underwriters Laboratory only to list US ones. And we have it in all areas where risk based development for machines or devices is given per law, so for medical devices as well.
And I would not say one word if from the beginning at least the events would be there I need to write the Software completely. But there was nothing like that at all. The fallen functionality was and is much more than only the Styles and the changed event names and command names. For that I do not need an Importer. And if I could write by self. No. I needed functionality which was and is still not there.
So: I have to say you have done a real good Job. API2.0 with an from API1 isolated view on it is also a great Job. But if I would know that urgently needed functionality is not there I would not buy xojo from the beginning. I bought it while the functionality was there.
And everybody was immediately getting informed in which emergency condition I was. Via Mail, Via Feedback. Via Calls. Nothing was helping. So for me the only chance was to get in the situation that I will have a supported Web API1.0 or change. I changed.
So, why I am here? Because I believe that smaller companies than mine are in the risk to make the same error with a software vendor which is not taking care exactly about this questions. And again: If I would know in 2019 that in 2020 it would be deprecated I would have changed immediately.
So what shall I say: from your point of view you are right. But I am also from mine. The question is the userbase behind. Let’s speaking trues: there are not so many Device developers using xojo for their devices. You may have tons more citizen developers of professionals developing business software. I agree. But that can not be the argument to deprecate and not tell in front that there will be a complete loss of functionality.
My Ranting on TOF was fundemantaly coming up while I could not believe that this is really happened and they do it to me and my customers.
1 Like
Ah, one Addendum: I would not say that they delete something. Thats not how they handle it. I would not dare to lie. But I will say it so: I think that, under civilized people, we could say that you where and you are not in the position to begin a sentence with an implementation that I try to lie. I really don´ t like that kind of behavior.
What you said wasn’t a lie. At best it’s an exaggeration, at worst it’s just wrong. If you want to take personal offense to me calling you wrong, so be it.
I only wanted to be clear about the motivation, everything is okay. And Neither it is exaggeration, not its wrong. Show me please where you thing I am wrong.
I have to append:
Not correct is “All xojo users suffered” the correct would be: “the xojo users I know and I was speaking about that stuffs also I was complaining about where suffering from it.”
Otherwise it would be really not true and so: yes, you are right, I had to write more precise. Thank you for critics.
1 Like
I complained too but was threatened with a banning like @thorstenstueker
When Xojo hears dissent, they threaten, delete posts, lock threads, and ultimately ban people.
Like Thorsten, I’ve moved on but with PHP. Xojo will never see another dollar from me until they change their behavior. I’ve come to realize they just don’t care about quality.
2 Likes
When I read Rick (but other can write that too) bug “report” (newly discovered bug in a just released version), I am thinking: How testers do not discovers that prior release (at beta debug time) ?
OK, Xojo, wait a week or so in case some other major bug(s) emerges and issue a .1 version without these bugs.
AFAIK, Xojo already wait some days after finalizeing the version, before releasing it to let time to testers to discover these late breaking bug(s); usually Friday to Tuesday (this time the release wad on Wednesday.
At last, I am capable of doing bad things like that (and I’ve done that recently: made a change that proved to be buggy later, but for some reason) I do not tested it enough before building the application. I have to find time to search where n the code the bug is and revert to its previous way. Then, eventually, try to understand how to achieve what I wanted to achieve in the first attempt. It is in the ListBox and I do not await a change if it is not my bug (why my change does not works). I will revert to the previous behaviour instead.
I used the Web edition when it first came out… Yes the were limitation and bugs, but to me the biggest selling point was that I did not need to know web technologies to accomplish most things (and If it was needed I did not do it), and most of my RB knowledge and experience carried over.
The way things worked out at work back then web apps became impractical… Thing have changed recently in way that might make them practical again at work, but Web 2 design makes me not consider doing one.
I don’t understand the philosophy behind the product anymore… If cross platform (desktop OSes, Web and now mobile) citizen developers are a major target audience, we don’t have teh time to learn the specifics the the different platform APIs AND do our main jobs…
In some ways it seem they are a lot less concerned with abstracting X-Platform differences/details even on desktop than they once were… again a bigger negative for “Citizen” developers than Pros with deeper knowledge of the platforms.
Even simple things like the vertical slider thread on TOF. Good that they documented that on some Mac OS versions you need a declare to get a vertical sider, while on other MacOS and Windows (an I assume Linux) versions all on has to do is make the control height > Width…
Why not put that into the framework to make the behavior consistent X-Platform (and X- MacOS Version)?
The time wasted on the API 2 name changes could have been used for things that really matter like working harder on the details to take more of the friction out of X-Platform development - which is really their raison d’etre IMO.
-Karen
1 Like
Karen you are exactly meeting my points: they have no contact to the user base and try to make xojo more feature rich. Making Xojo web more for professional web developers wasn’t a good idea as far as I can see. But who knows why they decide so?
1 Like
In the team’s defense, the platforms are moving MUCH more rapidly these days. It used to be that the three desktop operating systems were the only targets, and those didn’t change much. This gave the team a lot of time to focus on improving the product. With macOS, iOS, and Android making annual changes, and web evolving almost daily, they are in a state of chasing compatibility.
There is a solution to this, but it’d cost them customers. It’s really a question of wether or not it’d bring in more customers to offset the loss: eat Electron’s lunch.
Getting to true cross platform development is something many tools can provide part of, but I’m not aware of any that cross the finish line. Electron cannot do mobile. React kind of does desktop. The list goes on. If Xojo were to give up on native controls, they could provide the same experience on all platforms from one set of code. They are uniquely positioned to make this a reality. They could truly be the cross platform tool.
They won’t do it. I understand why they won’t. But it’s a solution. Instead, they’ll spend their time just trying to maintain compatibility.
1 Like
Not many
There was a beta on the monday and the release was 2 days later on Wednesday
1 Like
If Xojo were to “give up native controls” that would be a mistake on two fronts.
- They lose the ability to look and feel like a “native” application
- They need to spend resources they have proven they don’t have, to replicate all those controls, and thereby introduce another set of failure points in an already fragile infrastructure.
What Xojo needs to do in my opinion, is give up on lost causes (iOS and Android), they are years behind in both of those, and the alternatives are FAR superior to anything Xojo could ever hope to accomplish. Focus on what they might be able to do well… pick Desktop and Web perhaps, or maybe if the market shows, drop Desktop or Web in preference to just one and do one thing well, instead of 1/2 dozen things badly.
Xojo touts having 425,000 licenses sold. But how many are truly active? How many are people like myself and others that have become so disenchanted that we have already moved onto other more powerful developement tools? How many were newbies that were excited to get a tool based on the sometimes misleading advertising, only to later discover it wasn’t what they were lead to believe?
How many of those have been left to languish in the dark recesses of a hard drive?
The success of a company is measured in multiple ways. Yes, one is new customers, but more important is customer retention… Something that by the very existance of THIS forum and the corresponding Discord site, prove that retention might be lacking
1 Like
Xojo still claims that you dont - but there are a TON of relatively simple things that you have to mess with CSS to achieve
Fixing long standing framework, IDE and compiler bugs would have, IMHO, been a much better use of the time
1 Like
This would suggest they need more people at the very least - possibly a couple PER target
You and I know thats not likely to happen
1 Like
Well, another stupid move, you have to PAY xojo a PRO license to have the honour of make free labour for them testing betas. And they will kick out any tester that do not have a valid PRO license.
It is, lets focus on the NEW features and changes to make a lot of promisses regardless of quality, lets have the product in a eternal apha near beta state and use the promisses to make users pay anually to have little improvements to the halfbaked features delivered.
Well, that is what a Framework is, and what all the other X-Plat try to do But… Xojo way
Company name changes, IDE change, New Framework, API 2, Back to the, make promisses, lets show something new and shiny to lure new clients (even if is just nonsense naming changes instead of functionality)
- 99% of end users DON’T even care if is a “native app” or not. Most of them will not even know what a “native app” is and many will not notice the difference with a close enought look and feel.
I could say that they already use GTK in linux and porting it to other platforms shol be relatively easy but… Looking at the crap work they do with the “new controls” yes, it will take YEARS for them to make a decent port.
1 Like
They kick out people who aggravate them
There are people on the Testers list that dont even have licenses any more
I know at least 2
1 Like
Correct, but they will never have the resources for that. As you said, it’ll never happen. That’s why I suggest a change in direction. After the initial investment, it would be much easier to maintain and they can make more efficient use of their staff size.
It’s absolutely an unpopular opinion. But something needs to change. Adding staff members isn’t a possibility. Getting the platform vendors to slow down isn’t a possibility. So something needs to change. I don’t know what else it could be.
1 Like