Skip to main content

JDIC Project Needs Your Help!

18 replies [Last post]
Anonymous

Hi Dear JDIC Fans,

Thanks for your support for the JDIC project. We open-sourced this project and we also hope we can get your support on this project. :-)

What do you want?
--------------------------------------
From your feedback from JavaOne, JDIC forum, we understand that browser features, such as
- WebBrowser DOM Support
- WebBrowser Listeners & User Interaction Tracking
- WebBrowser Printing Support
are the most wanted features.

What do we need to solve now?
---------------------------------------
Before we nail down to these most-wanted featues, we realized we must first resolve the WebBrowser component Mozilla version dependency issue.

So, what's the problem?

The current WebBrowser component supports both Mozilla & IE. As you all know, Mozilla gets a rapid envolvment in the recent years. As we provide the embedded Mozilla support by accessing the Mozilla native interfaces, we found the code could only work with the specified Mozilla release, i.e. the WebBrowser component will only support Mozilla 1.4 if we build our native code based on the Mozilla 1.4 binaries. If we are going to support Mozilla 1.7, we'll have to build our native code on the Mozilla 1.7 release binaries, which, in consequence, will fail to support Mozilla 1.4/1.5/1.6.

The detailed information could be accessed at
http://www.javadesktop.org/forums/thread.jspa?messageID=26631
https://jdic.dev.java.net/issues/show_bug.cgi?id=87

This issue is very important as it might require reconstructing the architecture of the Browser component. We feel it unwise to rush into the new feature implementation as they might need a consequent modification based on this issue's solution.

After digging into this issue for a period of time, we didn't get a quite satisfying solution. So, we turned to you, our dear community members, for a help in this issue. We'd like any suggestion/discussion/patch on this issue.

Actually, we expect to deliver all the fancy features into the WebBrowser component ASAP. I bet you get the same idea, don't you?

So, let's move on to get this done! Drop us any idea you've got!

Thanks

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
netsql
Offline
Joined: 2004-03-07
Points: 0

JDIC is great and I use it to display internet ads (w/ flash) inside of my JDNC application.

I wish it woudl support FireFox. RedHat v4 ships w/ it and Windwos people use it more.
I am fine w/ including dll's and binaries if that helps, or even a longer automated instalation.
.V

georgez
Offline
Joined: 2003-08-19
Points: 0

Hi,

We did want to support embedding Firefox as well. But as Darin Fisher (working on Mozilla/Firefox) pointed out that,
it's not possible to embed Firefox in another application. This is because Firefox has Gecko built into it (all linked statically as one executable). This was done to improve the performance of Firefox and to reduce the download size.

So, it means that Firefox cannot serve as a distribution mechanism for the Gecko Runtime Environment, and that is somewhat unfortunate. Darin planned to try to build a better GRE that Firefox can embed such that this is no longer a problem in the future. Look for this to happen in the Firefox 1.5 timeframe.

Currently, just try it out with Mozilla. : )

Thanks,
-George.

netsql
Offline
Joined: 2004-03-07
Points: 0

I posted this as bug for Deer Park.
Please vote for it:
https://bugzilla.mozilla.org/show_bug.cgi?id=303956
.V

georgez
Offline
Joined: 2003-08-19
Points: 0

Hi Vic,

I voted for that. But it got a WONTFIX from firefox guys. :(

Thanks,
-George.

netsql
Offline
Joined: 2004-03-07
Points: 0

Thanks George.

What about us using that xulrunner, embed that in a "big" jdic native jar? (if not for you, then for us).
I wonder if we should try that.

btw, we got Mac to work (beta.roomity.com) :-)

.V

cdea
Offline
Joined: 2011-03-01
Points: 0

Paul,

I am just throwing out ideas.

I maybe mistaken but doesn't this pattern kind of follows what JINI helps solve?

-Carl

cdea
Offline
Joined: 2011-03-01
Points: 0

This sounds pretty risky. The extra download seem quite expensive.

What would happen if subsequent installs of other versions of some browser after the JVM was installed?

What about other browsers you have to support?
We are going to not only have DLL he11, but we will have jar versioning problems.

Is there an auto updater to update the latest dll?
Will giving them 1.7 mess things up for < 1.7?

I know I'm asking a lot of questions but I am trying to understand what risks this could impose.

-Carl

georgez
Offline
Joined: 2003-08-19
Points: 0

Hi Carl,

I didn't quite catch your points. For the fix in 0.8.6.1 for Linux (Window fix will be coming very soon), we just updated the same source code to eliminate the potential versioning problems(our fault). Now the same binary (mozembed--gtk*) built from the same source works from mozilla 1.4 through 1.8a4 (the latest release).

There is no extra download or difference from the perspective of end users, the new binary just supports mozilla 1.4+.

At the moment, we support IE/Mozilla on Windows and Mozilla on Unix, there is no plan to support other browsers on Windows/Unix.

Your questions are very welcome. If I didn't address your questions, please raise your comments.

Thanks,
-George.

cdea
Offline
Joined: 2011-03-01
Points: 0

George,

You basically answered my questions.

I had thought that many dll would have to be supported.

Thank you.

Does the tray API support the Escape Key?!

-Carl

georgez
Offline
Joined: 2003-08-19
Points: 0

Hi Carl,

You know, there is a reported issue for this problem:
> Does the tray API support the Escape Key?!
http://www.javadesktop.org/forums/thread.jspa?threadID=5102&tstart=0

It's not yet fixed. : (

-George.

onclejibi
Offline
Joined: 2004-08-19
Points: 0

Hi,

Would it be possible to simply include important Mozilla binaries with the browser, like it's done in JRex for example. It would solve the problem since we could be sure we have the right version everytime.

Perhaps I could explain how I use the JDIC browser so you can understand why such a solution would be acceptable. I need a browser to integrate into a client application I distribute to various customers using different platforms and having a lot of different level of computer knowledge. So what I need is a very simple solution to deploy, and I can't be assured of anything on my customers computers (like the JAVA_HOME directory being set or Mozilla 1.4 or Explorer being the default browser).

Since my application is distributed over the Internet, I like the small size of the JDIC release. But for me, and I think for a lot of people using java to develop applications, portability and use of deployment are paramount. So if it would be simpler to include all of mozilla libraries on every platform, perhaps adding 5-10 Mb to the download, it would be worthwhile. The added bandwidth would be far cheaper then having to pay for a call center to be sure my app works on every computer.

The two other points worth noting on this method is that we would lose support for plugins. It would be great if the browser could have default support for flash for example. It has now, but I don't know how you could do it with the method described above.

The other point is that it would need to be faster than what has been achieved in the JRez project. A large part of their rendering is done in java, which is great in theory but a lot slower in pratice.

Finally, I want to thank everyone working on the jdic project. It's the best java browser component I've seen, and I think such a component is direly needed by the java community. Keep up the good work,

Jean-Baptiste Blanchet

Anonymous

Hi Jean-Baptiste,

Thanks for your support for the JDIC project. We are really encouraged by your words. :-)

Yes, to include Mozilla binaries is one option to solve this problem. However, considering we are targetting at incorporateing JDIC into JDK 6.0, it would be better to find other solution. (You know, it would be hard to put the Mozilla binaries into JDK :-().

-Paul

onclejibi
Offline
Joined: 2004-08-19
Points: 0

Hi,

Is there a big difference between each version of mozilla? Wouldn't it be possible to detect the Mozilla version at runtime and use the appropriate binary?

JB

georgez
Offline
Joined: 2003-08-19
Points: 0

Hi Jean-Baptiste / JB:

Thanks for the comments. There may not be much difference beteen EACH version of Mozilla, but they keep changing.
I verified that: the embedded Mozilla binary (MozEmbed.exe on Windows, and mozembed--gtk*) built with Mozilla 1.4.1 (the currently supported Mozilla version) doesn't work with Mozilla 1.5, 1.6 and 1.7, though the same mozembed source build with all these Mozilla versions without any problem.

In brief, it's due to the change of XPCOM libraries between Mozilla versions, and the JDIC embedded browser binary links to XPCOM libraries.

I state the problem in detail in below links:
http://www.javadesktop.org/forums/thread.jspa?messageID=26631
https://jdic.dev.java.net/issues/show_bug.cgi?id=87

Any more ideas on that are welcome.

Thanks,
-George.

onclejibi
Offline
Joined: 2004-08-19
Points: 0

Hi,

Then, if there's not a big difference, why can't we build and include MozEmbed14, MozEmbed15, MozEmbed16 and MozEmbed17, then detect the version at runtime and load the right binary depending on the Mozilla version. In fact, use the same mechanism you're using right now to integrate Explorer or Mozilla, depending on which one is the default browser.

I'm not sure it's the neater way to do this, but it would only add 450k to the download (~200k if the files are in a jar) and would be relatively simple since each binary can be built from the same source, thus eliminating the overhead of having 4 versions to debug.

JB

georgez
Offline
Joined: 2003-08-19
Points: 0

Hi,

I like the idea. : ) Seems that though Mozilla (XPCOM) changes between versions, each major release (including several sub-releases) like 1.4.*, 1.7.* doesn't change much. I did verify that each mozembed binary built for a major release works with its sub-release. Say, a binary built with 1.4.1 works with 1.4, 1.4.2, 1.4.3.

So, I also proposed to release mozembed for each major Mozilla release (1.4, 1.5, ... 1.8). For the new incoming Mozilla major release, we just rebuilt the mozembed binary, and include it in the new JDIC release.

But some other contributors concern that then
1. we must build mozembed for every major Mozilla version, including varieties of compilers used by the Linux vendors, e.g. gcc 2.9, gcc 3.2, etc.
2. we must test JDIC from time to time against different version of mozembed with its associated Mozilla.
3. Mozilla will continue to push out 2 to 3 sub-releases every year in the next five years, and the whole thing will multiply!

So, looks like it's still a workaround, and we'll have much work to maintain it.

Another solution might be to have a glue layer (like xpcom glue API?) to wrapper the changes in the Mozilla xpcom library. Before it's checked into Mozilla source, we need to make it downloadable on the JDIC website (though this glue library still has the versioning dependency problem). And then we need to check it into Mozilla source, hopefully.

This glue layer cann't fix the problem for all existing versions of Mozilla. To limit the work, we can consider only supporting Mozilla versions that were shipped with the OSes, because these are the browser versions that are relevant! For example, those Mozilla versions shipped with recent versions of RedHat, SuSE, and other Linuxes.

For future versions of Mozilla, we can attempt to come up with a new glue layer (possibly "C" interfaces) that will shield us from this problem once and for all, and check the glue layer into Mozilla 1.9 or 2.0 if possible.

Which looks like very much a Mozilla project and require time and work. :-(

So, any other proposals are helpful. Thanks !

-George.

Gary Orser

I don't like this idea at all.

I think a more fruitfull approach would be to use something like
mozilla-remote-client. (We would need to add "command options" or in
effect expand the public api...)

There might be some discovery problems, like "where is mozilla installed
on this box?", but I think these are less daunting than maintaining binary
version compatiblity.

There might be problems with two way communications. But this public api
might be better addressed with xmlrpc or something similar to create the
public api. (It should be easier to hold a public api constant through
mozilla revision changes)

Cheers, Gary
------------------------------------------------------
Gary Orser , orser at cns dot montana dot edu
Montana State University
Center for Computational Biology
1 Lewis Hall, Bozeman MT, 59717

On Mon, 20 Sep 2004 jdic@javadesktop.org wrote:

> Hi,
>
> I like the idea. : ) Seems that though Mozilla (XPCOM) changes between
> versions, each major release (including several sub-releases) like
> 1.4.*, 1.7.* doesn't change much. I did verify that each mozembed binary
> built for a major release works with its sub-release. Say, a binary
> built with 1.4.1 works with 1.4, 1.4.2, 1.4.3.
>
> So, I also proposed to release mozembed for each major Mozilla release
> (1.4, 1.5, ... 1.8). For the new incoming Mozilla major release, we just
> rebuilt the mozembed binary, and include it in the new JDIC release.
>
> But some other contributors concern that then 1. we must build mozembed
> for every major Mozilla version, including varieties of compilers used
> by the Linux vendors, e.g. gcc 2.9, gcc 3.2, etc.
> 2. we must test JDIC from time to time against different version of
> mozembed with its associated Mozilla.
> 3. Mozilla will continue to push out 2 to 3 sub-releases every year in
> the next five years, and the whole thing will multiply!
>
> So, looks like it's still a workaround, and we'll have much work to
> maintain it.
>
> Another solution might be to have a glue layer (like xpcom glue API?) to
> wrapper the changes in the Mozilla xpcom library. Before it's checked
> into Mozilla source, we need to make it downloadable on the JDIC website
> (though this glue library still has the versioning dependency problem).
> And then we need to check it into Mozilla source, hopefully.
>
> This glue layer cann't fix the problem for all existing versions of
> Mozilla. To limit the work, we can consider only supporting Mozilla
> versions that were shipped with the OSes, because these are the browser
> versions that are relevant! For example, those Mozilla versions shipped
> with recent versions of RedHat, SuSE, and other Linuxes.
>
> For future versions of Mozilla, we can attempt to come up with a new
> glue layer (possibly "C" interfaces) that will shield us from this
> problem once and for all, and check the glue layer into Mozilla 1.9 or
> 2.0 if possible.
>
> Which looks like very much a Mozilla project and require time and work.
> :-(
>
> So, any other proposals are helpful. Thanks !
>
> -George.
> ---
> [Message sent by forum member 'georgez' (George Zhang)]
>
> http://www.javadesktop.org/forums/thread.jspa?messageID=29352&#29352
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdic-unsubscribe@jdic.dev.java.net
> For additional commands, e-mail: jdic-help@jdic.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jdic-unsubscribe@jdic.dev.java.net
For additional commands, e-mail: jdic-help@jdic.dev.java.net

georgez
Offline
Joined: 2003-08-19
Points: 0

Well, another update with the same problem. :)

We've got great help from Darin Fisher (darin). Now JDIC release 0.8.6.1 is available for the fix on Linux, please help to check it out and give your feedback:
http://www.javadesktop.org/forums/thread.jspa?threadID=5588

Thanks,
-George.