Re: GJS Status

[Alan Knowles <alan roojs com>]

Hi,
most of this code parsers the introspection data,
https://git.gnome.org/browse/introspection-doc-generator/tree/Introspect

it's used to generate the documentation here (it's getting quite old though now)
http://www.roojs.com/seed/gir-1.2-gtk-3.0/gjs/WebKit.html

The seed documentation is slightly better than gjs (as that is what I used first) - from what i remember it does not document return values that well for gjs.

If you are spawning... - I did wrap that up at one point here
http://git.roojs.com/?p=gitlive;a=blob;f=Spawn.js;h=4d9f202373cb111b47cb3c2eac0db4de405e0deb;hb=HEAD

Gives out quite a few features like tracking the io, backgrounding etc...

I'm not sure if the gir modifications in that file are relivant - I've actually ported most of my seed code to vala now.

Regards
Alan



On Tuesday, December 08, 2015 05:17 PM, Andrea Giammarchi wrote:

Now that's what I call a welcome email, full of info: Thank You!!!

I'd love to know more about Jasper St. Pierre idea. I'm playing with an experimental distro (on github, if interested I'll drop a link) based on ArchLinux that bootstraps into Weston on Wayland backend and GTK3 (GJS based) in 8 seconds, on a Raspberry PI, and it also launches node.js so the stack is 100% _javascript_ (who would have bet years ago?!)

About the documentation, I don't actually parse it: I just read all file names (https://github.com/WebReflection/jsgtk/blob/master/python-to.js) and based on these I create the file that will optionally make the API camel case.

As far as I have used _javascript_ (15+ years at this point) in both Web or Rhino/Nashorn/node/Server projects, methods and properties have always been camelCase.

I found it convenient to have it like it is now (I guess simpler to document and "Google |  grep" with its PyGTK counterpart) but I'm used too much to camelCase and having a lightweight opt-in that does not compromise internals seemed like a good choice to me.

However, I'd like to generate Gtk and WebKit namespace too (or all others different from  GObject, GLib, and Gio in this link https://people.gnome.org/~gcampagna/docs/ which is mentioned in this page https://wiki.gnome.org/Projects/Gjs/Documentation) for both reading files and also to document myself locally instead of bothering some GNOME or Github server ;-)

Would this procedure via Ruby you've mentioned make it possible to have all those files generated as well? Right now as soon as I make it stops after static folder is parsed with anything in the generated list.

About node.js

For me it wasn't a love or hate story on its API, it's rather the entry point to npm.

As example, now that I have a working `require` function instead of needing to re-polyfill again Promises for js24, I can simply do this:

```js

const Promise = require('es6-promise').Promise;

new Promise(function (res, rej) {

  setTimeout(res, 500, 'it worked!');

}).then(log);

```

That just worked via jsgtk. And please note jsgtk is not just a couple of helpers, core functionalities (https://github.com/WebReflection/jsgtk/tree/master/jsgtk) make it already compatible with a wide range of modules.

For instance, my last push from yesterday introduced Readable and Writable streams so that I can now communicate asynchronously within separate channels via spawn and, let's say, sqlite3 (or module based on this such dblite in npm, which now works too)

```js

let sqlite3 = require('child_process').spawn('sqlite3');

sqlite3.stdin.write('SELECT 123;\n');

sqlite3.stdout.on('data', (data) => {

  log(data);

  sqlite3.disconnect();

});

```

Thanks to this simplified spawn, where I couldn't find documentation, I could workaround interacting directly with nodejs like I've done for the os module: https://github.com/WebReflection/jsgtk/blob/master/jsgtk/os.js (I had hard time finding out how to retrieve valid network interfaces and their info via GJS)

Not ideal, but it works. jsgtk is also far away from perfect or complete ... but it kinda works already.

As final point about node.js, its documentation is superior for the simple reason that every module, constructor, or event, is described with examples too while the best documentation I could find about GJS and its most basic functionalities is in Japanese (I guess) http://foreachsam.github.io/book-lang-_javascript_-gjs/book/index.html

I'm willing to help improving GJS documentation,  least through my blog, but regarding `jsgtk` ... well, contributors are **more** than welcome so please have a look if you're interested and ping me whenever you want.

Best Regards

On Tue, Dec 8, 2015 at 6:02 AM, Philip Chimento <philip chimento gmail com> wrote:

On Mon, Dec 7, 2015 at 1:26 AM, Andrea Giammarchi <andrea giammarchi gmail com> wrote:

First of all, I'd like to say hello to everyone. I've been using GNOME on ArchLinux for more than a year now and I love pretty much everything about it.

Recently I've found GJS project and I've started playing with it making it more "JSish" than "Pythonic" and implementing partially some node.js core API and functionalities such require, fs, path, os, with some synchronous and asynchhronous API too.

Hello, welcome.

You might want to check in with Jasper St. Pierre (Jasper on IRC), he has been interested in bootstrapping the Gnome stack onto Node.js.

 

So far, so good ... however, there are 2 main questions I'd like to ask about GJS:

  1. is this project still alive? It works like a charm but repositories look untouched for long time

Yes, there was a 1.44.0 release just last month. It's not the most active GNOME project though.

 

  2. is it posible to know how to generate the Giovanni's documentation? I've talked with him directly and apprently he's not working on that branch anymore but beside static assets that are present in such branch, all generated content fails to build (tried in ArchLinux, Ubuntu) and I've no idea what I should do in order to generate the documentation for Gtk-3.0 or Gdk and others that are not Gio, GObject, and GLib.

The result of the parsing of such documentation  gives me the ability to create files like the following one: https://github.com/WebReflection/jsgtk/blob/master/jsgtk/gi.js

Since the Proxy implemented in  js24 seems to fail if used directly as Gtk instance, that's the way to tarnsform all accessors and methods from lower_case to camelCase but this is only one part of the project, the rest will be at some point documented as long as I understand it's worth keep improving it.

I would strongly recommend that you not parse the documentation but instead parse the GIR files directly.

Even better would be, in my opinion, to write some code on the C side of things to handle both underscored and camelcased methods. Here's where it's done for GObject property names: https://git.gnome.org/browse/gjs/tree/gi/object.cpp#n282

(I suspect a change like this would be controversial, though; I'm not sure of the reason why it was originally done for GObject properties and not methods, but hardly any existing GJS code that I've seen takes advantage of camelcased properties.)

Coincidentally I've been working off and on, on getting the GJS documentation into a local instance of devdocs.io. If you want to try it out, build this branch of gobject-introspection (https://github.com/ptomato/gobject-introspection/tree/wip/ptomato/devdocs) and check out this branch of devdocs (https://github.com/ptomato/devdocs/tree/gir-redux). In your Ruby environment run "thor gir:generate_all" then "thor gir:generate gio --force" (repeat the last one for whichever GIR documentation you want to generate), then "rackup" to start the webapp.

 

Right now the quick demo I can provide is that if you `npm install jsgtk` in a folder that contains a `node_modules` directory and you create a `hello-world` like the following

```

#!/usr/bin/env sh

imports=imports// "exec" "gjs" "-I" "$(dirname $0)/node_modules/jsgtk/" "$0" "$@"

let {console} = imports.jsgtk;

console.info('Hello jsgtk!');

```

and you `chmod +x hello-world` and run it or simply `sh hello-world` you should see the message in console.

Thanks for any sort of info or comment or clarification.

 

Personally I'm not a fan of Node.js's API, rather see something with promises than more callback hell, but it would indeed be nice to have some sort of standard module that lowers the barrier of entry for people new to Gnome who are used to web development. But that's my opinion and I'm not a GJS maintainer, just a heavy user.

Satyajit Sahoo who I think reads this list, also has something similar: https://github.com/satya164/gjs-helpers

Regards,

--

Philip

_______________________________________________
_javascript_-list mailing list
_javascript_-list gnome org
https://mail.gnome.org/mailman/listinfo/_javascript_-list