Hi Matej,

Thanks for your reply.

I think we are running into the meta-level confusion again.

Installing from squeakland means installing the etoys image.
And it installed the np* pieces in its vm directory and the
links in the firefox directories.
So the firefox on MY ubuntu runs the etoys image when I test my web-plugin.

The squeak-plugin-image that ubuntu lists, according to Bert, seems to be an earlier incarnation of this squeakland offering. When it was still being called squeak. And therefore the web-plugin image the squeak-plugin.

I really begin to feel as if I am back in Lewis Caroll's thru the looking glass as the white knight is about to recite his poem.
http://www.sabian.org/Alice/lgchap08.htm

--- On Thu, 4/23/09, Matej Kosik <kosik at fiit.stuba.sk> wrote:

> From: Matej Kosik <kosik at fiit.stuba.sk>
> Subject: Re: [squeak-dev] Re: Ubuntu package maintainers help
> To: peace_the_dreamer at yahoo.com
> Date: Thursday, April 23, 2009, 5:12 PM
> Jerome Peace wrote:
> > Umm. Ok. So the web-plugin image has a sort of
> contract with the .pr files that want to be run in it.
> > 
> > Is there any reason why we wish a squeak image for a 
> web-plugin? Rather than an Etoys-image for the web-plugin. I
> ask this because Squeakland seems to me to be the only one
> right now persuing this.
> > AFAIK they have cornered the market.
> 
> The squeak-plugin-inmage (Debian package) brings in
> squeakland image. I
> think that is OK.
> 
> Rarely, when I did some fancy things, they were working in
> ordinary
> Squeak images (3.8, 3.9) but they did not work in
> squeakland image. One
> must count with that when he creates pr projects for the
> web.
> 
> Ideally, those *.pr files are authored directly in the
> squeakland image.
>
Right. I have found *.pr files like their home image more than others.
In particular they don't travel well between forks. Etoys moved the layout slots and that causes confusion if I try etoys *.pr's in 3.9+ and vice versa. There are probably other points of friction.

I think from Bert's reply, we would recommend that a squeak-plugin package is something that squeakland used to promote and it has now become an etoys web-plugin.
> > 
> > I seriously doubt that either the 3.9/3.10 branch wants
> to pursue maintaining this.
> > Ditto for the Pharo branch.
> 
> I do not understand
> (but maybe my prior note clarifies what you meant)

Yes. The plugin is associated with Squeakland and not Squeak-dev.
 
> > 
> > Bert: Any insight into this point?
> > 
> >> In theory, any image could be used with
> squeak-plugin but
> >> it would
> >> create a chaos. Creators of projects would not
> know to what
> >> properties
> >> of the image they can rely.
> >>
> >>> Like say a command line passed from the
> browser to the
> >> image?
> >>> How can we test images to see if they can be
> browser
> >> plugin images as well?
> >>
> >> If you figure out, where `squeak-plugin-image'
> package
> >> installs
> >> /usr/share/squeak/SqueakPlugin.image.gz
> >> the image, you can replace it with your own and
> see what
> >> happens.
> >>
> >> I think, once I have tried to do it, I think.
> >>
> > It has been easier for me to create launchers to
> redirect
> > the pieces. That way I don't have to deal with
> special permissions. Everything can be in a local directory.
> > 
> > My user story on this: Doing a save as in squeak on
> Ubuntu sould also create an instance of a desktop launcher
> for that image. I.E. Squeak should be Ubuntu aware on
> Ubuntu. But that as the say is another story. (And my next
> mantis issue.)
> > 
> >  
> >>> Also as I was looking at the vmplugins it
> looked like
> >> for each supported browser we had a np<browser
> >> name>Plugin.
> >>> There was a link to the appropriate plugin
> from the
> >> firefox browser on my Ubuntu. So I presume each
> brower would
> >> need to be hooked up like that.
> >>
> >> I haven't seen such VM plugins.
> >>
> >>> Can you help clarify this for me?
> > When I installed Etoys amoung the things in the vm
> directory were
> > 
> > /usr/share/Etoys.app/Contents/Linux686/npetoys.so
> > /usr/share/Etoys.app/Contents/Linux686/npetoysregister
> > /usr/share/Etoys.app/Contents/Linux686/npetoysrun
> > 
> > and a link
> > /usr/lib/firefox/plugins/npetoys.so
> > pointing to 
> > /usr/share/Etoys.app/Contents/Linux686/npetoys.so
> > 
> > in the firefox directory.
> > I am presuming that is what links the browser to 
> > its helper in this case the Etoys image and stuff.
> > 
> > Jose would know more.
> 
> (a guess)
> 
> The np* prefix indicates that it is a "Netscape
> Plugin". Like
> `npsqueak.so' we provide. Bert Freudenberg wrote it.
> What is different
> in etoys web-browser plugin I have no clue.
> 
> The npetoys.so is not "VM plugin".

Okay. It just gets confused with one because it lives in the same directory. I still don't know what its low level function is. On the high level it gives Firefox the ability to start etoys as a helper.
Jose has probably got a neat package with all these things and do dads.

Also Pharo has compiled a list of vm-plugins at:
http://code.google.com/p/pharo/wiki/VMPluginOverview

it does not mention the np* class of things nor the 
vm-sound-* or vm-display-*. So I wonder what those classify as.
> 
> The other files are only helper scripts.

Could be.

=====
On another note. The post to Jordan Mantha I copied to the list never reached him. Bounced. Apparently his public ubuntu address is a dummy to prevent him being overwhelmed.
I copied it to the bug report Chris mentioned. Asked for some one to get it to him. And asked for a response.
I did get a response this morning but only the automatic one from the launchpad tracker. I have received no human response from Jordan or anyone at ubuntu. 

So I am now putting this on a back burner. I have done all I can do to get this fixed on the ubuntu side. The only thing left to do is wait for some signs of life on their part.

AFAIK their bug harvesting process somewhat resembles ours very chaotic and peculiar.
=======

Thanks again for all your help.

Yours in curiosity and service, --Jerome Peace