It’s been a while since my last post, I was busy with my university exams and didn’t get much time to work on my GSoC project. But during whatever time I got I tried to get myself familiar with GNOME Shell coding style and get a hang of the way it works, since GNOME Shell is the main module I will be working with in this project. But things weren’t as simple as I initially thought them to be. It has been a struggle trying to find out some structured documentation for GNOME Shell code-base mainly the JavaScript part.
After a lot of searching I realized that although nothing much directly related to JavaScript is available but it’s not a complete blackout, there are some ways and materials available which can provide a pretty good understanding when put together. So here I would like to mention my findings, it might not be a complete list but I would try to cover most of the things that I found:
- First of all the blog that gave me a start. She really has covered a lot of things in there and have done a great job doing that, it really helped me a lot 🙂 :
Then next is GNOME Wiki which also contains a lot of information.
It’s the GNOME Wiki for GNOME Shell, each link inside that is worth a visit but some of the most important one’s are:
- https://wiki.gnome.org/Projects/GnomeShell/Development
- https://wiki.gnome.org/Projects/GnomeShell/Terminology
- https://wiki.gnome.org/Projects/GObjectIntrospection
- https://wiki.gnome.org/action/show/Projects/Gjs
- https://wiki.gnome.org/Projects/GnomeShell/Gjs_StyleGuide
- https://wiki.gnome.org/Projects/GnomeShell/Extensions/StepByStepTutorial (a very useful tutorial)
- There is also a huge amount of documentation available on https://developer.gnome.org/, it’s just the matter of finding the required one but two particularly useful links are:
- https://developer.gnome.org/gnome-devel-demos/unstable/
- https://developer.gnome.org/references (although these references are not directly for JavaScript but they can be mapped based on Gjs/mapping and Gjs_StyleGuide)
- https://people.gnome.org/~gcampagna/docs/ (auto-generated docs, generated from gir files)
- http://helgo.net/simon/introspection-tutorial/ (A tutorial on how to use GObject Introspection to access C codes from JavaScript)
- http://www.roojs.org/index.php/projects/gnome.html
- https://blogs.gnome.org/mclasen/2014/03/24/keeping-gnome-shell-approachable/ ( a great hack to make development faster)
- Now even after searching through all these documents there are some functions which are still not found. It’s probably because they are the result of monkey patching: ui/environment.js contain few such functions e.g., hookup_style function used in ui/dateMenu.js has been declared in ui/environment.js.
So after going through all these documents I was able to gain a pretty good idea of the mapping between the libraries written in C and used from JavaScript in GNOME Shell. These documents provided me a great deal of information and helped in a lot in understanding GNOME Shell’s JavaScript binding better.
If you have some more information or link related to this context please drop a comment. 🙂
Shivam Mishra 
I am also developing in GJS and one particular useful thing I found was to use google to index the autogenerated GJS docs:
https://goo.gl/SHd9ZT
🙂
LikeLike
yepp that seems great, it would make searching a lot faster with the power of google search behind it.
Thanks for the comment, I really appreciate that. 🙂
LikeLike
including a google search will lead to surveillance – so the technical aspect is sure interesting but nothing should go on googles servers what i search in my shell (i would uninstall it then.)
besides: code is only googd with good documentation so this infos are really usefull to me – thanks for that!
LikeLike
Good point Shivam.
Now, after doing all this hard discovery part maybe, could you summary/map the info or references in a way making it easier for the next contributor.
It’s a shame that such a code base as
yes, documentation is not that fun to write but at big code, big responsabilities. 🙂
LikeLike
Thanks Philippe 🙂 and yes i agree documentation is very important when dealing with such big projects.
. I was thinking of doing this once I am done with my GSoC project 🙂 .
I would definitely want to work on its documentation part so as to improve it for other new contributors but right now with my GSoC project and some university work going on side by side I get very little free time
LikeLike