waba-spec

[Waba-spec] Proposed Vm.java and Resource.java

[Sean L. <se...@cs...>]

After looking at Waba's and SuperWaba's Vm implementations, and knowing 
that implementation of the Class class will take longer than expected, 
allow me to make the following recommendation for a new Vm class:

Re: [Waba-spec] Proposed Vm.java and Resource.java

[Guilherme C. H. <gu...@us...>]

I'm changing today the Vm class. Here are the changes:

! removed some methods from class Vm and putted as constants in class
Settings. Below is the convertion table:
  . Vm.oldStyle==true  -> Settings.uiStyle == Settings.PalmOS
  . Vm.oldStyle==false -> Settings.uiStyle == Settings.WinCE
  . Vm.getScreenSize -> Settings.screenWidth,Settings.screenHeight
  . Vm.isColor -> Settings.isColor
  . Vm.getMaxColors -> Settings.maxColors
  . Vm.getUserName -> Settings.userName
  . Vm.getPlatform -> Settings.platform

Sean, thanks for your complains.

    guich

Re: [Waba-spec] Proposed Vm.java and Resource.java

[Sean L. <se...@cs...>]

Guilherme, I defined getMaxColors as follows in Vm.java:

    /** Returns the number of colors supported by the device.
      * Colors are defined as follows:

      * 0 means 2^32 colors.
      * 1 indicates a lookup table of colors or other custom coloring,
      * which will be defined later
      * -1 is reserved for future use.
      * 2 means black and white.
      * Other values <= 16 mean that the device only supports gray scale
      *     with that number of grays.
      * Negative values N also mean that the device only supports gray 
scale
      *     with AbsoluteValue(N) number of grays
      * All other values indicate colors, and the value is the number of 
colors
      *     actually supported.  The number of colors *may* include alpha,
      *     which you can ignore if you like.
      * If the number is a power of three, then alpha is not included.
      *
      * Some common values include:
      *
      * <ul>
        <li> 0&nbsp;&nbsp;&nbsp;8bit/R, 8bit/B, 8bit/G, 8bit/A
        <li> 1&nbsp;&nbsp;&nbsp;(lookup tables)
        <li> 2&nbsp;&nbsp;&nbsp;Black and White
        <li> 16&nbsp;&nbsp;&nbsp;16 grays
        <li> -256&nbsp;&nbsp;&nbsp;256 grays
        <li> 4096&nbsp;&nbsp;&nbsp;4bit/R, 4bit/B, 4bit/G
        <li> 32768&nbsp;&nbsp;&nbsp;5bit/R, 5bit/B, 5bit/G, [maybe 1bit/A]
        <li> 65536&nbsp;&nbsp;&nbsp;4bit/R, 4bit/B, 4bit/G, 4bit/A
        <li> 16777216&nbsp;&nbsp;&nbsp;8bit/R, 8bit/B, 8bit/G
        <li> 1073741824&nbsp;&nbsp;&nbsp;10bit/R, 10bit/B, 10bit/G, 
[maybe 2bit/A]
        </ul>
      * This odd definition is given in order to be backward-compatible
      * with SuperWaba.
      */
    public native static int getMaxColors();


However, I would PREFER to define a VM function like this:

    /** Returns the display capabilities of the device.  If the value
      * is positive, then it indicates the bits per pixel for each of
      * red, green, and blue.  If the value is negative, then its absolute
      * value indicates the number of gray values (bits per pixel) for a
      * grayscale display.  If the value is zero, then the display system
      * is custom, likely a lookup table, and must be dealt with 
specially.
      * Special handling has not been addressed as of yet.  Alpha is not
      * indicated. Some possible values include:
      *
      * <ul>
        <li> 0&nbsp;&nbsp;&nbsp;(custom, likely lookup tables)
        <li> -1&nbsp;&nbsp;&nbsp;Black and White
        <li> -16&nbsp;&nbsp;&nbsp;16 grays
        <li> -256&nbsp;&nbsp;&nbsp;256 grays
        <li> 4&nbsp;&nbsp;&nbsp;4bit/R, 4bit/B, 4bit/G  [maybe 4bit/A]
        <li> 5&nbsp;&nbsp;&nbsp;5bit/R, 5bit/B, 5bit/G  [maybe 1bit/A]
        <li> 8&nbsp;&nbsp;&nbsp;8bit/R, 8bit/B, 8bit/G  [maybe 8bit/A] 
"32-bit Color"
        <li> 10&nbsp;&nbsp;&nbsp;10bit/R, 10bit/B, 10bit/G  [maybe 2bit/A]
        </ul>
      */
    public native static int colorDisplay();

What would be the consequences for SuperWaba if we defined the spec 
display in this form?

Sean