SourceForge Logo
  [overview]  [Waba]  [status]  [links]  [screenshots]  [survey]  [SF:summary]   [SF:downloads]  [SF:CVS]

 Survey / result March 12, 2001
 
General questions


 G1. Do you think it's OK to integrate SuperWaba in this CVS tree ?
    18 answers
    15 yes
    3 no

G2. Do you think SuperWaba should replace the standard classes and become part of the standard Waba platform (vs being an option, like currently) ?
    18 answers
    10 yes
    8 no

G3. Should Waba on SourceForge (this project) become the central point for:
  • Waba VM
      • 18 answers
      16 yes
      2 no

  • Waba core packages
      • 18 yes
      0 no

  • Waba non-core packages
      • 17 answers
      6 yes
      11 no

  • Waba applications and applets
      • 17 answers
      6 yes
      11 no

  • other: no answer

G4. Do you intend to contribute to the VM (=core) development:
  • for the Palm port ?
      • 19 answers
      6 yes
      13 no

  • for the Win32/PocketPC port ?
      • 18 answers
      4 yes
      14 no

  • for the Linux/uClinux port ?
      • 18 answers
      7 yes
      11 no

G5. Do you intend to contribute to the development of additional (=non-core) java packages for Waba ?
      19 answers
      15 yes
      4 no

  • Do such packages require development of native methods ?
      • 15 answers
      9 yes
      7 no

G6. Which GUI model do you (intend to) use ?
  • Waba / color Waba
      • 16 answers
      9 yes
      7 no

  • SuperWaba
      • 17 answers
      10 yes
      7 no

  • AWT if available
      • 15 answers
      6 yes
      9 no

  • MIDP (object model for mobile phones) if available
      • 17 answers
      4 yes
      13 no

G7. Are you interested in other usages of the VM than applications, such as:
  • real applets
      • 18 answers
      8 yes
      10 no

  • drivlets
      • 18 answers
      7 yes
      11 no

  • other:
      • - embedded java


Technical questions

T1. Should we have only one object model for both Black+White and color widgets (i.e. the classes detect the platform's capability and do the rendering accordingly) ?
    19 answers
    18 yes
    1 no

T2. Compatibility issues due to the specificities of the different platforms:
  • The PalmOS has blocking IOs, which makes the lack of threads particularly annoying (yet solvable with timer). Should the Palm port simulate non-blocking IOs in the VM, if technically possible ?
      • 15 answers
      11 yes
      4 no

  • Should the Catalog classes be provided for all ports to insure portability ?
      • 17 answers
      15 yes
      2 no

  • Should the filesystem be simulated on Palm ?
      • 18 answers
      14 yes
      4 no

T3. Should the JAR format be supported (at least for non-Palm platforms) ?
    18 answers
    15 yes
    3 no

Other suggestions:

- All clones and modifications should be merged into the project, IMHO.

- I would most heartily recommend that the waba.xx original package be preserved and everything else, (eq super-waba, or waba jump) be done via sub-packages (eg waba.super.fx, etc)

- I'd like to have a CommonWaba specification, combining the best of SuperWaba, ColorWaba and WabaCE, but in a portable fashion. E.g. to the application programmer, it shouldn't matter what platform the program runs upon, a portable call to create a button should give a button with a look-and-feel consistent with the rest of the program and with the platform's defaults. 		 

  © 2000-2001   Last Update: November 14, 2024