In This Edition:
Helix RADE 6.2 Preliminary Release 22: Fonts, and other fixes
11 April 2013 — Excellent progress continues with the twenty-second Preliminary Release of Helix RADE 6.2 available today.
Subscribers to the Europa Pioneer Plan should have received an email yesterday containing a link to this latest update. You can also get it by logging in to our web store and checking the download link listed in your current licenses. If you are a subscriber and you aren’t receiving the monthly emails, please contact us so we can determine why.
For those who haven’t joined us yet, the monthly subscription option came to an end two months ago. But you can still pay $440.00 and get the two remaining updates we plan on releasing through May 31, 2013.
As always, you can find all the details of what has changed since the last Preliminary Release in the Preliminary Release 22 Release Notes.
Since we put the second iteration of the new abacus in your hands a month ago, most of our resources have been diverted to fixing various problems we have discovered ourselves. Many of those are of our own making, due to the nature of development work. But the old Helix adage that “people use what works” always kicks in the moment someone in the field launches the Helix collection they know most intimately and so, anything we may have missed inevitably finds its way to us from the field.
In addition to the bug fixing, we took detours to two other fronts in the march to macOS. One was to resolve a major Client/Server 6.2 obstacle, which also turned out to be the cause of an annoying quirk in RADE 6.2. The other was to make the macOS Font Panel usable.
The ability to build abaci using a mouse again has clearly awakened the Helix RADE user base, which was becoming something approaching catatonic after such a long winter of discontent waiting for us to finish Server, Client and Engine. But now that it’s out there, it needs to be correct.
A month of detours
Last month we said that we were shifting our focus to the User Editor. But a double-click on a User icon in today’s Preliminary Release 22 will still bring forth the “This command is not yet ready for macOS” dialog. Though some parts of the new User editor are indeed already in place, so little of it is functional at this time that we decided we would keep it under wraps until you could actually do something with it. If all goes well, that should happen a little later this month.
As noted above, the principal detour this month was bug fixing. Whenever we start to fix bugs, we try to very painstakingly prioritize the little creatures. The first priority bug is the “show stopper,” and there were enough of those in the abacus editor that debuted last month that we needed to address those properly.
A show-stopper literally does just that: it stops the show. When we determine that we have one of these, we do not stop until it is fixed. A handful of particularly annoying ones were finally eradicated during the past month.
At the other end of bug spectrum, the “soggy bottom” of bug fixing is where the “bugs-with-workarounds” live. In our zeal to produce a working RADE product in macOS, we have often “forged ahead” knowing full well that problems exist, but secure enough in the knowledge that there were uncomplicated workarounds that could be used until a more propitious time arose in which to fully eliminate the need for any workaround.
As we saw the end of RADE development in sight, some bugs began to find their status rising from “mildly annoying” to “aggravating and beyond.” Each bug caught and fixed has the unfortunate tendency to shine a brighter light on all the others that yet roam free and unencumbered.
Dozens of bugs that ran the full spectrum were laid to rest at last this month; they are detailed in the aforementioned Release Notes. We urge you to read about them; if something in that list was keeping you from taking fuller advantage of RADE, or worse, keeping you in Classic RADE, these obstacles have been removed from your way forward.
As deep as we are into working on RADE, we always bear in mind that RADE is the centerpiece of a family of products, and that the other Helix products (Server, Client and Engine) do all eventually have to join the party. The Helix Engine is, for all practical purposes, already fully functional as a 6.2 product. But the Client/Server Toolkit has had a few problems that have kept us awake nights. We are very happy to report that the principal problem behind these fears was isolated and fixed this month. Testing on Helix Client/Server 6.2 will begin again soon.
And we received a very nice bonus when it was discovered that fixing the Client/Server issue also fixes the annoying quirk of RADE 6.2 that required you to open at least one view before taking the collection back to Helix 6.0 or 6.1. We’ve fielded enough tech support calls over that one that having it fixed is a real joy. (Be sure to read the supplemental April 17 edition for an important follow up to this bug fix.)
Back at the office
As close as we are to the end of this monumental journey, this seems like as good a time as any to start picking up all the junk we’ve left along the trail, which is a fanciful way of saying that we’re going to unload some of it in the form of pet peeves. Please bear with us. If any of it seems personal, it isn’t, except perhaps if you find yourself reading it and find yourself saying to yourself, “Hey! Is that me?” We never could be responsible for individual interpretations. In any event, before getting back to what is truly new this month, we ask for advance forgiveness for our digressions.
All through the process of bringing all these wonderful products into the future, we’ve also been running the business end of Helix “back at the office.”
And because that business is making Helix, we’re always ahead of the general learning curve because we’re always sitting around beating it up, looking for ways to make it fail. Like all of you, we’re always terribly disappointed when we find one. Unlike all of you, however, we pretty much have to see all the things you never should, so that disappointment weighs heavy and happens far too often. Such is the precarious nature of what we’ve undertaken.
Being ahead of the general learning curve has its advantages, but they are counterbalanced by a plethora of disadvantages. We’ve been running a business, as we noted above, using Helix Client/Server in macOS now for nearly seven years. None of us access our system with a Classic Helix Client anymore. We have learned and gotten quite comfortable with the many benefits accrued from running in macOS. Tiger was wonderful. Leopard was even better. Lion, and now Mountain Lion, have dramatically improved the Helix user experience in macOS.
One of the disadvantages for us is how hard it is to understand why so many Helix users are still running Client/Server in versions older than 6, still clinging to Classic out of fear of some disaster awaiting them.
Change is difficult, but for Helix, at least, things have really turned a corner, making us look forward eagerly to each new iteration. Each new iteration validates another assumption we made about how Helix had to be built, especially the decision we made years ago to take advantage of what the Mac OS offers, rather than do everything in our power to avoid it, backing Helix into an untenable position for the long run.
Each new iteration of RADE has made it easier to work in macOS, and brought with it new and better ways to use Helix. That makes us want to get the corresponding Client/Server tools into user hands as soon as we possibly can, and wean users off Helix Engine, which has nobly served its purpose but no longer needs to occupy the role it has while RADE was built.
Whither Helix Engine?
This question lies close to the heart not just of the future of Helix, but why we undertook the transformation of Helix from Classic to current in the first place.
When the last owner of Helix got into trouble, we were on the short end of a very sharp stick. All we knew was that there was smoke, and when there’s smoke there’s fire. But we were led to believe that before it all burned, the smoke would clear.
So when the original idea that we take over the day-to-day operations of the business was floated amongst us, it seemed like we were considering doing something no one in their right mind would ever do: working off money that was owed to us. If any money came in as a result of our efforts to keep Helix going, we would use it to pay ourselves for the many months we had gone without pay.
We were all quite angry at the way things had played out and our inclination was to toss it all away and let the previous owner sink along with his product. But working from a place of anger is never a good place to be. We were making our livings working in Helix. Most Helix users do not use Helix that way, but we did, and we wanted to continue being able to do so.
Finally, the thought that made it all happen was expressed this way: “You can certainly look at this situation like we’re doing some kind of penance, but if we don’t do this, there won’t be a Helix to go back to when the smoke finally clears.” For us, that just was not an option if there was a way to prevent it.
As anyone who has followed this saga knows, we have had to scratch and claw our way to get to where we are today. And a great deal of that scratching and clawing was done by offering users a lot of incentives for staying with Helix.
When it came down to financing the development of RADE, prior to the Europa Pioneer Program, one of the things we did was to ask RADE users to upgrade to Helix RADE 6.1, the then current version of RADE. But it was still a Classic product, and our customers were sick and tired of it because every time they launched it, it reminded them that we did not have Helix RADE for macOS. In exchange for that financial vote of confidence, we provided these users with the Helix Engine so they could at least work in macOS. Even if they couldn’t make structural changes to their Helix applications, they could at least use Helix on their new macOS-exclusive Macs.
Once again, good intentions had some unintended consequences and the “people use what works” principle kicked in. People who had no idea what Helix Engine was and only wanted RADE found themselves merrily working away in Helix Engine. And the more they did that, the more complacent they became about their need for Design Mode.
As we now know, it is the abacus that reminds us of the incredible power of Design Mode in Helix RADE, and with its arrival, suddenly a new legion of Helix users started looking at RADE in macOS and in the process, discovered quite a few bugs that had slipped into the last release. We decided to take the time and fix those bugs, and that’s why so little progress was made this month on the User Editor.
Better abacus editing
Thus the principal result of our bug work this month is better abacus editing. A month ago, we crudely pronounced the abacus editor as complete. The progress we’ve made in the abacus since last month makes it hard to imagine how we could ever have said such a thing.
Here is a perfect example of the difference between then and now: a handful of bugs in the abacus had to do with a crashes occurring when the user fails to commit after deleting a tile from an abacus. The workaround was to remember to commit. Not complicated, but easy to forget nonetheless. You don’t have to worry about that any more.
Last month, you could build an abacus with a constant in a socket. But if you decided to go back and change that constant, you were out of luck. Simple workaround? Change the constant by editing the Expression property. Now you can edit the constant directly.
Generally speaking, the abacus editor experience has been enhanced and improved this month. It is now where it probably should have been a month ago. For that, we apologize. If any of those problems caused you to put RADE aside or jump ship, please swim back now and have another look. The abacus editor works as it should. It will see more improvements in the future, but for now, we are moving forward again.
(finally) the Font Panel
The Font Panel is a macOS device for specifying fonts, font attributes, sizes, colors, backgrounds, in short: anything that relates to the display of type.
One of the earliest attractions of Helix was that it gave the designer easy, complete control over type, enabling users to do virtually anything, anywhere.
But for reasons we may never know, Apple decided that macOS users should not have as much graphic leeway as Helix users have always enjoyed. Some, graphic designers in particular, might argue that a typical Helix program has way to many fonts and colors in odd places, like on buttons or in so-called drop-down menus or on input control devices like radio buttons and check boxes.
The good old days of Helix graphics actually “went away” when we released the first macOS native Helix Client and Helix Engine. In place of the old Style menu, and its component sections of fonts, sizes, styles (plain, bold, italic, underline, outline and shadow) and colors, we now had a single device: the macOS Font Panel.
The only problem was that it did not really work the way it did in other places you might find it, such as TextEdit or other Apple applications. If it had worked properly back then, we would not have had to invest the time we did in the last month to get it right. It was always a high-priority back-burner issue, but with the ability to edit the text labels on a template, it was beginning to boil over.
In macOS, it’s the system font that displays on drop down menus, radio buttons and check boxes, leaving font styling applicable in only three places: when editing the content of a label or data rectangle on a template, or editing the content of a styled-text field on a view. Once you get comfortable with the fact of having to give up a little of your design control, dealing with the display of labels and data is still vitally important and deserving of a good solution.
The main reason the original implementation was so difficult to use was that it was a modal dialog. You had to make your settings and then close it to see them take effect. Often, even that did not work: the sheer bugginess found in this part of macOS is mind-boggling! But we pressed on. Having the Font Panel truly non-modal in User Mode is more than just a fix. The Font Panel provides an end user with much more flexibility than ever before possible in Helix when working in User Mode. It truly enhances the user experience, and as it evolves over the months to come, it will enhance that experience even more.
What lies ahead
A month and a half is all that remains of the Europa Pioneer Plan’s second year. It looks increasingly likely that there will be two more releases.
The first will be the User Editor, again, with everything going well, later this month.
The second, which will ship at the end of May, will correct the hopefully small number of bugs we introduce while building the new User Editor, and will give us the time to generally clean up our campsites and pull what few remaining rabbits remain in our hats out for your Helix-using pleasure.
Once Helix RADE 6.2 is set free, our plan is still to shift our focus to getting Client/Server 6.2 out the door. Then, we have a few fun things up our sleeves, more about which will be discussed in the months to come.
As always, please remember, even at this late date, that we still need all the financial help we can get to finish this job, and that you can both help us and save yourself some money by getting on board before Europa is finished. It’s getting very close to the time when the Europa Pioneer’s discount will end. If you are still not ready to commit, or can’t afford the $440 right now, log into the web store and purchase a block of USUs. They will help us get the job done, and when you have some more money, you can add it to those to pay for your eventual RADE upgrade.
We hope you enjoy using the new font panel and the improved abacus editor as much as we did making them. We are quite satisfied with what we have built so far, and we look forward to making it even better.
* All prices are stated in US Dollars.