Plugging into Lobo's Pure Java Web Browser
Lobo's Java Web Browser, still at a dot zero release, drew my attention today because it very recently was Java Posse's project of the week. I love the fact that this browser is pure Java! Plus, it is open source and under active development. Let's help things along by explaining how to create plugins, because this project is smart enough to expose an API for this purpose.
At the end of this article, you'll be able to start up the Lobo browser and you will then see a new menu, with a new menu item, that will produce a "Hello World" greeting in a JOptionPane. It will all look thusly:
Even though there is no "Hello world" document for Lobo plugin development (which I am hoping to remedy by means of this article), the Lobo Browser Plugin HOWTO provides most of the information you need. It is all quite intuitive, once you have the basics. Here they are:
- After you download the Lobo distro, put its lobo-pub.jar on your plugin-to-be's classpath.
- At a bare minimum, you need a class that extends org.lobobrowser.ua.NavigatorExtension. Here's mine, just to give you an idea. Note the overrides, of course, because these are the main hooks into the browser:
public class ExtensionImpl implements NavigatorExtension {
private JMenu menu;
private JMenuItem item;
@Override
public void init(NavigatorExtensionContext ctx) {}
@Override
public void windowOpening(NavigatorWindow window) {
menu = new JMenu("Greetings");
item = new JMenuItem("Hello");
menu.add(item);
item.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent arg0) {
JOptionPane.showMessageDialog(null, "hello world");
}
});
window.addMenu("Demo", menu);
}
@Override
public void windowClosing(NavigatorWindow window) {}
@Override
public void destroy() {}
}That's all we need for our small scenario. Since we're simply using Swing, it is easy to imagine other things that you might do when the window opens/closes, etc. Use code completion and other tools in your IDE to figure out other things you might be able to do to the Lobo browser:
- Now create a properties file called lobo-extension.properties, in your src structure, at the highest level, and add the following info:
extension.name=Demo Lobo Extension
extension.description=This is a demo extension
extension.by=Geertjan Wielenga
extension.version=0.1
extension.class=demoloboplugin.ExtensionImpl
extension.priority=4The extension class is the one shown in step 2, registered by its FQN. The priority is described in the API docs, it's not so important at this stage, since w're just doing a hello world scenario.
- Finally, you'll have a plugin that looks similar to this:
Now compile the plugin, creating a JAR that you put in the distro's ext folder. Below, mine is called "DemoLoboPlugin.jar":
Just restart the browser and there's your new menu. Since it is this easy to extend the browser, I'm hoping this intro has grabbed your imagination and that you'll support this super cool browser. If you love Java, you'll love this browser. Downloading the distro and setting things up was as simple as unjarring and then running java -jar from the command line. Here's hoping that the people behind this project will publish MANY small samples demonstrating the ways in which the browser can be extended. That way, they'd be giving developers handholds to making this browser all that it should be.





Comments
Jacek Furmankiewicz replied on Wed, 2008/02/06 - 10:20am
Forgive me for saying, but I think this type of project is really not very useful.
Java needs to get out of its "everything must be in Java" mindset and instead integrate better with whatever higher quality native components are availabe on each platform.
I'd rather see full official support for embedded Gecko with a Java-friendly API. This would be way more useful in the long run.
Swing could definitely learn a few tricks from SWT. I still wince every time I see all the rendering issues with Netbeans under Ubuntu (from fonts to control rendering).
Geertjan Wielenga replied on Wed, 2008/02/06 - 10:31am
in response to:
Jacek Furmankiewicz
Jacek, I agree with you that not everything must be in Java. However, on the other hand, I find these arguments from the Lobo page pretty convincing in this regard, under the heading "Why a Pure Java Browser?":
There are a number of advantages to be derived from a browser that is written in Java as opposed to a language compiled into native code, namely:Fabrizio Giudici replied on Wed, 2008/02/06 - 6:38pm
--Fabrizio Giudici
Mark Unknown replied on Wed, 2008/02/06 - 8:05pm
in response to:
Jacek Furmankiewicz
[quote=Jacek]Java needs to get out of its "everything must be in Java" mindset and instead integrate better with whatever higher quality native components are availabe on each platform.[/quote]
If they exist and are integratable. I've done plenty of what you are suggesting. It usually doesn't work that well.
[quote=Jacek]I'd rather see full official support for embedded Gecko with a Java-friendly API. This would be way more useful in the long run.[/quote] There is a project like this. It is dead.
[quote=Jacek]J
Swing could definitely learn a few tricks from SWT. I still wince every time I see all the rendering issues with Netbeans under Ubuntu (from fonts to control rendering).[/quote] Maybe. But SWT could learn some from Swing. Like making custom components easy to do.
James Imber replied on Thu, 2008/02/07 - 9:59am
Stephen Bannasch replied on Thu, 2008/02/07 - 10:37am
FWIW: We've started a project called MozSwing:
* http://confluence.concord.org/display/MZSW/Home
that integrates v1.8.1.4 the Mozilla rendering framework XUL with the Java Swing GUI framework.
We've got working code on sourceforge:
* http://sf.net/projects/mozswing
MozSwing is triple-licensed: MPL 1.1, GPL 2.0, LGPL 2.1.
You can see it work by running this web start jnlp: http://jnlp.concord.org/dev/mozswing/mozswing.jnlp
Running that jnlp will also run an extension-installer jnlp that will install platform and os-specific XUL libraries in your web start cache.
There are obvious disadvantages to relying on a native libraries that have to be installed.
Some of the advantages to using the mozswing approach is that we have both rendering and scripting access from a Swing application to almost any XPCOM components (browser plugins) like Flash that can be embedded in a Mozilla browser.
We're planning on porting the mozswing code to v1.9 of XUL and XPCOM (same codebase that's used in Firefox 3).
Thierry Newbee replied on Tue, 2010/12/14 - 3:40pm
Very nice project.
Searching a solution for sharing a web browser without sharing a graphical screen, I fall on your web page.
Your project seems to be a robust platform to implement serving of web pages through a java interface.
I haven't the skills for developing efficiently such achitecture. My idea could be discribed as this :
The server is a java machine with listeners waiting for a final user's client connection.
The client connects and loads java interface that interacts with the "web browser server" sending to the server all input devices signals and receiving
1 - graphical position and attributes of the cursor
2 - A copy of html contents of server side loaded Web Pages to be loaded by the client with the same rendering than the server
3 - Environment and cookies information shared with all users, if necessary.
The heavy graphical objects should be loaded directly from the target web server to the user's client, as often as possible (non contex-dependant objects), using absolute links.
Viewed from the target web server (example : google search) there is one unique client.
Am I nut ?
Kliment Simoncev replied on Tue, 2012/08/28 - 7:59am
No , You are not nut.
Your suggestion is about optimized Java based browser with some modified communication protocol. Similar to Lotus Notes client connection to Lotus Notes Server (using RPC). Also, see: http://www.pitman.co.za/projects/charva/index.html as example. All-in-all HTTP is terminal emulation (of course, more sophisticated... and portable by browser means)
Lucifer Williams replied on Thu, 2012/11/15 - 4:42pm