BKS Tab Control

Lenexa, KS (June 20th 2018) — BKeeney Software releases BKS Tab Control
The BKS Tab Control is a set of classes that offer developers a classic “tabs control” for Xojo Desktop applications. The Tab Control can attach to any RectControl or Window, and will maintain a relationship to this parent control if and when it changes size. Tabs can be displayed in one of four directions (North, South, East, West) and individually offer options like a close button, an icon, a background color, and can be disabled.
Other features:
— Optional CloseBox can be positioned on the left of right
— If the CloseBox is selected a CancelClose event is fired
— Optional Icon can be positioned on the left or right
— Each tab can have a different background color
— Each tab can be disabled
— Each tab text can be stylized with font, font color, text size, bold, italic, underline
— Tabs that overflow the available width may be accessed with an overflow popup menu
— Works in HiDPI and non-HiDPI modes
BKS Tab Control has been tested in macOS, Windows, and several varieties of Linux with Xojo 2018 R1.1 and back to Xojo 2017 R1.  The control may work, unchanged, in older versions of Xojo.
BKS Tab Control is sold as unencrypted source code and costs $75 USD.
More information and demo project download available at:
macOS
Windows
Linux
All Directions

Xojo and the Rapid Release Model

If I could change one thing about Xojo what would it be?  My answer is, without a doubt, the Rapid Release Model.  Here’s why.

The idea of the Rapid Release Model isn’t a bad one.  In the not too distant past many applications had major yearly updates.  Many still do.  In fact, Xojo (when it was called Real Studio) did this with varying degrees of quality.

Some of the complaints about the yearly, monolithic, release of Xojo (back when it was Real Studio) was that it wasn’t a very stable release and it took several dot releases to get it right.  This was the impetus that led me into the Beta Program so I could test out new features before it was released.  I was tired of new features not being usable due to an obvious lack of real world testing.

In theory, the Rapid Release Model introduces smaller changes and a few new features each release.  Releases are roughly every quarter but in recent years this timeframe has not been as consistent.  I believe this change happened, in large part, to address some of the complaints of the Rapid Release Model.  One of the complaints being that the constant drive to get new features in every release gives the software a perpetual beta feeling.  I would argue that the recent changes to the Windows drawing system certainly justifies that feeling to many current Xojo developers.  

From a developer standpoint, I can only imagine the pressure on Xojo’s small development team to constantly add new features every 90 days.  It means that developers are always pushed to get things done rather then get them right the first time.  Again, I would point to the plethora of changes to the Windows drawing system that have spanned many releases as proof.

I believe that marketing is entirely behind this new-features-every-release mantra so they can get buzz about something in every release.  I get it:  for a small company they need to create as much buzz as possible.  Buzz creates some sales and renewals.  But I think the Rapid Release Model is actually hurting them with many developers who value stability over new features.

More evidence that the Rapid Release Model is hurting Xojo is their recent change of telling customers their development plans.  No longer will they tell us the target date of when a feature is released and instead they’re simply saying if it’s a ‘priority’ or ‘important’.  Prior to this, Xojo CEO Geoff Perlman said that Interops and Android would ship by the end of 2017 and not only did they not deliver, but it seems highly unlikely they’ll get it out by the end of 2018 in anything other than an alpha release (purely a guess on my part and I’d love to be wrong).  

Being poor at estimating isn’t just a Xojo problem.  Chrono-Optimism is a human condition and I believe the old adage that 80% of the work takes 20% of the time and the final 20% takes 80% of the time.  Estimating is an arcane art form and at times software development is pure magic that takes time.  Forcing releases into this 90 day window makes the problem worse by having incomplete solutions and incomplete testing.

When all is said and done, I believe Xojo would be better off ditching the Rapid Release Model and going back to monolithic releases with regular dot releases that does nothing but fix bugs.  Perhaps this means that there are only two major releases a year.  Sometimes only one.

The Rapid Release Model is not without some merit.  We currently know that every release will fix a large number of bugs and we know roughly when that release is going to come out.  Not all bugs are created equal but for many developers we can’t wait six months to a year to get a release that fixes some bugs.  So any replacement to the Rapid Release Model must take into account that Xojo developers need a regular, perhaps monthly, bug fix releases for critical and important bugs.

I think changing to a hybrid model between the monolithic release and Rapid Release Model fits the small Xojo team better.  First, it lets the new features gestate in internal testing longer before we ever see them without being rushed out the door.  Second, the regular release of bug fix builds is simply that – bug fixes – and lets the developers continue to work on the next big thing without the pressure of having to add new things in each release.

To say that the Rapid Release Model is a failure is hyperbole.  To say that the model makes the product beta quality is also a stretch.  The truth is somewhere in the middle and I think this is an important discussion for the future of Xojo and their customer base.  What do you think?

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.