chrome and safari plugins in svn

89 views
Skip to first unread message

Sean Takats

unread,
Sep 23, 2010, 9:16:31 AM9/23/10
to zoter...@googlegroups.com
For those developers looking to test and contribute to the new code, there are now Chrome and Safari plugins available (see zotero.org/trac for details). Developers will need to check out a copy of /standalone and also a copy of /connectors. Standalone includes a script to build the standalone application. You'll need to have the XULrunner runtime (v1.9.2.x, available from Mozilla) installed on the build machine. The Chrome plugin is straightforward to install. The Safari plugin needs to be signed, which means you'll need to get a Safari extension developer key (free at apple.com). This code is most certainly not ready for production use, and all the usual disclaimers apply. That said, it's already quite functional, at least in MacOS. Have fun! -Sean

Bruce D'Arcus

unread,
Sep 23, 2010, 9:48:41 AM9/23/10
to zoter...@googlegroups.com
On Thu, Sep 23, 2010 at 9:16 AM, Sean Takats <se...@takats.org> wrote:

> For those developers looking to test and contribute to the new code, there are now Chrome and Safari plugins available (see zotero.org/trac for details). Developers will need to check out a copy of /standalone and also a copy of /connectors. Standalone includes a script to build the standalone application. You'll need to have the XULrunner runtime (v1.9.2.x, available from Mozilla) installed on the build machine. The Chrome plugin is straightforward to install. The Safari plugin needs to be signed, which means you'll need to get a Safari extension developer key (free at apple.com). This code is most certainly not ready for production use, and all the usual disclaimers apply. That said, it's already quite functional, at least in MacOS. Have fun! -Sean

I have to say I'm skeptical about this approach (the FF dependency;
notwithstanding reasonable resource issues, it seems to me it make
more sense to do a full-fledged web client that can be deployed across
any contemporary browser, including mobile*), but I'll withhold
judgment until I hear more from Dan.

In the meantime, anyone care to post a screenshot to show what the UI
is proposed to look like?

Bruce

* I've been wondering if SproutCore might provide a good platform for
doing this: recreating the full library browsing and item editing and
creation UI experience of Zotero in ways that a) offer desktop-like
performance, and b) mobile support.

Bruce D'Arcus

unread,
Sep 23, 2010, 9:57:48 AM9/23/10
to zoter...@googlegroups.com
On Thu, Sep 23, 2010 at 9:48 AM, Bruce D'Arcus <bda...@gmail.com> wrote:

...

> * I've been wondering if SproutCore might provide a good platform for
> doing this: recreating the full library browsing and item editing and
> creation UI experience of Zotero in ways that a) offer desktop-like
> performance, and b) mobile support.

Maybe not quite what I was thinking. According to this (which is
admittedly a bit old):

<http://wiki.sproutcore.com/Basics-Introducing+SproutCore+MVC>

"You will usually only use Foundation and either Desktop or Mobile in
a single application, but not both. If you plan to build an app for
both desktop and mobile devices, you will often create two
applications - one for each target."

Bruce

Avram Lyon

unread,
Sep 23, 2010, 10:07:51 AM9/23/10
to zoter...@googlegroups.com
2010/9/23 Bruce D'Arcus <bda...@gmail.com>:

> I have to say I'm skeptical about this approach (the FF dependency;
> notwithstanding reasonable resource issues, it seems to me it make
> more sense to do a full-fledged web client that can be deployed across
> any contemporary browser, including mobile*), but I'll withhold
> judgment until I hear more from Dan.

I was relieved to hear that the team is staying focused on the Mozilla
platform, since even the Mellon grant won't significantly relieve the
developer resource issue, and I would hate for improvements in the
core functionality of Zotero as an organizational and research tool /
environment to be delayed due to a major re-write or platform change.
Furthermore, the Mozilla platform as a whole is not going anywhere,
announcements of Firefox's death at the hands of Chrome
notwithstanding.

The Zotero Everywhere model is just what we need -- maximal support
for diverse usage scenarios with a minimum of redundant functionality
and code.

Nice work and good luck. I look forward to helping make this happen in
the next months and years.

- Avram

Bruce D'Arcus

