Apple's accelerated schedule of releasing new Intel-based Macs has put Helix users in a bind once again. The new Intel-based Macs do not support the Classic environment, which Helix RADE, Engine, and Client currently require. It is becoming more and more difficult to purchase a new Mac capable of running these Helix components.
Shortly after the release of Helix Server 6.0 (compiled using CodeWarrior) we began the arduous process of converting our entire code base to Xcode. Although this is fairly easy for small projects, large projects present difficulties that must be addressed.
Some of our customers are understandably nervous about the situation, and we field calls daily asking for updates. The purpose of this page is to document the progress we are making in short form, keeping you up-to-date on the status of this project. For a better “long range” view of where we have been and where we are going, be sure to read The Latest Word.
Some of this information was formerly found on our Intel-compatibility page.
Ugh. This week was spent fighting through some incredibly difficult code…
On one front was the button name issue. Helix allows you to name buttons dynamically, using the output of an abacus to provide the button name. There are also options for dimming and hiding inactive buttons and making active buttons transparent. The naming code is mostly done, and it features a couple of immediate improvements as well as being written in a way that will allow us to provide some serious feature improvements down the road. However, there are issues still to be dealt with. Transparency is going to prove difficult, as the Carbon button code only supports transparency as part of the disabling process. Also, Carbon buttons do not allow the label text to wrap to multiple lines. We are working on some solutions, but they probably won’t be easy.
Another engineer spent the entire week working on record locking. (Before this, our OS X Client/Engine did not lock records, and being able to edit the same record on two views — or from two Clients — would be a serious flaw.) On top of that, we discovered a bug that has existed in Helix, apparently from the very beginning:
- Create a collection with one relation, having two fields. Make a template with both fields, and a default value (just a constant will do) for one of the fields. Make two views using that template.
- Make a template+view with both fields, without the default value. Use that to enter a record that has an undefined value in the defaulted field.
- Using both of the other two views, find that record. They will both show the default value. On one of them, change the other field, but don't hit Enter. That will lock the record. In the other one, hit Replace. That will store the default value, even though the record is locked by the other window.
This bug was addressed while implementing write locking. But even without that problem, adding write locking was incredibly difficult. Both HIView (Apple’s code) and wxWidgets (the cross-platform API) believe that something really should have keyboard focus in every window. Helix assumes that nothing will have keyboard focus if the record cannot be changed because it is locked in another window. The fix involves changes at many levels in the architecture of the program and to intercept keyboard and mouse input at a more fundamental level.
This week was spent trying to get irritating inconsistencies fixed. This is the stuff that makes programming painful. Getting buttons to enable/disable at the correct time, getting the background objects in a template to stack properly, getting dynamic popup menus to be dynamic (and not crash), getting label rectangles with pictures to put the picture in the right place, getting the ‘Option-Enter’ keystroke to be recognized… the list goes on and on.
One ongoing struggle is with ‘popup menus that allow typing’. In OS X these are called Combo Boxes. For some miserable reason, you can tab into them, but you can’t tab out.
Still, the OS X Helix Engine is actually starting to become a usable product.
In case we forgot to mention it: in keeping with our volcanic code name theme, The OS X Client/Engine project is code named Io.
Arrgh! Getting a cross-platform API like wxWidgets to understand the difference between the Return key and the Enter key is a real pain. Add to that Helix’s variations on what Enter means: Enter (aka: Enter/Find), Replace (Replace/Find), Static Enter (aka: Enter/Stay), Static Replace (Replace/Stay), Enter Overide, Static Enter Override, trigger default button, accept dialog box input, …) For the collection designer there is quite a bit of work to do to make sure Enter does what it is supposed to do in all cases.
In the process of updating the code for OS X we have had to sort these out, and in the process, we have made a change to the way Helix works, closing an inadvertent design loophole where a view with a default button could still be ‘entered’ by using the Enter menu command. In Classic Helix a designer who wants to make absolutely sure the user can never simply enter a record — e.g. because the default sequence must be run — must also remove the Enter command and/or remove the Add/Replace permissions for every user for that view. Removing Enter from the user menu creates other logistical problems. Removing specific view permissions from users is an arduous process where errors can easily slip in. Toss in the fact that most designers do not clearly understand the purpose of the Enter Override and Static Enter Override commands and you have a situation where making sure the user can not simply enter the record — and keeping your data sound — can become a complex and time-consuming task.
The revised code treats the Enter menu command exactly the same as pressing the Enter key. If there is a default button on the view, selecting Enter from the menu now triggers that button. The Helix Reference (4.7.3.1) does not explicitly define what was formerly expected to happen in this case; it only notes that if you remove Enter from the menu you must make Enter available in a sequence (button) on the view to enter the record. We debated what the wording in The Helix Reference implies about Enter in the menu and concluded that this spec change does not counteract any explicit specification. That conclusion, along with to our desire to close the loophole, plus the fact that this ‘path of least resistence’ to get Helix to OS X, helped make this decision.
This should not be interpreted to mean that an Enter command within a sequence will also take on this behavior. That command (which will be renamed ‘Enter Record’ in the future) continues to simply enter the record on screen. Use the sequence command Keypress: Enter to simulate a keypress/menu selection Enter when needed.
Also note that the Enter Override and Static Enter Override commands placed on a user menu will continue to simply enter the record also trigger the default sequence.
The names of the enter commands as seen within sequences will be changed to Enter Record, Static Enter Record, Enter Record Override, and Static Enter Record Override in Helix 6.1 to make the distinction clearer.
The Import/Export & Copy/Paste Record Options dialog has been reworked for OS X. Much nicer.
Sort Order now has an inndicator to specify the ‘default’ index. (Bold+Italic text)
The Export Ordered code was left in place, but blocked out, since 100% of our survey respondents so far say they never use it.
More bugs fixed.
Sort Order is reimplemented as a toolbar widget. Much nicer.
Styled Text works much better now. (No memory leaks, color support, etc.)
Lots of little bugs fixed: tabbing from field to field is better, static enter works, dialog box response to keystrokes, dynamic popups no longer crash when clicked on, etc.
Open Query is now functional in OS X.
A nagging problem has been fixed: the new view code thought that simply tabbing through the fields in a record was enough to signify a change to the data, and Helix would ask if you wanted to save changes before closing even when no changes were made. This was traced down to a bug in wxWidgets and fixed.
One from the ‘Ugh’ Department: Buttons in Helix have been changed from Aqua Push buttons to Bevel buttons. This was done because Push buttons are limited to specific sizes, while Bevel buttons allow virtually any size, allow pictures instead of text, etc. Bevel buttons provide the feature set Helix designers expect, so although we personally find them ugly, we have to go that way.
Here's a link to Apple’a HIG Page Showing Button Styles.
One sentence from Larry in this morning’s email: Printing works!
More words: “I think I've got all the pieces, although I'm not completely confident that the pieces all work in every combination. Let the bug reports begin.”
This is a huge step forward and, based on our initial in-house testing, may allow us to finally zero in on a time frame for eventual release of OS X Engine/Client.
Printing. This is a huge task, and probably the last (and largest) hurdle we have to cross before serious testing can begin.
Basic page printing is working, now come the details: large templates (larger than one page), suppressing rectangles where "Printable" is off, honoring the "First Page", "Middle Page", "Last Page" check boxes, printing in sequences, handling a Cancel during printing.
More ‘rough edges’ are being knocked off. The Quick Query toolbar no longer opens every time a view is opened. Subforms are now clickable. List selection is now fully functional.
Click to select records on a list, and double-click to open records on a list now work according to the new spec. The new spec resolves an ambiguity by recognizing the difference between double-clicking an unselected record (which does not create an "ad-hoc query"), as opposed to double-clicking a selected record, or one of many selected records, (which does create an "ad-hoc query".)
A single click selects the record that is clicked, and deselects everything else. The first record selected sets an "anchor point", and a shift-click selects only the records between the anchor point and the clicked record (inclusive.) A command-click toggles the selection of a record, adding or removing it from the selection as needed.
Records in a subform list can be opened with a double-click, but not selected. (Consistent with existing spec.)
Dragging over a list of records to select records under the mouse is not implemented yet.
Next up: Bug swatting.
Converting views to run with native OS X controls is long, slow business. Although the views are up and running we have encountered (and fixed) bugs with names like: "Sequences Can Not Be Cancelled", "P# does not display Page Number", & "Scroll bars still visible when turned off." Many more remain, but steady progress is being made.
Be sure to read our final "The Latest Word" of 2006 for a few screen shots.
Next up: picture rendering, selectable list functions.
One round of "obvious bug" swatting complete. Found some unpleasantness in sequence execution, among other things. It's still not really usable, but we're making progress.
Display Subforms! The subform code is the most complex piece of code that must be migrated to OS X before we can ship native Client/Engine. It is finally done — until testing starts finding obscure bugs in it, that is.
On another front: Helix Client's Visit/Open dialogs had to be reworked, and we took the opportunity to add a few nice enhancements.
This page switched to listing event in "most recent first" order. (Because who likes to scroll all the way to the bottom to read two lines?)
Helix Server's conversion to Xcode has reached the stage where we can start testing this build to see if Xcode has broken anything.
A "first run" Helix Client OS X was built today and successfully connected to the new Server. Another major milestone is passed!
Some bug fixing on the first pass at entry forms is being done.
And during that bug fixing… oh, wow… the "Helix is a processor hog" bug was found and fixed! Or so we think.
The list code has been committed and sent to testing. Subforms are next.
Alpha testing on entry forms continues. List forms are shaping up. The first version you see may not look like much, but the stage is being set for many new features. (As much as we'd like to do them now, we resist so as not to allow the ship date to slip further.)
A giant step forward. Our Xcode projects for Helix have been totally restructured for more efficiency. The all new, MLTE-enhanced view code has been integrated into the revamped project. Our in-house Alpha testing can begin in earnest.
Please note that this does not mean that release is imminent. We still have a lot of work to do. Nonetheless, this is a major milestone.
Popup menu work is completed. Checkboxes and Radio Buttons are up next.
On a separate thread: we now have a proper About Box (complete with live links to our web site and a "current version" lookup) and an Open Recent menu item.
Dynamic Popup menus are nearing completion.
Styled text hit a few snags, requiring a re-evaluation of the code. In the end we discovered that Apple's Carbon implementation of the Font Panel is a bit buggy (to be kind) and we switched over to using the Cocoa Font Panel. It seems to be 98% right, which is close enough for now, given the time constraints we are under.
The Fixed Point data type was exhibiting some oddness (nothing to the right of the decimal point, funky rounding) but that's fixed now.
Pictures in template rectangles now draw correctly. Picture fields work fine, except that OS X clipboard does not seem to support the PICT format anymore. We're studying the issue.
Styled text is working, except that the old Classic "Shadow" type is removed from OS X, so that type of text displays as plain text. (There's nothing we can do about that, sorry.) OS X Helix uses the standard OS X Font palette (Select "Show Fonts" in TextEdit or Mail.app to see it) to specify font/style data! It all works except specifying a color.
MLTE work nears completion. Views — including Quick Queries — are like a whole new (OS X native!) world. We're thrilled to be (mostly) past this obstacle.
MLTE work continues. (Did we mention that this is a big project?)
MLTE work continues. (This is a big project!)
The login interface been rewritten to present a single User/Password login window. This adds security since the intruder must now guess both the name and password at the same time. With User Name Security turned off, the login dialog now uses a popup menu (using OS X controls, so it is also type selectable!) to select the user name.
from TextEdit to MLTE
This week (actually, last week) one of the ‘hard jobs’ of converting an old application like Helix to OS X was started: converting from using the TextEdit APIs to MLTE.
What is TextEdit: TextEdit was originally designed to handle editable text items in dialog boxes and other parts of the system software. Although TextEdit has been enhanced to provide more text-handling support since its inception, especially in its handling of multi-script text, it retains some of its original limitations. (From Apple's Carbon Reference for Legacy APIs)
What is MLTE: MLTE (Multilingual Text Engine) is an application programming interface (API) that allows your application to provide Carbon-compliant Unicode text editing. MLTE is a replacement for TextEdit that offers more features than those in TextEdit—features such as document-wide tabs, full justification of text, support for more than 32 KB of text, built-in scroll bar handling, built-in printing support, support for inline input, support for the advanced font features of Apple Type Services for Unicode Imaging (ATSUI), and support for multiple levels of undo. (From Apple's Carbon Reference for Modern APIs)
Considering that the time required to replace TextEdit with MLTE is expected to be about the same as updating our old TextEdit code to be OS X compliant, this decision was a no-brainer. We'll have a better fix on ‘how long’ in a few days.
Note: our plan at this point is to leave Unicode support turned off in the first release of an OS X Client/Engine. We need to fully understand the ramifications of that before adding such a dramatic new feature and work out how this will interact with the existing OS 9 Client.
Compiler Speed
Adriaan van Os, Mac OS X/Pascal code guru and member of the GNU Pascal Compiler (GPC) development team has signed on as a consultant. Adriaan will be working with us to improve the performance of the compiler and to work through the tricky details of moving our Pascal to Xcode.
With Helix Engine in the hands of testing, engineering turns its attention to creating Xcode versions of the other Helix products. In less than one week the Helix Server project was moved from CodeWarrior to Xcode. The few wrinkles that were found were ironed out quickly. Next up: Helix Client.
Helix Engine is now ready for initial alpha testing. Next week we start running our baseline tests and looking for obvious bugs.
Larry writes: Some more real progress was made today. I got the query window dialog working, and actually stored some data and found it with the query. I checked in my current code...
Progress on Helix Engine has been stalled over window drawing issues. It took days to track down the problem. The old code that draws windows is going to be a problem until we have time to totally rewrite it. For now, we stick with QuickDraw (which has been depreciated by Apple and will be dropped at some point) and give up all the nice things Quartz would give us. Getting an OS X Client/Engine is deemed more critical than having beautiful, anti-aliased text.
Parallel to the main work, there is an ongoing project to eliminate the last vestiges of OS 9 dependent technology. Behind the scenes, we were still using one of Apple's ancient apps (MPW Shell) to generate the code that gives each type of icon its attributes. MPW Shell is an OS 9 only tool, and therefore destined for the dustbin. All of the scripts that ran in MPW Shell have now been converted to Python and thoroughly documented, so we now have a firm handle on this fundamental aspect of Helix code creation. Next up is the Dynamic Popup Menu code, which is still (believe it or not) written in 68K assembly language!
The best example of where this comes into play is in the copy/paste structure code. Helix's ability to paste structure from older versions of code requires thorough knowledge of the attributes of the objects, particularly how they changed as new versions of Helix were released. Some of the copy/paste structure bugs we've fixed lately were introduced because there was, from 1997 to 2003, nobody working on Helix who thoroughly understood how this code worked.
On a more sober note, this week Larry's father encountered some serious health issues, and Larry may be sidetracked for a few days. While the rest of us continue plugging away on Helix, we ask you to join with us in praying for the best for Larry and his family.
Larry writes: Helix Engine can now launch cleanly, open a collection, enter records, and save the collection. (This is a major milestone!)
Helix Engine compiles in Xcode, but crashes immediately when launched.
Since Helix Client is, essentially, Helix Engine plus networking, getting Helix Engine converted is a much more efficient way of working on the code. Once Helix Engine is debugged, Helix Client will be mostly complete. (Helix Server is already running in OS X, so our networking code is already there.)
“Update Collection now works.”
Attention turns to moving Helix Engine to Xcode.
Our first product to convert to Xcode is Update Collection. This is chosen because it is the smallest Helix application, which will give us faster turnaround times when making changes. (It's good to start with a simpler project before trying to tackle a huge one like Helix Engine.)
Converting large CodeWarrior projects to Xcode projects is not the walk in the park Apple presented it as. Many fundamental assumptions (e.g. how many bytes are required to store an integer) must be challenged and revised. Helix code must be painstakingly searched for such assumptions and turned into explicit declaration.
Xcode's lack of support for legacy Pascal requires that we go on a search for a third party Pascal compiler that works with Xcode. We settle on GNU Pascal Compiler (GPC).
Apple releases Intel-based PowerBooks and iMacs. We accelerate plans to build OS X native Engine and Client in Xcode.
After we "made a valiant attempt at creating a Helix Client with CodeWarrior" and saw that it wasn't going to work, we made the decision to abandon CodeWarrior and start moving to Xcode. Larry Atkin is tapped to head this project.
We ship Helix Server, Helix Utility and Update Collection as OS X native components.
Attention turns to the feasibility of quickly creating OS X native Client and Engine built in CodeWarrior. CodeWarrior's general inability to handle our user interface code makes progress slow.