It looks as if the `patch` map can only change the output for elements in the gir data, not add new elements, so I guess `exportObjectInternal` is where I could add members to the data to make that work. Unfortunately though, `registerClass` is a global function, not a method, so I don't think that would work for it. I should add the `_init` method though, which GObject classes are supposed to use instead of constructors, and `patch`/`exportObjectInternal` would probably be a good way to do that.
The first line of gjs/modules/overrides/GObject.js is: /* exported _init, interfaces, properties, registerClass, requires, signals */ The four other exported things there I haven't already mentioned are JS symbols used as keys for fields providing meta-data in GObject.Object. Would it be a good idea to add those symbols and fields to ts-for-gjs' output? On Wed, 14 Nov 2018 at 17:09, <makep...@firemail.cc> wrote: > For methods added by Gjs, like GObject.registerClass, I'd put them into > the `patch` map at the end of `main.ts`, where now are substituted lines > and comments for clashing and overriden definitions. Basically what you > suggest, but keys are more specific like "library.class.method". Or you > can add another map if turns out really more convenient. > > Then look into the `exportObjectInternal` method, which generates > definitions for a given introspected class. Search for `connect` there, > and def.push `registerClass` and your other definitions similarly if > `cls._fullSymName` equals to "GObject.Object" or the other class you > need. > > For imports.package, imports.system etc you'd need to look through the > `exportGjs` method in `main.ts` and hardcode a few new exports with > method signatures. > -- TH
_______________________________________________ javascript-list mailing list javascript-list@gnome.org https://mail.gnome.org/mailman/listinfo/javascript-list
