Il giorno lun, 24/10/2011 alle 11.48 +0200, Alexandre Mazari ha scritto: > Hi, > > In its current incarnation, g-s extensions system give total freedom > to arbitrary code: extensions have access to the whole environment to > tweak with. > While great flexibility and freedom are given to extensions authors, > it might pose a problem of security and 'alienization' of the shell, > making it a lot different from the lovingly crafted original > experience. > Furthermore, it makes developing an involving task because no clear > and documented API is defined. > > Instead, it might be better to have clear extension points defined and > hide unrelated data and logic. > That'd gives the shell a way to control and restrict extensions and > reduce the surface of exposed symbols while lowering the learning > curve for newcomers. Some of the extension point you list are present and actually used by existing extensions. The fact that you can develop stuff outside that is a side effect of using JS and having private properties that are just underscored instead of properly hidden. Nevertheless, I consider that a feature, as I can develop both the nice and clean status area menu, and the completely hacky replacement for internal functionality (at the expense of some more breakage). As noted before, extensions are expected to change the user experience, that's why they're there, and they are the replacement for the configurability that is not provided by core. On this topic, by the way, I wanted to start a thread, sooner or later, about striking a balance between what should be an extension and what should be in core. This is related, but not equivalent to extension points. My view is that small feature changes should be configurable by core code, and the metric for drawing the line should be the maintenability of the resulting compound. Three categories come to my mind: 1) some extensions use well-defined extension points, are clean and well "separable" from other shell components; examples of these are zeitgeist (search provider), xrandr-indicator (status area item) and gajim (message tray source) 2) some extensions provide additional functionality, or otherwise involve a large amount of additional code, by replacing what's in core; examples of this are alternate-tab or native-window-placement 3) some extensions just tweak one small bit of UI, using convoluted hacks to bypass existing code; unfortunate examples of this last group is alternative-status-menu, auto-move-windows (the workspace collection part, not the automatic movement) and that extension which removes the a11y menu I think that we have no problem with 1) being outside the core tree, and indeed some better docs would help, but the amount of extensions of that kind developed so far (from weather applets to CPU monitors to app menus to window switchers) shows that it's not a big deal. It may be necessary to keep 2) outside core, as it would raise the burden on shell developers by a large amount, without providing considerable benefits for the user base at large. We can discuss that on a case by case basis, though (for example, some features of alternate-tab are still under discussion) Finally, 3) should be in core and controlled by GSettings. I'm tired of layering hacks over hacks just to keep alternative-status-menu working with the latest change. I'm tired of having copy-pasted code spread around my extensions just to change one single line. Giovanni
Attachment:
signature.asc
Description: This is a digitally signed message part