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/
<https://people.gnome.org/%7Egcampagna/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.chime...@gmail.com <mailto:philip.chime...@gmail.com>> wrote:
On Mon, Dec 7, 2015 at 1:26 AM, Andrea Giammarchi
<andrea.giammar...@gmail.com <mailto:andrea.giammar...@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
<http://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 <http://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
_______________________________________________
javascript-list mailing list
javascript-list@gnome.org
https://mail.gnome.org/mailman/listinfo/javascript-list
