Which logical fallacy is it when you use Chat GPT to write insipid posts? 
2 Likes
Nothing in any post in this thread implies anything of the sort. You are assuming facts not in evidence.
1 Like
Since menus appear as a result of user action, typically a mouse click in the menu bar or a right-click to generate a contextual menu, seems to me the best approach is simply not to generate the menu/menuitem when it shouldn’t be there, rather than just setting it to invisible.
I found one place in my code where I was setting a menuitem to invisible, and indeed it appeared not to work under Windows, so I’m altering my code to not generate it rather than generating it and then setting it to invisible. Which is a better approach all round.
What this particular situation needs is a clear statement from someone who knows, as to whether what @Arnaud_N suggests here:
is actually the case.
Yes, I have done this (more than a few times) in the past. That’s not a positive takeaway, in my opinion. It’s an indictment that the bug tracking system isn’t a reliable way to get a bug fixed in a timely manner. We shouldn’t have to leverage our personal connections inside the company to get anything fixed.
2 Likes
There is no objective way to measure because choosing a development tool is extremely subjective. The tool needs to have the functionality that you care about. It needs to be reliable enough for you in the ways that you use it. If it’s entirely unsuitable for someone else, that’s irrelevant for you.
the fact is that the more resources are dedicated to add functionalities the less there are for bug fixing.
More functionalities → more bugs
More functionalities → more new customers
More bugs → less license renewals
and the end very bad quality checks.
Common menu items worked perfectly on Realbasic… and then I read from people that’s a problem of MS Windows OS that can’t handle this?
Just to say, I very much care if Xojo is unsuitable for others, and I think that’s all of our business. Not merely because I rely on those others buying my products, or because it’s part of being an MVP, but because I want Xojo to succeed in the long-term. There will always be use cases where Xojo isn’t the right tool, but I’m a bit taken aback by this sentiment that others’ bad experiences shouldn’t matter to anyone else, and hope that’s not what you really meant to say. Can you please clarify the intent?
5 Likes
I had planned to download the bug base and do some statistical analysis to demonstrate the value of this data. My original idea was to look at the CSV file available from tracker.xojo.com, focusing on column M (“Created At (UTC)”) and column O (“Closed At (UTC)”). By filtering out anything labeled as “Feature Request” and focusing on “Bug” in column R (“Labels”), it would be straightforward to analyze trends month by month, a draw a pretty graph to show:
• The number of new bugs
• The number of open bugs
• The average age of open bugs
You’ve mentioned that you don’t think it can be boiled down to a single number, but surely these trends would be good to know. (I’m not trying to measure something as amorphous as "success " what I’m trying to measure here is is the bug problem getting better or worse.)
But there is one problem.
Did you turn off the ability to download the bugs ? It was there yesterday.
EDIT WAIT I might have found it.
I have found it.
Pretty graph to follow.
1 Like
As you pointed out, no tool is ideal for everyone. It is a very rare case that we come across a potential user who tells us that Xojo is not appropriate for their needs. If someone came to me saying that they wanted to create a first-person 3D shooter game and asked if Xojo was the best way to do that, I would say it is not. So while Xojo will be appropriate for nearly anyone, there will be people with needs that Xojo wasn’t designed to meet. What each user ultimately cares about is whether or not it meets their individual needs. You are in a special circumstance different from that of the typical user because you sell Xojo add-ons. But again it’s rare that we find a user that tries Xojo and determines it won’t meet their needs.
1 Like
I disagree. I can remove myself from my own needs as third-party developer, and consider what’s best for Xojo and the community without my own bias. Additionally, the response isn’t in the context of the discussion. It’s understandable that Xojo isn’t built for high-performance 3D graphics, but we’re talking about bugs. Your response to which I replied seems to say that we shouldn’t care if users run in to bugs that they can’t workaround or become so frustrated with that process that they decide to abandon Xojo altogether.
5 Likes
My guess is that Geoff was not talking about bugs important to someone else, where the bugs makes the product ‘entirely unsuitable’.
I think there are many more than expected. But they have the numbers that matter:
So you have an almost 100% Trial download to using/buying conversion? That is just ridiculous. People really do not try Xojo, find it unfit and tell you about it. They just don’t use it and move on to a product that meets their needs. But back to the bug issue…
Can one determine anything from the length or tone of this thread?
That is not what I’m saying. When prospects choose not to purchase, it’s rare that it they choose not to because it can’t do something they need it to do. They have other some other reason.
Like a reputation for not being serious about bugs?
This thread is not helpful, just seems to make a lot of negative assumptions to stirr up people’s frustrations. Has posting this kind of data and rough assumptions in a public forum helped many people?
Even if you had good intentions I don’t see how any of this is more actionable than a post that says “Xojo is very buggy IMO!!”
4 Likes
Yes, we can. That ideally each user would prefer to never run into any bugs and that Xojo have every feature they need at the time they need it. I’m a user as well. I occasionally need something we don’t yet have built-in or a bug. Even if I ask an engineer to fix the bug, I still have to wait for that bug to appear in a release. I’m not going to waste their time making special builds for me.
For some I don’t even think it’s a question of having run into a bug but the concern that they will. That’s just life as a developer. The experienced developers know this. They know that if they run into something they will find a workaround and move on. If you are looking for a development tool that is so reliable that you so rarely run into bugs that you can’t even remember the last time you did, best of luck finding it. As I said in the blog post, Xojo, like many development tools, is large, internally complex and thus has a huge surface to cover. To reach the nearly bug free level, we’d either have to charge significantly more (thousands of dollars instead of hundreds while not losing users due to the higher cost) for it to have the resources to hire the engineers to make that happen or dramatically reduce the surface area by only supporting a small subset of what it can do now. I don’t think there are many that want either of those things.
This subject comes up every once in a while and we have the same discussion about it each time. While we are constantly looking for ways to improve, that doesn’t mean what we do is always going to match up with what each and every user would do if they were making the decisions. This is why reaching 100% customer satisfaction is like trying to travel at the speed of light. The more you attempt to reach the goal, the more energy it requires to move forward.
2 Likes
We don’t have that reputation. If we did, we would be out of business. We have been making Xojo for over a quarter of a century now. We are not perfect. Far from it. But we have outlasted most other development tools. Consider what was around in 1998 and you will find that many are no longer here. That is telling.
The most productive developers recognize that occasionally they will run into a bug that they have to work around. We do regularly and not necessarily in Xojo. We run into bugs in the various operating systems we support and we have to workaround them. That’s simply par for the course. We can keep working to make it better while knowing we will never get to 100% and that’s ok because we are still making progress.
5 Likes
You are absolutely correct.
I have asked that they implement some sort of KPI to track the number, life span of bugs. I was told that numbers are of no value.
You cant help those who don’t think they have a problem and don’t care to look at the data .
2 Likes
Agreed.