Name bar

The name bar arrows that are used to navigate through cards in a stack have been moved into a new class, HasNumberedPages, so that non-stack-based scenes can also have arrows to scroll through pages.

The caption that appears between the name bar arrows can be customized. The attribute HasNumberedPages_CaptionTemplate returns an ephemeral copy of iStandardCaptionTemplate which is "/page number/ of /page count/". Subclasses can override this attribute to return custom captions, like "/page number/ of /page count/ doohickeys". The attribute HasNumberedPages_CaptionPhrase uses the templated returned from CaptionTemplate() to fill in the page number and page count. Subclasses can override this attribute to perform additional mungine on the caption text.

The titleBarFlags field of class NameBar has been split into individual Boolean attributes.

Classes affected by these changes

Name cards

To increase the performance of unpacking packages full of name cards, and to increase the amount of contact information that can be kept on a Magic Cap communicator overall, the name card model has been changed in the Rosemary release of Magic Cap. Contact information is now kept in FullContact objects instead of AddressCard objects, but many occurences of "AddressCard" still appear in the programming interface.

There is no longer a one to one correspondence between name cards and an entity's contact information in the system. The name cards file keeps one NameCard object around; as the user cycles through contact information, this single name card is used to display the information in any given FullContact object. Typically, contact addresses will be passed around the system; name cards will only be created when contact information needs to be displayed. This new model increases the amount of contact information that can be kept on a communicator while reducing the amount of time it takes to install a package full of address cards. Similarly, a single index card is now shared by all the indexed letters.

This change means that you no longer install name card objects into the name card stack. Instead, your packages should install a FullContact object into a master list maintained by Magic Cap.

The old way:

        instance ObjectList install;
            entry: (NameCard myNameCard 'GMDTS');
        end instance;

        instance ObjectList receivers;
            entry: iNameCardsStack;
        end instance;

The new way:

        instance ObjectList install;
            entry: (FullContact gmdtsContactInfo 'GMDTS');
        end instance;

        instance ObjectList receivers;
            entry: iContactsMasterList;
        end instance;

Name cards choose their form in SetAddressCard() instead of using separate name cards that are identical other than form for different address card categories. The form is set up based on the card's category. This makes NameCard_PrototypeNameCard obsolete, so this operation has been removed. You can access the singular name card with NameCardsScene_NameCard.

Since only one name card is used in the name cards file, class NameCardsStack is no longer necessary. Removed this class and iNameCardsStack, which pointed to the instance of it.

Searching for name cards is actually performed on address cards in the master list. NameCardsScene_SearchFor returns a new AddressCardSearchResult instance for any matches that are found.

Prior to Rosemary alpha, tapping in the index tabs in the name cards stack was very slow. Improved the tapping performance when there are a large number of items in the list.

The index tabs themselves have also been reworked to be more international friendly. Index tabs embody two concepts, section index and tab index. These two concepts were rather muddled and have been separated. A section index refers to a sublist of iAddressCardsByLetter. A tab index points to a particular tab in the index tab image. There used to be a direct correlation between a section index and a tab index. By creating a mapping table, index tabs can support a more flexible mapping between the tabs and the section lists. For example, the Japanese name card index tab is not even in the same order as the contents of iContactsMasterList. Index tabs now assume much less about alphabetic order. The new class IndexTabMappingTable knows how to map between tab numbers and section numbers, and knows what ranges of characters each tab represents.

The mapping table supports three formats. The simplest mapping specifies just the start character. Sections are assumed to be in cardinal order as are the tabs. Each section must have the same number of "first letters" and each first letter must be a single character. This is the format that is used for the U.S. name cards file.

The second format provides a more general mapping for index tabs to map to a single character. This format specifies a start and end character for each section. Each section also specifies which tab it is associated with, allowing tabs to be associated with sections in a somewhat arbitrary order. This is the format used for the Japanese name cards file.

The third format provides the most general mapping. It allows each tab to have multiple characters. For example, you might have tabs "S" or "Sch". This mapping can only be used if the default sort order knows about such initials.