unread,
Sep 23, 2010, 10:20:43 AM9/23/10
to zoter...@googlegroups.com

I think this is a reasonable position. However, I think there's a real
danger of over-promising here. I'd prefer the team just focus on the
bookmarklet for cross-browser support: less resources, broader
support, more clear message.

Bruce

Dan Stillman

unread,
Sep 23, 2010, 12:16:19 PM9/23/10
to zoter...@googlegroups.com

Given that Simon has already checked in largely working versions of
Chrome and Safari plugins that connect to a largely working Zotero
Standalone client, I'm not sure what we're overpromising here. Trying to
produce a complete Zotero client clone via the web and/or in other
browsers (which, for reasons listed on the browser compatibility FAQ
page[1] that mostly have not changed, we can't) seems like it would be
where we would be overpromising.


[1] http://www.zotero.org/support/kb/browser_compatibility

Bruce D'Arcus

unread,
Sep 23, 2010, 1:20:07 PM9/23/10
to zoter...@googlegroups.com
On Thu, Sep 23, 2010 at 12:16 PM, Dan Stillman <dsti...@zotero.org> wrote:

> Given that Simon has already checked in largely working versions of Chrome
> and Safari plugins that connect to a largely working Zotero Standalone
> client, I'm not sure what we're overpromising here. Trying to produce a
> complete Zotero client clone via the web and/or in other browsers (which,
> for reasons listed on the browser compatibility FAQ page[1] that mostly have
> not changed, we can't) seems like it would be where we would be
> overpromising.

By over-promising I guess I'm getting at my belief that people
(average users) will be assuming:

a) Chrome, etc. versions will be feature-comparable to the FF version
(but it sounds like they won't)

b) that they don't need FF (but they will)

Notwithstanding reasonable technical contraints, it just seems really,
really odd to require the FF dependency. Or to put this differently,
this is how I believe the average user will view the issue.

Bruce

Dan Stillman

unread,
Sep 23, 2010, 1:25:04 PM9/23/10
to zoter...@googlegroups.com

Did you read our full messages?

1) Yes, the plugins + Zotero Standalone will be full-featured, with the
one possible exception of automatic proxy detection.

2) No, they won't require Firefox.

Avram Lyon

unread,
Sep 23, 2010, 1:25:34 PM9/23/10
to zotero-dev
2010/9/23 Bruce D'Arcus <bda...@gmail.com>:
> b) that they don't need FF (but they will)

They won't. The standalone application is using the XULRunner
framework, but the average user will not know that, just like they
probably don't know that Miro uses it (iirc). And XULRunner is not the
same as Firefox -- it's much simpler and slimmer. Just a way to let
XUL+JavaScript run outside of Firefox. This is exactly the way that
the team should go.

Avram

Bruce D'Arcus

unread,
Sep 23, 2010, 1:34:42 PM9/23/10
to zoter...@googlegroups.com
On Thu, Sep 23, 2010 at 1:25 PM, Dan Stillman <dsti...@zotero.org> wrote:
>  On 9/23/10 1:20 PM, Bruce D'Arcus wrote:
>>
>> On Thu, Sep 23, 2010 at 12:16 PM, Dan Stillman<dsti...@zotero.org>
>>  wrote
>>>
>>> Given that Simon has already checked in largely working versions of
>>> Chrome
>>> and Safari plugins that connect to a largely working Zotero Standalone
>>> client, I'm not sure what we're overpromising here. Trying to produce a
>>> complete Zotero client clone via the web and/or in other browsers (which,
>>> for reasons listed on the browser compatibility FAQ page[1] that mostly
>>> have
>>> not changed, we can't) seems like it would be where we would be
>>> overpromising.
>>
>> By over-promising I guess I'm getting at my belief that people
>> (average users) will be assuming:
>>
>> a) Chrome, etc. versions will be feature-comparable to the FF version
>> (but it sounds like they won't)
>>
>> b) that they don't need FF (but they will)
>>
>> Notwithstanding reasonable technical contraints, it just seems really,
>> really odd to require the FF dependency. Or to put this differently,
>> this is how I believe the average user will view the issue.
>
> Did you read our full messages?

Obviously not in the correct sequence.

Bruce

Reply all
Reply to author
Forward
0 new messages