Re: 3.6 Feature Proposal: Extension Hook Support and Updates

2012-04-24 Thread Jasper St. Pierre
On Tue, Apr 24, 2012 at 2:08 PM, Federico Mena Quintero
 wrote:
> On Tue, 2012-04-24 at 03:54 -0400, Jasper St. Pierre wrote:
>
> (In a way, I like thinking of some extensions as the correct answer to,
> "but we don't want two code paths and a preference".  It helps keep
> everyone responsible for the way they want things to work, instead of
> burdening the maintainer with everything for everyone.)

That's a possibility, but I hope that the majority of the extensions
aren't a "missing checkbox". I hope that the best extensions are ones
that are novel, and add "missing functionality", like Desktop
Scroller.

  https://extensions.gnome.org/extension/136/desktop-scroller/

It's a great idea, and works perfectly as an extension. If we try it
out in usability tests, maybe we should consider adding it to the
Shell itself.

>  Federico
>

-- 
  Jasper
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: 3.6 Feature Proposal: Extension Hook Support and Updates

2012-04-24 Thread Federico Mena Quintero
On Tue, 2012-04-24 at 03:54 -0400, Jasper St. Pierre wrote:

> As for the "Extension Hook Support", I want to get consensus of a
> policy that we won't reject a patch that allows an otherwise
> tricky/dirty/impossible hook into the Shell or Mutter for extensions
> use, after passing the standard code policy purposes. I've seen a few
> patches rejected because "we don't support extensions", but I'd like
> to change that.

This is great news!  I'm sure it will help clean up code which is too
"tight" to let an extension be implemented cleanly.

(In a way, I like thinking of some extensions as the correct answer to,
"but we don't want two code paths and a preference".  It helps keep
everyone responsible for the way they want things to work, instead of
burdening the maintainer with everything for everyone.)

  Federico

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


3.6 Feature Proposal: Extension Hook Support and Updates

2012-04-24 Thread Jasper St. Pierre
Hey, I'm sort of new to this, so maybe this isn't the best feature
proposal ever. Sorry.

I'm quite sure you all know what GNOME Shell Extensions are, and how
they're a great boon for this platform. If you haven't seen the GNOME
Shell Extensions repository and the wide variety of extensions
available (or only checked it out on day one), you might want to check
it out now, as the collection as ever growing. Here's two that I have
on my machine right now:

  https://extensions.gnome.org/extension/55/media-player-indicator/
  https://extensions.gnome.org/extension/212/advanced-volume-mixer/

Anyway, the extensions community has always been sort of distant from
the core GNOME community, and I always feel bad for them.

Extension updates are exactly what it sounds like. Right now, you have
to manually update your extensions. There's a green update button for
each updateable extension on the Installed Extensions page, and the
update experience is quite poor: Click the green update button, wait
for the existing extension to uninstall, wait for the extension to
download, press "OK" on the installation dialog, rinse, repeat. I'm
going to propose to update extensions automatically, pinging back to
http://extensions.gnome.org/ every week or so with the installed
extensions, and updating extensions if there's an upgrade. [0]

As for the "Extension Hook Support", I want to get consensus of a
policy that we won't reject a patch that allows an otherwise
tricky/dirty/impossible hook into the Shell or Mutter for extensions
use, after passing the standard code policy purposes. I've seen a few
patches rejected because "we don't support extensions", but I'd like
to change that.

Extensions are a powerful story going into the future, and I think we
should try to exploit that and help out the people helping our future,
rather than fight it.

[0] I've always felt bad in that we're half reinventing a package
manager, but for a specialized case. If anyone knows a sort of package
manager like thing that only requires the home directory, can do all
the things that package managers can do, and has an API I can use from
the Shell and browser-plugin (C API, basically), I'd like to look into
depending on it, replacing our own home-rolled equivalent.

-- 
  Jasper
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list