Minutes from the GNOME Shell extensions BoF -- 2015-08-10

Focus: developers:

• minimize extensions breakage for each GNOME release
• making easy and pleasant to make g-s shell extensions

should we have some subset of API "stable" and some "not yet stable" ? tradeoff between how much extensions can do and API flexibility

user experience:

• UX not optimal
• how to "advertise" extensions (optional topic for today).

What is broken ATM: What we want to do with g-s in the future ?

extensions writers should test their extensions before release they should use GNOME Continuous

have a mailing list to reach out extensions writers (from extensions.gnome.org):

• mailing them when reaching RC phase
• automated testing each extension:
  • with version check
  • without version check

and sending results to author in advance of final release of the desktop. initially, only do it starting with .90 and mail authors. Allow them to opt-out.

Be able to test extensions either using openqa or dogtail (and check error and standard output).

extensions.gnome.org :

• only works in Firefox
• doesn't work in Chrome (NPAPI is not longer supported)
• plugin doesn't work in epiphany (crash)
• will never work in Wayland.

Allan will work on a design on a replacement.

should the plugin part be moved to a "install extensions" standalone application ? It would need a .desktop / .mime stuff. This would only fix the "install" part but not the configure / which extensions are installed.

native application: should it be in :

• a specific application : could be a webapp wrapped in a application
• tweakUI
• GNOME Software: it has ratings but we would loose comments

how to keep extensions up to date ?

• regular update when not upgrading the desktop
• update when upgrading desktop

get the API as the API used by the most installed/used extension (10 or 15, for instance). Problematic because some of the most popular extensions are doing crazy things .. Could classic mode be used to bootstrap that ?

Is there some community of extensions writers ? Not sure there is, extensions writers are probably looking at other extensions code to "learn" from it.

Should we disable version check by default ? Extension error is already done anyway at initialization One option could be to re-enable it back if a major API is changed.

How about documenting the "api" which are considered "kind of stable", not saying it will be a "always stable API" but at least documenting common practise.

Documenting best practise:

• async call for IO
• async call for network calls
• don't do a dbus connection to a service which might not be there
• release memory...
• avoiding creating a full application as a extension
• extension blocking will block the entire desktop !

Some developer friendly extensions could be added to gnome-shell-extension repository

Extensions can sometime used to develop a prototype, before writing the real code. In that case, extension is not expected to be published on extensions.gnome.org.

Volunteers who want to be involved in GNOME could help testing the most popular extensions.

Should the most popular extension features be included in GNOME Shell, like mpris2 or have settings to replace some extensions (alt-tab extension)

sri as PrjMgr for this !