Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: current
    • Fix Version/s: None
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      220

      Description

      We are working to put the Desktop package into Mustang now. Here would be the
      place to gather all the feedback for JDIC Desktop API to meet J2SE API
      defination standard.

        Issue Links

          Activity

          Hide
          paul_huang added a comment -

          Reassigned to Paul

          Show
          paul_huang added a comment - Reassigned to Paul
          Hide
          paul_huang added a comment -

          Feed back from Denis@AWT team:
          1. Make Desktop class obtained through the static-factory method. Convert all
          method to non-static.
          Use case would be
          ----------------------------------------
          Desktop desktop = Desktop.getDesktop();
          desktop.open("c:
          test.txt");
          desktop.print("c:
          test.txt");
          ------------------------------------------
          Static methods limit the potential of extension in the future. With an instance
          acquired from the factory, you can then manage appcontext-sensitive
          configuration settintgs, enforce security, etc.

          2. Add isSupported method for all atomic actioins - browse, edit, print, open,
          mail.

          3. Make Class Message an internal class for Desktop.

          4. Change the return type of all get method of Class Message to be list instead
          of an interator.

          5. Specify that the implementation of mail() API converts the string to UTF8 to
          work around the Unicode handling problem within native mail applications, or it
          wouldn't pass the JCK.

          6. Use File object list instead of String object list to speicfy the attachment
          info.

          7. Add more detail to the documentation of each method and class.

          Show
          paul_huang added a comment - Feed back from Denis@AWT team: 1. Make Desktop class obtained through the static-factory method. Convert all method to non-static. Use case would be ---------------------------------------- Desktop desktop = Desktop.getDesktop(); desktop.open("c: test.txt"); desktop.print("c: test.txt"); ------------------------------------------ Static methods limit the potential of extension in the future. With an instance acquired from the factory, you can then manage appcontext-sensitive configuration settintgs, enforce security, etc. 2. Add isSupported method for all atomic actioins - browse, edit, print, open, mail. 3. Make Class Message an internal class for Desktop. 4. Change the return type of all get method of Class Message to be list instead of an interator. 5. Specify that the implementation of mail() API converts the string to UTF8 to work around the Unicode handling problem within native mail applications, or it wouldn't pass the JCK. 6. Use File object list instead of String object list to speicfy the attachment info. 7. Add more detail to the documentation of each method and class.
          Hide
          paul_huang added a comment -

          1. Will follow Denis's suggestion to provide static-factory and make all other
          methods non-static methods.

          2. Provide a new API isSupported(String actionName, File file). The actionName
          will specify the action type and the file will specify the file to be operated.
          With this API introduced, the two APIs isEditable() and isPrintable() will be
          removed.

          3. Consider changing the API mail(Message message) to mail(URL). Developers
          would be requried to specify the message as an Mailto URL. In this way, the
          class Message will be removed.

          4. Will not consider this if we are going to remove the Message class. Or we
          will change all the return type as a List (copy of the internal reference) for
          all the get methods of the Message class.

          5. Will specify in Javadoc.

          6. Use File object list instead of String object list to speicfy the attachment
          info.

          7. Will enrich the document.

          Show
          paul_huang added a comment - 1. Will follow Denis's suggestion to provide static-factory and make all other methods non-static methods. 2. Provide a new API isSupported(String actionName, File file). The actionName will specify the action type and the file will specify the file to be operated. With this API introduced, the two APIs isEditable() and isPrintable() will be removed. 3. Consider changing the API mail(Message message) to mail(URL). Developers would be requried to specify the message as an Mailto URL. In this way, the class Message will be removed. 4. Will not consider this if we are going to remove the Message class. Or we will change all the return type as a List (copy of the internal reference) for all the get methods of the Message class. 5. Will specify in Javadoc. 6. Use File object list instead of String object list to speicfy the attachment info. 7. Will enrich the document.
          Hide
          paul_huang added a comment -

          Add dependency to Issue 240.

          Show
          paul_huang added a comment - Add dependency to Issue 240.
          Hide
          pietschy added a comment -

          > 3. Consider changing the API mail(Message message) to mail(URL). Developers
          > would be requried to specify the message as an Mailto URL. In this way, the
          > class Message will be removed.

          Can attachments be added using the mailto url? If not (or if it's difficult) I
          would prefer to retain the Message object (or find an elegant way to support
          attachments).

          Show
          pietschy added a comment - > 3. Consider changing the API mail(Message message) to mail(URL). Developers > would be requried to specify the message as an Mailto URL. In this way, the > class Message will be removed. Can attachments be added using the mailto url? If not (or if it's difficult) I would prefer to retain the Message object (or find an elegant way to support attachments).
          Hide
          georgez added a comment -

          A branch "Issue_220" was created for the API and implementation revising for the
          inclusion in Mustang. Check out the latest API spec and implementation code from
          there.

          Show
          georgez added a comment - A branch "Issue_220" was created for the API and implementation revising for the inclusion in Mustang. Check out the latest API spec and implementation code from there.
          Hide
          keithkml added a comment -

          I'm pretty sure "DesktopLauncher" or "ApplicationLauncher" would be a better
          name. This package has no more to do with the desktop than the system tray or
          file types API do.

          Show
          keithkml added a comment - I'm pretty sure "DesktopLauncher" or "ApplicationLauncher" would be a better name. This package has no more to do with the desktop than the system tray or file types API do.

            People

            • Assignee:
              armin_chen
              Reporter:
              paul_huang
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: