Guidance for working on an accessibility service

[matan]

Hi,

I am a total newb here, badgeless undecorated. I have looked at the latest non-major version release notification on this forum. I assume that it represents the standard way of announcing a new minor release in this community.

I would like to use this opportunity to learn what is the way to browse the source of a particular release, this one or any other “modern” one. I see that the link to the source packages is provided there.

So preliminary, I wonder why are they called source packages? (are they transformed in some way for bundling or installation as the word implies?)

And substantially, I’d like to learn how does one look at the source code from which this release is made. Maybe someone can point me in the right direction, to the point of having the entire source code locally and being able to then build it locally with local changes, and deploy as one’s own fork to e.g. an Ubuntu desktop running an older version of of Gnome. There are many docs indeed, maybe these essentials are covered in a guide I haven’t found yet.

Maybe you can also share from your experience, some average case estimate for how long this process might take for a developer to accomplish.

Motivation: to provide transparency about my angle, my overarching angle of interest is that I would like to integrate a project enabling voice control of a linux desktop environment ― whereas my understanding is that the Gnome project as currently is, does not provide hooks for an assistive daemon being able to get the list of open windows, window under the cursor and so on, elements which are necessary for robust voice control designs as I see them.

Thanks and kind regards,
Matan

[zbrown (Zander Brown)]

@matan

So preliminary, I wonder why are they called source packages?

Because they contain source code, not compiled code

Someone has to compile that code before it’s overly useful for you to run on your system

[mcatanzaro (Michael Catanzaro)]

You’re going to need to modify GNOME Shell. There are some instructions for building GNOME Shell here: Projects/GnomeShell - GNOME Wiki!

You can safely ignore the GNOME release announcements and just focus on GNOME Shell alone. The GNOME 3.38.5 release contains hundreds of different components. The release announcement suggests that you could build them all with BuildStream (there is a pointer to some instructions in the README file), but that will take a long time, doesn’t allow for easy development, and can’t actually be used to run GNOME Shell except via a VM image that it can create. In short, it’s not what you want to do. Just try to build and run GNOME Shell alone following the instructions above and go from there. Good luck!

[matan]

Thank you. I am humbled by your prompt solution. I was able to follow the links down to the GNOME Shell source repository from there. This reminds me that GNOME Shell is the actual implementation that I’d think of as the Gnome Desktop in layman terms. I understand from you that GNOME Shell is the GNOME project that is the desktop management experience and windowing stack integration.

In general, do I really need to work inside GNOME Shell to be able to actively act based on the geometry of active windows in my accessibility service to be, and for factoring in notifications of changes and of launching/closing of windows, or is that something for GNOME Extension writing?

I am looking at Wayland not X11, and some discussions I have read discuss that GNOME Shell does not allow access to that information about windows, not static nor change notifications, at all, at least not when Wayland is chosen. Some StackOverflow posts suggest this is a design choice by project leaders’ design and philosophy as it relates to security (Albeit, I would say it’s a somewhat exaggerated response to X11’s lack of security in that regard, whereas opening up the option to privileged applications/extensions installed and enabled by very explicit user approval could make sense, support effort aside).

[mcatanzaro (Michael Catanzaro)]

@matan

In general, do I really need to work inside GNOME Shell to be able to actively act based on the geometry of active windows in my accessibility service to be, and for factoring in notifications of changes and of launching/closing of windows, or is that something for GNOME Extension writing?

Those GNOME extensions are modifications to the shell, so that is actually exactly what you want to do.

@matan

I am looking at Wayland not X11, and some discussions I have read discuss that GNOME Shell does not allow access to that information about windows, not static nor change notifications, at all, at least not when Wayland is chosen. Some StackOverflow posts suggest this is a design choice by project leaders’ design and philosophy as it relates to security (Albeit, I would say it’s a somewhat exaggerated response to X11’s lack of security in that regard, whereas opening up the option to privileged applications/extensions installed and enabled by very explicit user approval could make sense, support effort aside).

Right, and that’s not going to change: applications shouldn’t be able to know information about other applications’ windows. That means you need to implement your voice command service as part of gnome-shell itself.