Browser Plugins

From WebOS Internals
Revision as of 19:55, 20 July 2009 by Hopspitfire (talk | contribs) (New page: ===Call for hackers=== From destinal July 11 09 -- This is very much a work in progress. If you are interested in being part of the effort to get a graphical terminal (and any number of...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Call for hackers

From destinal July 11 09 -- This is very much a work in progress. If you are interested in being part of the effort to get a graphical terminal (and any number of other GUI applications) working on the Pre, please contact me at destinal on #webos-internals or email me at predestinal@gmail.com. --destinal

Plugin architecture

Browser plugins are located a directory defined in the PluginsPath directive in /etc/palm/browser.conf. The default path is shown below.

browser.conf: PluginsEnabled=true
browser.conf: PluginsPath=/usr/lib/BrowserPlugins

Browser plugins are ELF-format shared libraries with the standard .so extension.

To be more specific, in fact, webOS browser plugins use the NPAPI specification common in WebKit and Gecko-based browsers.

For information on how to create an NPAPI compliant plugin, see Mozilla Plugin Documentation

Stock plugins

root@castle:/usr/lib/BrowserPlugins# ls *.so
BrowserAdapter.so    MAPartsAdapter.so    PDFAdapter.so
LunaMediaAdapter.so  OfficeAdapter.so     TnAdapter.so


Upon Luna start, all shared libraries in the plugins directory are loaded and registered based on the MIME type they return in their public function NP_GetMIMEDescription()

Stock plugins by MIME type

root@castle:/# grep x- /usr/lib/BrowserPlugins/*
/usr/lib/BrowserPlugins/BrowserAdapter.so:application/x-palm-browser
/usr/lib/BrowserPlugins/LunaMediaAdapter.so:application/x-palm-media;media;Media File
/usr/lib/BrowserPlugins/MAPartsAdapter.so:application/x-motionapps-partsadapter
/usr/lib/BrowserPlugins/OfficeAdapter.so:application/x-palm-officeadapter
/usr/lib/BrowserPlugins/PDFAdapter.so:application/x-palm-pdfadapter
/usr/lib/BrowserPlugins/TnAdapter.so:application/x-navigation


Building a working browser plugin (using the basicplugin sample)

Getting the code

BasicPlugin is located in the webos-internals applications repository. A sample webOS / mojo application called helloplugin which embeds it is also available there.

git clone git://gitorious.org/webos-internals/applications.git

Ensure you have required libraries

This depends on your linux distro. On ubuntu, you will need build-essential, libglib2.0-dev, and libx11-dev:

sudo apt-get install build-essential libglib2.0-dev libx11-dev

Building the plugin (basicplugin.so)

cd applications/basicplugin
make

Installing the plugin

Copy basicplugin.so to your pre or emulator into the directory /usr/lib/BrowserPlugins.

That's it!

Installing the mojo app to call it

Copy the directory applications/org.webosinternals.helloplugin to your applications directory on your pre or emulator (/var/usr/palm/applications)

Rescan Luna packages or reboot to get an icon to launch it.

Running the plugin

Simply click the "Hello Plugin" link in the emulator.

If everything worked, you'll have a blue card.

A blue card?

Later versions of the sample plugin will do something more exciting, but that's not the point.

More importantly, check out the code, and use it as a template to create your own browser plugins.

Also check out the mojo code for more advanced plugin-based-apps to see the huge amounts of event forwarding code required for a proper app


Things to try next

Write useful plugins

Enhance mojo app to transmit keyboard, pen, and other events.

Plugins vs extensions

Some have suggested using this technique to run Mozilla extensions such as ChatZilla. Note that NPAPI is for plugins rather than extensions -- plugins are native shared libraries of binary code providing functions that are called directly by the browser, whereas extensions are interpreted XML, JavaScript, and similar technologies. Though the Gecko SDK recommended to obtain the plugin libraries is the XULRunner SDK, we are only using the NPAPI / plugin headers, executing XUL / extensions is a long way off.

More on plugins seems to be at:

About This stuff so far: destinal thanks to:

  • bpadalino (help in debugging)
  • mdklein (npapi, npsimple ideas)