Date: Tue, 01 Aug 2006 13:46:07 -0500 From: "Jeremy Messenger" <mezz7@cox.net> To: infofarmer@freebsd.org Cc: gnome@freebsd.org, Arjan van Leeuwen <avleeuwen@piwebs.com>, Jeremy Messenger <mezz@freebsd.org> Subject: Re: NPAPI/XPI support in native gecko apps and other ports Message-ID: <op.tdmbq5o59aq2h7@mezz.mezzweb.com> In-Reply-To: <cb5206420607291616l3701793bt832a1b26daeffac@mail.gmail.com> References: <cb5206420607291616l3701793bt832a1b26daeffac@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 29 Jul 2006 18:16:50 -0500, Andrew Pantyukhin <infofarmer@gmail.com> wrote: > Hello! > > As you might have noticed, I've been working on NPAPI and > XPI infrastructures to make user experience more enjoyable > while improving flexibility of the way plugins and extensions > are managed. > > I understand (http://wiki.freebsd.org/Gnome) there are plans > to devise a separate helper port which would create links and > manage browser_plugins dir. I wanted to go the very same > way with XPI, but I seem to have found an alternative, which > some find more likeable. > > Implementation details can be found here: > http://wiki.freebsd.org/NPAPI > http://wiki.freebsd.org/XPI > http://wiki.freebsd.org/Linkfarming > > In a nutshell, to make an app fully NPAPI/XPI-compatible > you need to: > > a. Copy links on installation (a line in Makefile and in plist) > b. Preen links on deinstallation (a line in plist) > > To give an idea, some linux-gecko ports have these lines: > > in do-install targets: > > @${CP} -R ${LOCALBASE}/lib/npapi/symlinks/${APP_NAME}/ \ > ${PREFIX}/lib/${APP_NAME}/plugins/ > @${CP} -R ${LOCALBASE}/lib/xpi/symlinks/${APP_NAME}/ \ > ${PREFIX}/lib/${APP_NAME}/extensions/ > > in plists: > > @exec /bin/cp -R %%LOCALBASE%%/lib/npapi/symlinks/%%APP_NAME%%/ > %D/lib/%%APP_NAME%%/plugins/ > @exec /bin/cp -R %%LOCALBASE%%/lib/xpi/symlinks/%%APP_NAME%%/ > %D/lib/%%APP_NAME%%/extensions/ > @unexec /usr/bin/find %D/lib/%%APP_NAME%%/plugins/ -depth 1 -type l > -delete > @unexec /usr/bin/find %D/lib/%%APP_NAME%%/extensions/ -depth 1 -type l > -delete > > It is a good idea to add "2>/dev/null || true" at the end of each line. > > As you can see, only 3 lines are needed for NPAPI (plugins) support > and 3 lines for XPI (extensions) support. > > It would be great if we could work together and introduce the > support to the apps you maintain. If there's anything you don't > like about infrastructure, it's quite understandable and let's > discuss it. The final goal is to make both users and developers > a little bit happier. Can you remove create any symlink in share/linux-opera/plugins please? It is causing linux-opera to display two plugins if I add lib/npapi/symlinks/linux-opera support in linux-opera (going to commit it soon). I personal rather to have linux-opera to find any plugins in lib/npapi/symlinks/linux-opera than have stuff in share/linux-opera/plugins. It is painless that way. Thanks! While I am here, as for the other browsers that will have a several symlinks in plugins directory by NPAPI and XPI stuff, you will need to add @dirrmtry path/browsers/{extensions,plugins} and @dirrmtry path/browsers for plist in Makefile.npapi and browsers' plist. For example: 1) install linux-flashplugins7 or other stuff 2) deinstall one of browser 3) uninstall linux-flashplugins7 or other stuff 4) path/browsers/{extensions,plugins} will be ending up leftover. Cheers, Mezz > Thanks! -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src) http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org http://wiki.freebsd.org/multimedia - multimedia@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.tdmbq5o59aq2h7>