-Putting it in a url, but not having a menu item, removes much of the
benefit since only a tiny percentage would be able to use it.
<wrench> -> Extensions opens chrome://extensions so yes, we can do the
same for plugins, or reuse chrome://extensions for listing the plugins
as well, as Peter and I think other developers have suggested.
-Checking that each plugin is up to date should be automatic and
enabled for
all users, just like our plugin installer is automatic. I don't see
the
benefit of having that functionality be listed as a "plugin",
especially
since that can't be completely done inside an NPAPI plugin.
Yes we want to implement this in Chrome itself, but at a later stage.
On Dec 7, 12:28 pm, Peter Kasting <pkast...@google.com> wrote:
> Sigh, resending now that I have re-added my address to Groups after it got
> auto-removed :(
>
>
>
> On Mon, Dec 7, 2009 at 12:25 PM, Peter Kasting <pkast...@google.com> wrote:
> > On Mon, Dec 7, 2009 at 11:45 AM, Panayiotis Mavrommatis <
> > panayio...@google.com> wrote:
>
> >> I'm not sure if my email did reach chromium-dev,
>
> > It didn't, so I was confused at first :)
>
> > > > - Modify about:plugins for this purpose. That page is a simple
>
> > > > javascript page that iterates over navigator.plugins. Similar to
> >> other
> >> > > about: pages it doesn't have access to chrome internals. We feel
> >> > > chrome://plugins follows the model of chrome://extensions better,
> >> in that
> >> > > this page cannot be inspected and allows the user to modify state
> >> of the
> >> > > browser.
>
> > To users the distinction is meaningless. I suspect (but am not sure) that
> > we can write an internal handler that serves about:plugins in whatever way
> > we want (e.g. as a DOM UI page with two-way communication with the browser).
>
> > > > - Add the plugins to chrome://extensions -- we can do that too,
> >> we'll
> >> > > let Chromium devs chime in on what's the preferred option here.
>
> > We should definitely put the two together in whatever UI we end up with.
> > Users don't perceive these differently (just try explaining to a
> > non-developer how when they say "plugins" they really mean "extensions"),
> > and the information to see and actions to take are pretty much identical
> > with an extension versus a plugin.
>
Thanks for the insight. Taking these into consideration, I agree
putting extensions and plugins together makes sense (another point of
confusion is that extensions can be configured to use NPAPI, which
blurs the line between the two even further. I'll update the design
doc unless I hear otherwise in the next few days.
> > > > - Modify mostly PluginService (chrome/browser/plugin_service.cc)
> >> > > - Will store state in the sqlite database, per user.
>
> > I'm not familiar with this code. Does it already use a sqlite database?
> > If not it might make sense to just shove this in the Preferences file.
> > This is where we list other similar data, and it avoids the overhead of
> > having another file to open and read on startup.
Will definitely come back and ask you more about this as soon as the
UI settles down
>
> > > > - A plugin is identified by its path in the filesystem. Different
> >> paths
> >> > > are considered different plugins.
>
> > Does this imply that different versions of a plugin are different plugins?
> > I ask because it would be annoying to find the Flash auto-reenabled itself
> > after it auto-updated. Perhaps "same name OR same path"?
>
It's a good question. On linux in particular I find myself with 2-3
versions of a plugin from time to time. One in /etc, another in
~/.mozilla ...
Personally I found myself wanting to disable the /etc plugin but leave
the one in ~/.mozilla So I know of at least 1 user who'd prefer per-
path disabling/enabling. But I don't know what fraction of the user
base I represent.
The situation you suggest is a good point. We can investigate how
often plugin paths change after auto-update and come back with a plan.
Will definitely add to the design doc soon.
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