Class IndexTab is an abstract class that defines the interface for using index tabs. NameCardsSceneIndexTab and ListViewIndexTab are subclasses that are specific to the tabs in the name cards scene and the tabs in list views. Each subclass of IndexTab needs to provide implementations of TabSelected(), CurrentIndexItem() and ListIsEmpty(). TabSelected() updates the display and the highlighted tab depending on which tab was tapped. CurrentIndexItem() returns the currently "selected" item (the current card in the name cards scene or the currently selected item in a list view). ListIsEmpty() returns whether the list that the index tabs are managing is empty.

Class ContactsMasterList defines a setter for the attribute NumberOfComponentLists() which specifies the number of sections that appear in the name cards file. This is set by the locale package and will be different for different countries.

It's now possible to enter more than one line as the street address. Added a switch in the street address edit steps that toggles the AttributeWindow_LargerLowAttributeField() attribute.

The Rosemary Magic Cap API tries to avoid having multiple operations have the same name but different interfaces. Since Magic Cap doesn't do polymorphism, this is just plain confusing. Many operations have been removed or renamed to avoid this problem. All occurences of Entity() in Magic Cap are now attributes. Some classes had defined two operations, Entity() and SetEntity().

Tapping on an e-mail address in the address panel will create a new telecard, much like tapping on a phone number in the phone panel will dial that number.

Tapping on the new button in the name cards scene now automatically creates a name card for a person. A button has been added to the lamp that allows you to create new groups. The edit steps for entering the initial information on a name card has a switch that lets you decided whether this is really a person, or if it's a company.

NameCard_SetContact will only work with FullContact objects. Don't pass in a SimpleContact object.

NameCardsScene_RemoveDisplayedContact renumbers any remaining duplicate name contact addresses. This will cause the removal of the "(2)" after one of the duplicates is deleted.

The PeopleAddressPicker class has been removed. This was used in 1.x for automatic mail forwarding to a chosen contact address.

Removed the operation AddressPanel_ScrollToLabel. This was introduced in Magic Cap for Windows '95, but the implementation has not been updated to work with Rosemary.

Defined the new operation AddressLabelStamp_ComposeNameFromAddressInfo, which changes the name of an address label stamp to be of the form "name (description)". The name is the result of calling IdentifyingName() on the stamp's label's entity, and the description is the label's description.

The PeopleListTarget class has been made a mixin, so you should now inherit the class instead of just the interface. PeopleListTarget also provides a default implementation for EditStepsForNewEntity(), so it is no longer necessary to always override this operation to provide an implementation.

A new mixin class has been created to define the interface for objects which can appear in the name card log. This class, CanBeInNameCardLog, defines operations that are used to get information displayed in the log: DateForLog(), SubjectForLog(), and TypeForLog. These operations are declared as noMethod. Classes that inherit from CanBeInNameCardLog must implement these operations. The Task, PhoneCallCard and Telecard classes now inherit from CanBeInNameCardLog.

Moved address card merging operations from NameCardsStack to NameCardsScene. Many operations that used to take name cards as parameters now take address cards instead. Many operations have been moved to class ContactsMasterList as part of this change. Some operations have been renamed in the process.

Classes affected by these changes

Number formatting

Rosemary provides operations for formatting binary numbers (integer, fixed or floating point) into human readable strings, and to interpret numeric strings back into a binary number. This functionality is localizable so that numbers will be formatted in standards that international users are accustomed to. The high level interface is defined by the class Math. The low level interface is defined by the abstract class NumberFormatter, which provides the interface to format numeric strings in localized formats.

Magic Cap has always had the feature of cleaning up phone numbers by adding parenthesis and dashes in the appropriate places in the number. This functionality is a localizable service in Rosemary, and is encapsulated in the PhoneNumberFormatter class. This class will be able to format phone numbers for different countries in the proper format for that country.

The classes Money and FormattedMoney have been removed because the new localizable framework provides the interface for displaying formatted currency.

The Rosemary Magic Cap API tries to avoid having multiple operations have the same name but different interfaces. Since Magic Cap doesn't do polymorphism, this is just plain confusing. Many operations have been removed or renamed to avoid this problem. Removed the operation ValueToText(). Numeral() should be used instead.

Classes affected by these changes