Chasing Xojo

The most important thing for developers is to have a reliable IDE.  The Xojo IDE has been stable for a couple of years and while I don’t find it as useful as the old REAL Studio IDE it doesn’t hinder me as much as it used to either.

Another vital aspect of a solid development tool is the stability of the compiled application.  This is where Xojo isn’t doing as well.  MacOS has been stable since the transition to 64-bit Cocoa was complete.  The transition for Linux and Windows has been less successful and this has to change.  If they don’t get better, many of us will be forced to look elsewhere for a new development tool.

This post is part rant and part wish list.  I want – no need – Xojo to be better than it currently is.  Part of my frustration is the plethora of older projects that are stuck on an older version of Xojo because of issues with newer versions.

Linux is a particularly difficult platform to work on: The number of distributions and slight variations ensures that there will always be some challenges to stability.  These differences make it difficult for Xojo to create builds for all distributions that work evenly.  The new GTK 3 drawing system has been less than ideal for us.

We have several cross-platform commercial applications that have macOS, Windows, and Linux targets.  When Xojo made the transition to GTK 3 it really messed up how these applications work in Linux.  Add in some 3rd party control compatibility issues and we’re stuck at Xojo 2017 R1.1 (before the GTK 3 switch occurred).

More recently, and more importantly, we’ve had a number of projects that were last built using Xojo 2016 R3 and the client recently wanted 64-bit builds for macOS.  This wasn’t a hard transition with only a few 64-bit specific changes required.  The Windows builds (still at 32-bit) in Xojo 2018 R1.1 proved to be impossible simply because the Windows drawing system has steadily changed in (what seems like) every release since 2016 R4.  

I’m not sure what the drawing system change was in 2016 R4 but drawing doesn’t work the same way as in 2016 R3.  Then there was the change to Direct2D from GDI and that had significant bugs for several releases.  The recent 2018 R1 release introduced even more significant changes to the Windows drawing system to reduce flickering.  The caveat is that drawing is much slower depending on settings and how you’ve layered your controls.

From my experience and from what I’ve gathered from the Xojo forums is that the new ‘flicker-free’ system is causing a lot of heartache among developers building for Windows.  Sure, flicker is gone but drawing is so slow as to be unusable in some cases.  Even developers that could live with the flicker are unhappy with the speed hit.

My client eventually told me to give up because he didn’t want to foot the cost of converting to a new drawing system that wasn’t causing him issues to begin with.  So, this means I’m creating macOS builds with Xojo 2018 R1.1 and Windows builds with 2016 R3 (with the code base from that era).  That is nuts and unacceptable.

I get that Xojo will always be playing catchup with changes to the target operating systems.  When Apple or Microsoft or a specific Linux distribution changes things it has to react to the change.  Hardly ever does Xojo have advance notice of the change (remember when Apple deprecated QuickTime and stopped accepting Mac App Store submissions with QuickTime just a few months later?  Or when Apple decided that iOS apps were going to be 64-bit only?)  I think that what we have in Xojo is nothing short of miraculous.

But, in regards to the drawing systems for Linux and Windows they’ve made a conscience decision to change a critical and important system.  This makes it tough to upgrade from one Xojo version to another without a great deal of work.  Clients don’t want to hear the term ‘lot of work’ because it means it will cost them.  So we’re stuck with older, and inferior, versions of Xojo.

I guess this is the price of advancement.  Any NEW projects will have the new Linux and Windows drawing system in place and we’ll think nothing of it a year from now.  But heaven help anyone trying to upgrade from an older version of Xojo to a newer one because it will cause a lot of work.

It’s probably not possible, but it would be great to have the option to use the older drawing system and have it marked as deprecated, or perhaps we even have to force the switch to use an older Graphics object.  In the not so distant past we had the switch in Windows to allow GDI or to use the slightly different GDI+.  I would really like that option in Windows (instead of the flicker free version) and for the older drawing for Linux.

I love Xojo.  What it does is nothing short of magic.  Develop on the platform of your choice and write for the other platforms.  That’s some high level wizard stuff there.  I just wish the transitions of major subsystems were planned out better beforehand, more stable when introduced, and not in need of major work to upgrade to use, or at least have a way to use the older system version for a period while still getting to use the new version of Xojo.

I can also argue that the constant cycle of adding new features and changing things every release is detrimental to the product.  Every now and then I want a release that is comprised ONLY of bug fixes.  Marketing be damned – I just want stable and reliable releases so I don’t have to juggle Xojo versions and plugins.

