Developing an Extension

Update: The labeled spaces extension can be found here.

As I work to have my idea enter the pipeline for inclusion into mainline, I’ve decided to implement my labeled workspaces idea as an extension. To make the customizations necessary, I’ll need to have a pretty good understanding of the system I’m modifying. Unfortunately, due the current lack of documentation for the Javascript files, I’m going to have to go through the source code and try to understand it myself. It also doesn’t help that I’m not accustomed to the technologies the shell is made out of – Clutter, StShell, GI, and Gjs, but I think it should be a fun learning experience. Firstly, I plan to learn and understand Clutter with:

After learning Clutter, St, and Shell should easier to pick up since they are either fully or partially based on Clutter. After understanding the drawing libraries, I’ll head on to understanding GI. Actually, it turns out Clutter and GObject are closely related, so I’ll have to do those two together. Finally, I’ll look over Gjs and the Javascript files concurrently and attempt to understand how the UI works. After all this, I should be able to understand what components to modify as I make my extension.

Have any tips, comments or pointers?


5 thoughts on “Developing an Extension

  1. olsonjeffery says:

    #gnome-shell on is a great resource.. the devs are *terribly* helpful and if you take the time to talk about about API functionality you’re trying to access, someone in there will (most likely) let you know where the source code is that you need to review (or if the functionality is exposed atm).

    Also: I would do GObject and Gjs first, specifically understanding how it parses function/classdef signatures in the C source and automagically exposes that stuff, via gir, to JavaScript, since that’s the lynchpin of figuring out how you would will interact with the c library that underpins gnome-shell… understanding Clutter is mostly a side-effect of how to implement what you want. If you’re after a more holistic understanding of how gnome-shell (and extensions) work, I’d attack the C/JavaScript interaction layer. But that’s just one person’s opinion.

    I followed you here from your post on the gnome-shell mailing list and I really appreciate the work you’re doing for this feature. It’s really interesting stuff. As far as getting this incorporated into the mainline goes: have you tried getting a GNOME designer’s ear? Politically speaking, they’re the gatekeepers to getting new features/workflows into the gnome-shell UX.

  2. Luke Meyer says:

    Using this right now and it’s helpful, but limited. The idea is just what I need, though. Doesn’t look like you’ve had time to work on this in the last 8 months or so… any chance you could put the code up on github for others to take a crack at?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: