there are two problems with java-applets on webpages: the time the java-vm needs to start
up and the time it takes to download the jars to start the main applet code (and actually be
able to give feedback on screen from inside the applet).

i made an example to show that applets can be preloaded using a minimal preloader-class
and javascript:
http://bezier.de/processing/xhtml/appletobject/index.html

it solves both problems and gives callbacks to customize the look of the status-feedback.

it's currently not really well documented, some explaination is at the bottom of this page:
http://bezier.de/processing/xhtml/

a commented source can be found here:
http://bezier.de/processing/xhtml/appletobject/js/appletobject_005_src.js
and the html-source is here:
http://bezier.de/processing/xhtml/appletobject/index.html.txt

F

does this actually fix the issue with java vm startup time? when downoad
time isn't considered, the vm startup time on windows is *abyssmal*, on osx
it's not quite as bad but still pretty bad.

the issue with the vm load time, from what i understand, is that it's
hitting the disk and catalogging rt.jar, and since that keeps bloating with
every java release, it's become slower and slower (why they don't cache
this stuff properly i haven't a clue...)

anyhow, you'd basically want the page to load and lay itself out, then put
up some kind of message that the loading was happening, and only then do
you insert the <object> tag for the applet (if that's possible). that way,
the screen doesn't go blank for several seconds as the vm kicks in. you're
doing this, right? it's just that the user has to click 'run' to make it
go? i wonder if there's a better way to do this, i.e. do we allow users to
specify an image instead of the "run" text, that will say "click to load"
or something like that. this would certainly solve the annoyance of people
visiting a web page, and having their machine halt (while they curse
"java") or do we just have it load automatically via onLoad()?

the other thing is the liveconnect stuff.. how's the browser support for
this? has it been deprecated? i thought i saw in one of the threads about
thse issues that a major version of IE doesn't even support it?

and my third question, for the loader, it flickers on and off for me, going
back and forth between blank and showing the text progress bar, or just the
background color. what's happening there? (this was on osx with camino or
firefox).

> does this actually fix the issue with java vm startup time? when downoad
> time isn't considered, the vm startup time on windows is *abyssmal*, on osx
> it's not quite as bad but still pretty bad.

well, it does not fix it but it will allow (customizable) feedback.

> anyhow, you'd basically want the page to load and lay itself out, then put
> up some kind of message that the loading was happening, and only then do
> you insert the <object> tag for the applet (if that's possible). that way,
> the screen doesn't go blank for several seconds as the vm kicks in. you're
> doing this, right?

yes.

> it's just that the user has to click 'run' to make it
> go? i wonder if there's a better way to do this, i.e. do we allow users to
> specify an image instead of the "run" text, that will say "click to load"
> or something like that. this would certainly solve the annoyance of people
> visiting a web page, and having their machine halt (while they curse
> "java") or do we just have it load automatically via onLoad()?

sure, can be anything. image, text, window.onload (that would start it automatically).

> the other thing is the liveconnect stuff.. how's the browser support for
> this? has it been deprecated? i thought i saw in one of the threads about
> thse issues that a major version of IE doesn't even support it?

don't know. JSObject might not be there (and is not included in my jar) .. but i use a
openDocument("javascript:") fallback. see source, it's inside the ZZZZZZ.jar
i tried to call from js to java for a while (reading variables inside applet, or calling
functions), but that causes firefox to go into an endless loop. so the only way to do it is
from java to js.

> and my third question, for the loader, it flickers on and off for me, going
> back and forth between blank and showing the text progress bar, or just the
> background color. what's happening there? (this was on osx with camino or
> firefox).

have to test .. firefox works great for me (both 1.8 and 2.0). haven't tested camino.
there is an issue with the javascript thread (a forked call) fighting with the java-vm. that is
more or less impossible to solve on our side ... no access to the vm and javascript is just to
high-level.

another idea i had about the loader: actually it could preload most of the media into the
java-cache. for example the loading.gif shows up there. i'd have to test how it works with
fonts and sound-files ...

... and it needs a good deal of ducumentation.

got it. including JSObject is a no-no, it's only 'stub' code that links
into the browser's version of JSObject, which is native glue that ties it
to the browser. so we'd break it completely if JSObject were included
(unless the browser is smart enough to ignore it.. doubtful).

the flickering thing seems problematic, is there no way to set the applet
as 'hidden' while it's loading?

i'm really excited about this in general, i think people will love it.

> got it. including JSObject is a no-no, it's only 'stub' code that links
> into the browser's version of JSObject, which is native glue that ties it
> to the browser. so we'd break it completely if JSObject were included
> (unless the browser is smart enough to ignore it.. doubtful).

right, i figured after looking into the src of natscape.javascript lib.

> the flickering thing seems problematic, is there no way to set the applet
> as 'hidden' while it's loading?

hidden will not load the applet at all in many cases , opera for example (some browsers are
smart, or not, depends on the viewpoint ..). but: the flicker you have is not from the
applet. that lives in a tiny 2x2 pixel spot in the upper left corner, so it's the threads that
interfere. with which os, browser, ..., are you having that flicker? for me it's sometimes
hanging a little but it does not flicker.

> i'm really excited about this in general, i think people will love it.

great, me too. it took me a couple of days to get it working as it is now (partly because
installing win and linux on virtual-pc was a bit of a bitch).

re: flickering

i found the problem but it needs some time fixing. it's a problem with [ someNode.innerHTML
= "html-code" ] being a MicroSoft addition (oh man) and not a DOM feature. camino obviously
removes the DOM nodes in place before parsing the string to nodes and back in. so i will
replace all these with DOM calls, and have to test how the other old browsers like it ...

keep us posted on how this progresses. if you and some others from the
board can work on it a bit and iron it out, we can eventually make it the
default applet html.

even fancier would be if we could get rid of the separate opengl vs regular
html, but that's just getting nutty...

yep. stephen williams has already merged his version with mine.
i mailed you about some space on the processing svn, i think it would be great to have it here
instead of sourceforge ..

ok, we moved to a temp home for now:
http://ez-applet-html.svn.sourceforge.net/viewvc/ez-applet-html/
http://ez-applet-html.sourceforge.net/

we have a couple of things on our list that we like to fix / implement before we will release a
new version. mostly getting the java-detection rock-solid and some simplifications for the
users. i keep you posted.

F

are you still needing svn space? sorry to not get back on that, casey and i
have been swamped and everything is eclipsed by book priorities.

i'm not quite sure how we'd incorporate this, i'm guessing that it might be
something under the tools menu, to allow for a more advanced sort of
export. if that's the case, you could just make a branch and work in
processing/app/tools if i give you access.

the tools route could make things confusing for users, however... what's
your goal for this new version? is the point to eventually replace the
default applet.html because this one will be far better? that seems ideal,
and in which case you could simply be branching on the applet.html file.

no. don't worry about the svn i think we'll stay at sourceforge for the moment.

replacing or rather enhancing applet.html is the goal.

excellent, looking forward to it.

moved to a new home on textdrive, now with super trac up and running:

http://appletobject.org/

http://trac.appletobject.org/

F

any more luck in developing this?

or for that matter, any chance the 1.6u10 might also be helpful in this
regard (at least on windows/linux)?

haven't really had time to continue working on it. will report back once i have a new version ...