The Mozilla
Organization
At A Glance
Feedback
Get Involved
Newsgroups
License Terms
Newsbot
Developer Docs
Roadmap
Projects
Ports
Module Owners
Hacking
Get the Source
Build It
Testing
Download
Bugzilla
Bug Writing
Tools
View Source
Tree Status
New Checkins
Submit A Bug
FAQ
Search


XPFC Resources

The Julian Calendar Team
August 19, 1998

Index


Introduction

This document describes how XPFC will deal with platform independent downloadable resources for application UI's.

Consumers of these resources include XPFC Dialogs and Application Widgets

General Dependencies

All known technical dependencies exist today:
  • modularized libpref
  • modularized javascript

Format

Benefits
The format of resource files will follow that of existing Communicator preferences files, ala prefs.js. The benefits of doing this are:
    1. Mission Controllable Resources
    2. Arbitrary JavaScript scripting within the resource files themselves
Syntax
Generally, preferences are stored as key/value pairs syntactically appearing as function calls, ie:
user_pref("preference.subpref.key","value");
The syntax of the value part depends upon its type (ie Rect, Int, Bool).

TODO: Put description here with further examples.

Resources will follow the same key/value pair syntax, but use function calls equivalent to their references XML tag attribute names.  For instance, the label attribute of the menuiten tag will reference its resource as:

label_pref("key","value");
 
Accelerator and Shortcut preferences can refer to the escape sequences found in table 1 below for referencing keyboard modifiers.

XML Reference

Use the LINK tag to refer the resource file in your XML definition
<LINK HREF = "resource://resources.js" TYPE="application/resources">
When referenceing actual resources, use the symbol "$" to refer to a resource file:
<SOMETAG SOMEATTRIBUTE="$SOMEKEY">
The above reference would expect the following in the resource file:
someattribute_pref("SOMEKEY","The Actual Referenced Value");
Keyboard Reference

The following tables shows the string sequences used to refer to platform-specific keyboard modifier keys:
Mac Unix Windows Letter
Apple Meta Alt \a
Shift Shift Shift \s
Ctrl Ctrl Ctrl \c
F# F# F# \F#
Option <nil> <nil> \o

The default Accelerator sequence is '\a'.
The default Shortcut sequence is '\c\.

Notes:

  1. that 'F#' referes to the Numbered Function Keys on top of the keyboard.
  2. The Apple on Macintosh Systems is mapped to the Alt on Windows and Meta on Unix by default.
  3. When referring to the Option key on Mac systems, Unix/Windows currently will ignore that key sequence.

Issues

  1. What to do about DBCS support in parsing JavaScript files
  2. Can Javascript support appVersion and platform as defined by our client (ie window.navigator.appVersion is something like window.calendar.appVersion). How do we define more types as we need for javascript to understand as builtin objects.
  3. Should the Option Key on Mac systems also map to the Alt/Meta keys on Win/Unix?

Example

Following are some examples of useage in describing a menuitem which has platform specific accelerators and platform independent command key sequences. The example shows how to nicely separate out the resources  for easy localization.

FILE: resource.js

// common to all platforms prefs
label_pref("close", "close")
accelerator_pref("close", "C") // "Alt/Meta/Apple-C"

 // mac prefs only
if (app.platform.class == "macintosh")
{
    shortcut_pref("close", "\AW"); // "Apple W"
}
 // win prefs only
if (app.platform.class == "windows")
{
    shortcut_pref("close", "\A\F4"); // "Alt-F4"
}
 // unix prefs only
if (app.platform.class == unix)
{
      shortcut_pref("close", "\CX");    // "Ctrl-X"
}

FILE: menuitem.xml

<link href = "resource://resource.js">

<ui>

< ! example of menuitem using localized strings (close window)>
<menuitem label = "$close" command = "$close" shortcut = "$close" />

</ui>

History

Who When What
spider 8/19 Initial Document

Copyright © 1998-1999 The Mozilla Organization.
Last modified January 15, 1999.