I have to stop hanging out in the TOF

Xojo
1

WARNING RANT

In recent days, participating in TOF has become incredibly infuriating for me.

There’s the post about the HTMLViewer and the App Sandbox, you’ll see that the solution which I took the time to figure out, write about and share, doesn’t work in the DesktopControls dumbness.

What makes it worse, is the reason I created the solution in the first place. Is because the feedback I filed to get Xojo to use this API (you know so it can work) was ignored in favor of self-sabotage and by now has probably been auto-closed, because it only “affects a small number of users” and is over 2 years old.

I then see someone else trying to use code I shared to center a window, but failing because they too are using DesktopControls.

I realized that getting angry over things like this isn’t worth my time. It only hurts me. Xojo have made it abundantly clear that if you don’t like API 2.0 / DesktopControls, there’s the door. I really must listen and let go of the pain and frustration that’s been caused by their actions over the last two years.

Sigh… Thanks for providing a place where I can say things like this and not be insta-branded as a Troll and banned, I’m going to start self medicating by removing myself from what’s causing me pain.

Addendum:
As several people have asked, I have no intention of abandoning App Wrapper at this moment. if I am forced to change (it is not an update) to DesktopControls, I will assess how worth the time is versus sales at that point.
I will be withdrawing the Ohanaware App Kit and some of the other solutions I’ve created for Xojo that are not compatible with DesktopControls.

3 Likes
2

TBH I’m surprised that the declares etc DONT work since the DesktopControls are 99.9% the same underlying controls as the old controls they just have some marginally different names etc

In fact I’d hazard a guess that with a decent debugger (like Xcode’s) you could determine that DesktopHTMLViewer actually calls in to the same underlying Obj-C code that HTMLViewer does

I know a German guy that could probably tell you If that true :slight_smile:

But - that said- I hear your frustration
It IS, or was, one of the reason INN was originally founded
And, over time, its proven to be the only place you can vent like this and NOT get banned

2 Likes
3

With the not get banned I would be carefully since somebody from the Team told me that I will not get Access to Testers forum cause of the stuffs I wrote here and in INN discord. I don’t know if that was true while it was an MVP telling me this but still it is a risk. They ARE getting what is going on on INN definitely.

4

I think that is what it comes down to is, as you say, your sales vs the effort to rewrite for API 2. API 2, love it or hate it, is water over the dam at this point so it’s pointless to wear yourself down over it. Other app / tool vendors are supporting it. New users are coming on board with nothing but desktop controls in their apps – I’m one of them. I’m still on the fence how much and for what I’ll be using Xojo for long-term, but I am certainly a potential future customer if you move the product forward. If there’s money to be made, don’t cut off your nose to spite your face. If not … no one can legitimately fault you for taking your business elsewhere if you determine that’s best for you.

1 Like
5

Unfortunately, unlike the Xojo name spaced API (which they did back off from because of complaints), I think you are right…

Those of us with 20ish years of using the product are the ones most affected by the change, but I’m sure long term users are only a tiny percentage of the user base …

Outside of a small core group, there always seemed to be significant churn. API 2 seemed to significantly eat into that long term core.

-Karen

1 Like
6

In part I got banned for things said OUTSIDE TOF :frowning:

As the Xojo community is meant to be a resource for Xojo users to receive help, share tips, and communicate in a reasonable and professional manner, intentionally inflammatory comments (trolling) or users who are an overwhelmingly negative influence in the community will be suspended.

A rule that appears to have disappeared from their guidelines (I dont believe it ever did but …)

2 Likes
7

There is no need for. Speaking truths was right enough. They have released Web 12 without any care of their customers with Web 1 applications. And soon later they say: see how old Web 1 is. We can’t do any fixes on it. That was in the beginning what I always over and over said sitting on a ready for shipment application with a deprecated programming language behind.

1 Like
8

This was not a decision that I have taken lightly. I’ve been thinking about this since it became clear that DesktopControls was coming, regardless if we the customers, liked 'em or not.

The main problem with Xojo source code (which is what OAK is) is that I need to maintain two copies. Xojo did add a function to help with some of the conversion, but it didn’t handle everything it should. I reported this and waited.

OAK is used in all my applications, which helps it continually grow and improve. None of these improvements would make it to DesktopControl poop, unless I duplicate and convert each and every single change I make, so DesktopControl functions would fall out of sync pretty quickly.

I waited and lobbied for Xojo to add old feature requests which would dramatically improve this and thus allow me to continue developing OAK, while supporting both… Glad I didn’t hold my breath.

