dart-gde/chrome_gen.dart

Deprecated! See dart-gde/chrome.dart

chrome_gen.dart's Issues

Find out what "nocompile" and "nodoc" annotation mean?

Anything with a nocompile and nodoc should be removed from the idl model/transformation part to the chrome model. @devoncarew do you know who we could confirm this with?

app_window.idl:

[nocompile, nodoc] static void initializeAppWindow(object state);

windows.dart does not get exported to chrome_app.dart

Not exactly sure why the mismatch is happening. It seems like when you call ChromeAppWindow.create the future object is a AppWindow which has a property AppWindow.contentWindow of type Window. That Window object does not have any Events to listen on. So the path that I find hard to figure out is if ChromeAppWindow.create is called how does one listen to events such as maximize, minimize, etc..

http://developer.chrome.com/apps/app_window.html#type-AppWindow

json parser does not parse enum information

JSON: Add support for parsing "choices" in property parameters

Some parameters contain properties that have choices. Meaning they can be multiple object types or objects of multiple types.

Example of setIcon function from browser_action.json where imageData could be a $ref of ImageDataType or a javascript object with additional properties and $ref

{
        "name": "setIcon",
        "type": "function",
        "description": "Sets the icon for the browser action. The icon can be specified either as the path to an image file or as the pixel data from a canvas element, or as dictionary of either one of those. Either the <b>path</b> or the <b>imageData</b> property must be specified.",
        "parameters": [
          {
            "name": "details",
            "type": "object",
            "properties": {
              "imageData": {
                "choices": [
                  { "\$ref": "ImageDataType" },
                  {
                    "type": "object",
                    "properties": {
                      "19": {"\$ref": "ImageDataType", "optional": true},
                      "38": {"\$ref": "ImageDataType", "optional": true}
                     }
                  }
                ],
                "optional": true,
                "description": "Either an ImageData object or a dictionary {size -> ImageData} representing icon to be set. If the icon is specified as a dictionary, the actual image to be used is chosen depending on screen's pixel density. If the number of image pixels that fit into one screen space unit equals <code>scale</code>, then image with size <code>scale</code> * 19 will be selected. Initially only scales 1 and 2 will be supported. At least one image must be specified. Note that 'details.imageData = foo' is equivalent to 'details.imageData = {'19': foo}'"
              },
              "path": {
                "choices": [
                  { "type": "string" },
                  {
                    "type": "object",
                    "properties": {
                      "19": {"type": "string", "optional": true},
                      "38": {"type": "string", "optional": true}
                    }
                  }
                ],
                "optional": true,
                "description": "Either a relative image path or a dictionary {size -> relative image path} pointing to icon to be set. If the icon is specified as a dictionary, the actual image to be used is chosen depending on screen's pixel density. If the number of image pixels that fit into one screen space unit equals <code>scale</code>, then image with size <code>scale</code> * 19 will be selected. Initially only scales 1 and 2 will be supported. At least one image must be specified. Note that 'details.path = foo' is equivalent to 'details.imageData = {'19': foo}'"
              },
              "tabId": {
                "type": "integer",
                "optional": true,
                "description": "Limits the change to when a particular tab is selected. Automatically resets when the tab is closed."
              }
            }
          },
          {
            "type": "function",
            "name": "callback",
            "optional": true,
            "parameters": []
          }
        ]
      }

Other json idl also contain this structure.

bookmarks.json:            "choices": [
browser_action.json:                "choices": [
browser_action.json:                "choices": [
browser_action.json:                "choices": [
context_menus.json:            "choices": [
context_menus.json:            "choices": [
context_menus.json:          "choices": [
context_menus.json:                "choices": [
context_menus.json:            "choices": [
context_menus.json:                "choices": [
context_menus.json:            "choices": [
declarative_web_request.json:            "choices": [
declarative_web_request.json:            "choices": [
grep: devtools: Is a directory
events.json:              "choices": [
experimental_accessibility.json:            "choices": [
idltest.idl:    // we might be able to do is have a 'choices' list including all the
page_action.json:                "choices": [
page_action.json:                "choices": [
processes.json:            "choices": [
storage.json:                "choices": [
storage.json:                "choices": [
storage.json:                "choices": [
tabs.json:                 "choices": [
tabs.json:            "choices": [
tabs.json:                "choices": [
tabs.json:            "choices": [
test.json:            "choices": [
test.json:            "choices": [
test.json:            "choices": [
test.json:          {"choices": [ {"type": "string"}, {"type": "object", "isInstanceOf": "RegExp"} ], "name": "message", "optional": true}
windows.json:                "choices": [

Solution for handling this is still in discussion.

Error when reading values from CrFile

When making calls to CrFile.name, the following error is thrown:

Uncaught Error: Class 'File' has no instance method '[]'.

NoSuchMethodError : method not found: '[]'
Receiver: Instance of 'File'
Arguments: ["name"]
Stack Trace: 
#0      Object.noSuchMethod (dart:core-patch/object_patch.dart:42)
#1      CrFile.name (package:chrome_gen/src/files.dart:336:29)

This happens because CrFile reads its values from jsProxy using map notation. At least when getting files using CrFileEntry.file(), the object passed to CrFile.fromProxy() is an HTML File object. So values should be read using dot notation.

convert map parameter into a series of required, optional, and named parameters

We should look onto converting a map parameter into a series of required, optional, and named parameters into the method. For some context:

The largest disadvantage is all of the places where an API takes a Map with limited structure, and your code has to give up because it doesn't know what keys are expected (e.g. compare https://github.com/dart-gde/chrome_gen.dart/blob/master/lib/gen/browser_action.dart#L25 to https://github.com/dart-gde/chrome.dart/blob/master/lib/src/browser_action.dart#L29).

Looking at the .json sources (https://code.google.com/p/chrome-documentation-chs/source/browse/documentation/branches/stable/extensions/api/browser_action.json?r=729e9197586823aaee8c4ee2734612ff293996ea#31) it looks like the necessary information is available. If you can update your script to take advantage of the properties info that would be great.

Handle multiple callback parameters by creating new class

Reviewing some of the .idl files it looks like a few of them might use multiple parameters for callbacks.

audio.idl:

  callback GetInfoCallback = void(OutputDeviceInfo[] outputInfo,
                                  InputDeviceInfo[] inputInfo);

file_system.idl:

  callback EntriesCallback = void (
      [instanceOf=Entry] optional object entry,
      [instanceOf=FileEntry] optional object[] fileEntries);

The multiple parameters for a callback - this is a situation that we should handle but currently punt on in both the json parser and the code gen. We just use 'dynamic' in these cases, but should move to something like generating a new class just for this specific callback / Future return.

0.0.5?

I'd like to push the ArrayBuffer changes in the next day or two. It's not hugely time-critical; if there are other changes people want in we can batch things up.

Arrays/Lists are not properly generated from IDL

Examples of callbacks that do it incorrectly:

alarms.idl:

    callback AlarmListCallback = void (Alarm[] alarms);

    // Gets an array of all the alarms.
    static void getAll(AlarmListCallback callback);

alarms.dart:

  /**
   * Gets an array of all the alarms.
   */
  Future<Alarm> getAll() {
    var completer = new ChromeCompleter<Alarm>.oneArg(_createAlarm);
    _alarms.callMethod('getAll', [completer.callback]);
    return completer.future;
  }

NOTE: finding the list of improperly handled arrays.

~/dart/gen_tools.dart/idl
$ grep "\[\]" *.idl|less

Should never generate 'var' as a param type

New Event.hasListener(var callback)

should never generate var
How to handle callback types?

A lot of event types with complex properties just end up with `Map`

TabsOnMovedEvent.moveInfo
OnSelectionChangedEvent.selectInfo

etc

Need smarter generation here...

Chrome_gen.syncfs should return FIleError instead of JsProxy object

The chrome_gen.synfs dart API returns JsProxy objects as errors while they are standard Html.FIleError

We need a wrapper around the error, to return dart FileError objects.

issue parsing multiple dictionary members in a dictionary

See app_window.idl and app_window.dart. The generated AppWindow class only has one property defined, but should have ~12. I think only the last dictionaryMember is being included in the dictionary?

jsify needs to be improved

From googlearchive/chromedeveditor#382 (comment)

Having a quick look at chrome_gen.dart there are several places where you don't call .jsProxy on ChromeObject. Particularly when you have a List of ChromeObject on which you call jsify (like https://github.com/dart-gde/chrome_gen.dart/blob/master/lib/gen/file_system.dart#L169). Since js.Serializable has been removed you have to write your own jsify that handle the calls to xxx.jsProxy.

We need to do a better job of converting Dart data structures into JS ones. In particular, when converting lists, we also need to convert each entry in the list.

bad code gen for fileSystem.ChooseEntryResult

We're generating it as:

class ChooseEntryResult {
  Entry entry;
  FileEntry fileEntries;
}

but should be generating it as:

class ChooseEntryResult {
  Entry entry;
  List<FileEntry> fileEntries;
}

update generation pipline

change from a (json text | idl text) ==> idl model ==> dart code pipline to a

json text ==> json model ==> chrome model ==> dart code
and
idl text ==> idl model ==> chrome model ==> dart code

pipline. I.e., introduce json and idl specific models. This will allow much of the chrome library smarts to reside in the chrome model code. It also means that the parsing code can be simpler for both json and idl. They just translate into models that are easy for them to produce. Those models are then translated into a common chrome lib model. This will also make it easier to facilitate multiple backends for code generation.

Handle instanceOf type assignment for parameters in IDL files

IDL

  callback GetTabMediaCallback =
      void ([instanceOf=LocalMediaStream] object stream);

  interface Functions {
    static void capture(CaptureOptions options,
                        GetTabMediaCallback callback);
  }

Will generate

  Future<dynamic> capture(CaptureOptions options) {
    ChromeCompleter completer = new ChromeCompleter.oneArg();
    _tabCapture.callMethod('capture', [options, completer.callback]);
    return completer.future;
  }

But should generate

  Future<LocalMediaStream> capture(CaptureOptions options) {
    ChromeCompleter completer = new ChromeCompleter.oneArg();
    _tabCapture.callMethod('capture', [options, completer.callback]);
    return completer.future;
  }

When we do parse instanceOf, just putting its value into the refName field of IDLType should be enough for the generation framework to do the right thing.

#21

Why the static `create` methods?

Why not use the normal constructors?

Bring unit tests over from chrome.dart

Bring tests over from package:chrome. https://github.com/dart-gde/chrome.dart

Could most instances of `Map` be `Map<String, dynamic>`

When we're talking about Javascript hashes, we know the key is always a string

instanceOf annotation need to be picked up by the parser and generate proper type

When we see an object we should try and resolve with an annotation of instanceOf
Example idl code:

media_galleries.idl:

void ([instanceOf=DOMFileSystem] optional object[] mediaFileSystems);

app_window.idl:

void ([instanceOf=AppWindow] object created_window);

rev to 0.3.3?

Is there anything else you want to get in before the next point release? @financecoding

programmatically warn when APIs are not available

Some APIs - like system.cpu - require permissions set in the manifest.json file before they're available to be used. W/o those permissions, things fail in ways that are difficult to triage.

We should investigate detecting these failures, and throwing a Dart exception w/ a better error message.

For system.cpu, the ChromeSystemCpu._system_cpu field will be null. Perhaps put a check in the ctor?

dart:js changes

Serializable is going away imminently; the CL is out for review and will probably be in the next SDK. We should move away from relying on it, and explicitly generate calls to param.toJS().

@justinfagnani

Include idl documentation in generated code

some parameters passed in the wrong order

Our generation code sometimes passes parameters into JS methods in the wrong order, if some args are defined as optional. Will try and quantify this a bit more -

fix storage.dart

storage.dart is generating fields for sync and local, but these are just instances of StorageArea. We need to generate custom subclasses of StorageArea in order to expose the fields that are specific to the sync and local implementations. See storage.json.

Create generation gap type of system to override code with custom code

Thoughts on this type of pattern for the custom code overriding? @kevmoo @devoncarew

http://heikobehrens.net/2009/04/23/generation-gap-pattern/

http://eclipse.dzone.com/articles/new-ways-around-generation-gap

annotations.dart proxy

the new annotations.dart has a proxy annotation defined. This is interfering with references to a proxy instance variable we have defined on sub-classes of ChromeObjects. Most of chrome_gen breaks at runtime :(

We'll have to fix this (a relatively small fix), and get a new version out asap. The next version we were planning on landing (0.1.0) has some breaking changes.

@financecoding what's you timeframe for moving over to the new parser? Should we put it in 0.1.0, or make an 0.2.0 release w/ the parser soon after?

Generated Event.addListener, .removeListener missing a paramater

combine some APIs (app_runtime, app_window)

Combine some APIs into the same file, and add an accessor class. This would be for the app_window and app_runtime apis, as well as the devtools_* apis. Ex.

final ChromeApp app = new ChromeApp._();

class ChromeApp {
  ChromeRuntime runtime;
  ChromeWindow window;
}

add the ability to override a method (and class?) implementation with a custom, hand-written one

For things like chrome.fileSystem.chooseEntry(), which need custom logic when returning values.

There's also an API method that takes two callbacks (I can't locate it right now). That'll need a custom implementation as well.

Create wiki page on running unit tests.

https://github.com/dart-gde/chrome_gen.dart/wiki/Running-Unit-Tests

readme: `dart tool/gen_api.dart` does not generate library

I get the help message.

Tried running dart tool/gen_api.dart meta/apis.json

But get a null error.

More help?

Images for wiki

Adding images via a issue is easy.

Use parts of https://github.com/a14n/dart-js-wrapping?

Alexandre Ardhuin has a package to help automate exposing a JS library in Dart. You write a Dart interface that mirrors the JS API. He has a tool which parses that and generates an equivalent API which uses dart:js for interop.

https://github.com/a14n/dart-js-wrapping

He's created several utility classes which closely mirror some of our objects. From Alexandre:

The most important class is TypedJsObject which look really like your ChromeObject . There are some other similarities between my IsEnum and your ChromeEnum . You can also be interested by TypedJsArray that give you a Dart adapter to handle jsArray.

If his library gets traction, we could consider replacing our ChromeObject* classes with his implementations.

@kevmoo @financecoding @a14n

What should be done with collisions of class names?

Drone.io build is failing on error between similar dictionary/class names defined in bluetooth.dart and serial.dart.

$ dartanalyzer lib/chrome_app.dart
Analyzing lib/chrome_app.dart...
[error] The element 'ReadInfo' is defined in the libraries 'serial.dart' and 'socket.dart' (/home/ubuntu/src/github.com/devoncarew/gen_tools.dart/lib/chrome_app.dart, line 25, col 1)
[error] The element 'Device' is defined in the libraries 'bluetooth.dart' and 'usb.dart' (/home/ubuntu/src/github.com/devoncarew/gen_tools.dart/lib/chrome_app.dart, line 34, col 1)
[warning] Undefined class 'Level' (/home/ubuntu/src/github.com/devoncarew/gen_tools.dart/lib/gen/power.dart, line 18, col 25)
[warning] Undefined class 'SocketType' (/home/ubuntu/src/github.com/devoncarew/gen_tools.dart/lib/gen/socket.dart, line 18, col 17)
[warning] Undefined class 'ConflictResolutionPolicy' (/home/ubuntu/src/github.com/devoncarew/gen_tools.dart/lib/gen/sync_file_system.dart, line 24, col 38)
2 errors and 3 warnings found.

rev to 0.2.0?

Thoughts on rev'ing to 0.2.0? We've had some breaking changes in the API in the last ~few commits (https://github.com/dart-gde/chrome_gen.dart/pull/105/files).

Tracking issue for promoting package:chrome_gen to package:chrome

This issue is to get comments and people's thoughts about making chrome_gen the preferred chrome API library. So, something like:

• rename the package chrome_gen to chrome, and rename the github repo or move the contents into the chrome repo
• rename the package chrome to something like chrome_old, and swizzle the github repo contents accordingly. This way people that still need to depend on the old repo can do so

I think this work is predicated on getting the old chrome tests running with the new chrome_gen package, so we maintain existing test coverage.