There are a lot of bugs that should be fixed that have been around for years.  I understand that not all bugs are created equal but some are very serious when you encounter them and are impossible to work around.  Again, having only a couple of releases every year that do nothing but clear the backlog would be awesome.

Instead, we already know we’re going to get Web 2.0, API 2.0, Interops, and Android in the near-ish future.  Those are all major NEW features.  Can we just get a few stable releases before those things are added so we don’t have to chase Xojo versions depending on bugs?

The old way of doing releases was to do one major release a year and then issue a number of ‘dot’ releases.  It usually meant that the first release of new features wasn’t a great one because of bugs but usually pretty good after the first or second update.  With the constant race for new features every release we get to chase versions based on what bugs we can and can’t live with.  

Please, Xojo, be better before I have to go in search of a new tool.

21 thoughts on “Chasing Xojo

  1. And I’ll add that Feedback is about a poor an application as I’ve used in a long time. It tried to report a Runtime Error in the IDE and it couldn’t submit and when I finally gave up and tried to quit I got an endless succession of dialogs until I finally force quit the damn thing. Feedback is useless to too many people.

  2. Good to see you changed your mind on the Rapid Release Model. Crossbasic started with the aim to be a better Basic than Basic and a better C++ than C++ by combining the best of both Worlds: the easy Syntax and approachability of Basic with the object-orientation of C++ … but as soon as stability and quality are no longer the driving force then things have only one way to go: downhill.

    I for one need basic functionality (pun intended) to be rock-solid.

    But I fear the situation is going to get worse before it gets better.

  3. P.S. Another way to look at it: I spend well north of $1,000 on “value” software bundles that in the end only had mediocre software that I never use. I spend a lot less on some choice software that is top of their field, and I use them all the time.

    I would prefer Xojo to be top on the desktop only to a Xojo that chases every target but is mediocre.

  4. It’s unfortunate that the same complaints I was hearing back in 2003 are still causing significant pain fifteen years later.

    Sorry to hear of your struggles, Bob!

    • Same complaints with or without the rapid release model which didn’t start until about 2005 😛

      Long time no talk

      • True. Part of the reason I got involved with the beta program was that the monolithic releases weren’t very stable until the 3rd or 4th dot release.

        The advantage it gave us, though, was that no NEW features were dropped in on those dot releases.

        I would have to imagine that the relentless pace of the 90 days Rapid Release Model makes being a developer for Xojo a freaking nightmare with the focus on adding new features EVERY release. It’s nuts and if I had a vote on it I’d get rid of the Rapid Release Model.

      • Hey Norman! 😀

        Yeah, my comment wasn’t a statement against the rapid release model. I think such a model could be successful, but only if certain preconditions were met.

  5. ” Just wish the transitions of major subsystems were planned out better beforehand, more stable when introduced, and not in need of major work to upgrade to use, or at least have a way to use the older system version for a period while still getting to use the new version of Xojo. ”

    “Can we just get a few stable releases before those things are added so we don’t have to chase Xojo versions depending on bugs? ”

    As I have to build for Windows, these two statements must be met to stay with Xojo on the long run. I am getting tired dealing with techniques being partial implemented, solving one issue at the expense of new ones.

    Hey Bob, giving relieve to frustrations helps dealing with it, isn’t it ?

  6. Xojo is a charming company with good people. But unfortunately that’s not enough reason to stay with them.

    I was shocked hearing that they are now dropping the Xojo Framework. That framework was a good step forward in making Xojo a more professional tool. I get that many prefer the Classic framework, but I’m really sorry, but the Classic one is ok for hobby purposes, but not for critical professional work.

    The last release was shameful, looking at the kind of bugs that were fixed. Those bugs should never get through a professional test. I can’t take this anymore.

    At this moment Xamarin, under the Microsoft flag, is going fast becoming a great cross-platform tool (eg. Xamarin Forms). C#/.NET is easy to learn. It has a lot of power built in, without the need for adding addins and (yuk) declares …

    Choosing a Microsoft tool is much more future safe that using Xojo. Xojo is ok for private hobby stuff. Sorry if I’m being harsh.

    • A few comments:
      Yes, it’s shameful the bugs that were released in the last release. We demand better.

      I think the jury is still out on Xamarin from a desktop perspective. The last time I looked at it it was wildly immature and you ended up writing stuff in C# and in Obj-C. And Mac IDE for Xamarin was godawful slow. This was long before MS put it’s stamp on it.

      To say that is Xojo is only for private/hobby stuff is absolutely 100% false. I *know* because I’ve written wildly successful commercial software for clients. I *know* other Xojo developers that are doing the same thing. So you really don’t know what the heck you’re talking about.

      • I apologize for my “hobby” remark, which can be misunderstood.

        I do like Xojo and its BASIC-like language. I think its team deserves a lot of credit and success.

        But …

        What I meant is that I need a tool I can count on. A tool that is stable. A company that has the resources and the responsibility to quickly fix serious bugs.

        From my experiences and from what I’ve read/heard from other users, that isn’t 100% the case.

        To give one example:
        I also develop in .NET and there I use a toolset from Rebex. I once found a serious bug that affects a number of my customers. I reported it to Rebex at 3 PM and got send a fix by them at 8 PM. A experienced that couple of times.

        I don’t say that every company should react that fast, but within a few days would be assuring.

        That’s what I meant with the “hobby” remark. With a hobby project I wouldn’t have customers at my back requiring my responsibility.

        So, yes, you can make commercial products with Xojo. I just trust Xojo enough.

        I also think the IDE and Xojo Frameworm fiasco is unforgivable for such a small team. If you have large man power then that’s not a big problem, but with such a small team as Xojo has, you can’t make these mistakes.

        That’s why I’m now looking at Xamarin which is making big steps on all fronts. It’s much better than 2 years ago.

        I hope I explained it a bit better now …

        • To my humble opinion you are going wrong when comparing bug solving by Rebex and Xojo.
          You should compare Xojo with .NET as both are the framework that you use to develop software.
          When you have a bug in .NET and report this bug to Microsoft, it will not be solved within a short period (hours).
          When it comes to tools, many Xojo tool developers like MonkeyBread Software, Einhugur, GraffitiSuite, etc. are usually very fast in solving bugs.
          Just my 2 cents.

  7. Could you make the Rapid Release Model work? Sure, if you had ten people fixing bugs for every one introducing new features … 😉

    The simple fact is:

    Under the old model you ended up with fairly stable releases that had all major bugs fixed before a big new version came out.

    With the Rapid Release Model pretty much every release ends up with some major bug making it unsuitable for certain projects.

    That was easy to predict back then, it’s easy to see now, and I know which one I prefer.

    • If Xojo actually had ten developers it would be a big shot in the arm. Instead you have four full-time developers and a contractor or two they use for certain things. I’d call what they do miraculous. But it really does spotlight how tiny the development team is.

      • Yes, it may be miraculous what they achieve with such a small team. The problem with such small companies, however, is that you get burned on the long run when you base your own business on a niche product.

        The product might not be around anymore tomorrow – I have seen this happen more than once with niche development tools, I’ve even worked at such a shop myself back in the late 1990s and witnessed first hand what it feels like when your employer goes bankrupt.

        I have used other BASIC dialects in the past from small development teams… Amazing programming languages, nice communities — and each and everyone of them shared the same fate eventually.

        Yes, I know. Nobody was there to keep Microsoft from killing FoxPro and the original Visual Basic. It’s not safe using a product from an industry giant either. I also witnessed Borland leading Turbo/Borland Pascal to its ruin — and that took a lot of effort, after all, back in the 1980s and early 1990s, Borland Pascal ruled the software development landscape. And Turbo Pascal was a really great product back in the day. And so was Turbo Basic – later PowerBASIC. And so was BlitzMax. Heck, even Flash was an amazing development environment once you understood — until Steve Jobs told everybody not to use Flash because he was afraid that people could actually use it to write multi-platform software with it instead of willingly getting locked into just writing apps for iOS…

        Great tools come and go. Unless, of course, they are called C, C++, Java or even Python. Or COBOL or FORTRAN for that matter. These seem to be doomed to stay around forever. Why? Because way too many developers are using them and there are committees or independent foundations behind them, guaranteeing their long term survival in the industry. Those languages and their ecosystems are not niches, which makes them safe(r) choices.

        Personally, I like niche BASIC-style languages, but I’ve lost my trust in them a long time ago. It would be nice to find a safe haven that will stay around for the rest of my career and that I feel the same affinity for that I feel for good old BASIC. Python seems to be the closest thing, if only it was as fast as our beloved compiled BASICs…

Comments are closed.