The biggest set-back came when OAK lost it’s spot in the Omegabundle to the “plugin guy”. OAK was made public because the “Plugin guy” didn’t want to participate in the bundle anymore, and while OAK was in the bundle, it was worth it. If OAK was to retain its place, the transition may have been worth it. Without it, it is a lot of work for a handful of sales.

OAK simply wasn’t popular enough to stand on its own, maybe I am not as good as I thought I was, or maybe the market isn’t big enough for both the “Plugin guy” and little ole me?

In this instance however my complaint is because there is a problem with the Xojo framework, which they don’t think is worth addressing. I did it for them and provided the solution to help their customers.
Instead of Xojo fixing the problem, they created new ones, breaking this solution.
Now a customer is facing this problem and the solution I devised doesn’t work, I should help the customer as it’s in my nature. However in doing so, I actually become part of the problem, because I enable Xojo to ignore customers and to not fix their problems.

I want Xojo to improve, I want them to focus on their customers and making spectacular apps, I’ve filed feedbacks, I’ve lobbied, I’ve talked to the CEO via Zoom. I’ve now accepted they’re gonna do whatever they feel like, I am not important to them and the only person I hurt by trying to to be heard, is me.

So I have to stop. Maybe, just maybe, by not solving this problem for them, Xojo will step up and fix it, or maybe they won’t and it’ll be another customer they lose in frustration.

1 Like
9

IMO it’s market size, and i know for me (and I expect many others) I was primarily interested in Xplatform stuff and yours tended to be Mac only.

That said my own experience in trying to sell into the Xojo market overall was not financially worth while, even though it was X-Platform (Mac, Win) and no one else was providing the main feature I was …

But it was a niche need (my mergable Cell Listbox), the documentation could have been a lot better, code nicer, and outside of an occasional post on the mailing lists or forum ( I did not want to keep injecting myself into every listbox thread) I did not do any marketing beyond announcements to speak of.

In any case as i originally wrote it for myself, and as I have stayed on API 1, it made no sense to put the work in to convert it to API 2. which is why I open sourced it.

-Karen

2 Likes
10

It’s really hard to move on from Xojo. Takes a lot of effort and time which seems wasteful.

However, on the other side of that effort things are so much better.

I’ve never had to call tech support using FileMaker, 4D, etc. But with Xojo, I HAD to contact support due to bugs and not knowing if I was doing something wrong or if it was a bug. Got to the point where I assumed it was a Xojo bug whenever I had an issue.

But now I’ve recreated what I need in php and haven’t encountered a php bug yet. It’s nice to know that bugs I find are likely my own bugs. :slight_smile:

I’m still upset the Geoff cannot get a handle on Xojo bugs, decided to rename things, tossed Web 1.0 in the trash, using a bot to hide bugs, and then went onto label me and others as trolls / toxic.

Rather than fix the problem, Geoff chose to blame others.

1 Like
11

re: “It’s nice to know that bugs I find are likely my own”: Yeah that is what I grew used to with .NET but I just don’t like the UI-facing part of things as a way of working. Writing temperamental HTML or XML / XAML to constantly shifting standards / namespaces is my idea of death by slow torture. Balkanized mix-and-match frameworks and libraries with wobbly backward-compatibility shims and the need to deal with accumulated “lint” every couple of years by rewriting to the purity of the latest API or standard. Over-engineering everywhere you look.

Then there’s the problem that if you take a random project in any corporation it’s likely to be mired in technical debt to the point that it’s 10, 15, even 20 years behind the times anyway.

Where, oh where is a vendor who isn’t trying to sell incomplete toolchains by pushing off gruntwork onto users? Xojo claims that but then you have the bugs and Xojo’s denialism around them. Plus it’s not a single solution for multiple targets; it is more for generic target types (desktop / mobile / web). In an ideal world I would want a project type that abstracts away platform differences to a great extent, and targeting web is no particular special case. Then there are Xojo’s limitations around parallelism and threading – an increasing concern in today’s multi-core world. The only other platform that is so hamstrung around true multitasking by its basic architecture that I know of is Python and its GIL. Python is always going to lag in terms of performance except as the glue for a bunch of C code, otherwise I’d be more into it. I rather like the language.

I’m probably asking for too much. The velocity of the marketplace is too great for even well-endowed vendors to provide comprehensive tooling, it seems. Plus a lot of developers know nothing else now but slinging various flavors / derivatives of XML, they think it’s normal and probably consider visual designers to be wimpy and limited – when they needn’t be if done right.

2 Likes
12

Java isn#t, QT isn’t, c++ isn’t.

13

Producing code in Xojo feels like riding the proverbial dead horse.

1 Like
14

Timely in regard to Xojos bugs…

https://twitter.com/NBCNews/status/1597179779085918210

2 Likes