Re: What about defined extensions points ?

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
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.


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]