On Fri, Jul 15, 2011 at 11:55 AM, Federico Mena Quintero <feder...@gnome.org > wrote:
> On Thu, 2011-07-14 at 13:54 -0400, Jasper St. Pierre wrote: > > > They're three separate actors by design, because it's *really hard* to > > do it otherwise. I assume what you really want is a method or > > something that will hide all three for you. I doubt you're going to > > get that API: it doesn't really benefit us at all. > > Florian already posted a cute snippet that ties the visibility of the > corners to the visibility of the main panel. > > We need to strike a balance between these: > > - Gnome-shell wants to have a coherent design. Still, it needs to > accept that not everyone's needs are equal. > It doesn't need to. > - People want extensions to tune gnome-shell to their particular usage. > > - Extensions will find the points in the gnome-shell code where they > would like to "plug in", but they aren't clearly defined yet. > > - Gnome-shell wants to keep evolving, and extensions to thrive, without > breaking all the time. > > Considering all these, extension writers *will* find points where it is > cumbersome to extend gnome-shell. The best thing gnome-shell can do is > to make those extension points easy and explicit; once we have them, we > can have a clear policy for deprecation of extension points if > gnome-shell ever needs to remove them because of other changes. But in > the meantime, it's better to make it easy to write extensions, than to > shun them away because "gnome-shell doesn't need them". > Sure. Given that JS is extremely malleable *without* extension points, I'd like to start including extension points based on what real extensions use. > Allow the ecosystem to build itself and it will be better for both > parts. > > Federico > > -- Jasper
_______________________________________________ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
