A modern Tcl PlugIn?
David Gravereaux
What would it take (aside from time) to get our old browser plugin all
modern again? http://www.tcl.tk/software/plugin/
The old netscape plugin API is no longer supported in the current MSIE.
Just for fun, what would be a development plan for getting it working
again?
--
David Gravereaux <davy...@pobox.com>
[species: human; planet: earth,milkyway,alpha sector]
Please be aware of the 7.5 year ping times when placing a call from alpha centari
Cameron Laird
David Gravereaux <davy...@pobox.com> wrote:
>I was just wondering...
>
>What would it take (aside from time) to get our old browser plugin all
>modern again? http://www.tcl.tk/software/plugin/
>
>The old netscape plugin API is no longer supported in the current MSIE.
>Just for fun, what would be a development plan for getting it working
>again?
.
.
It would take, among other things, a bunch of philosphizing.
The original plugin architecture was a Netscape creation (to
abbreviate somewhat), designed to fit with different browsers.
Microsoft has ordained that plugins will never work again with
Internet Exploder. Microsoft offers alternative technologies.
Jeff and I have both mentioned that the Microsoft architecture
appears to offer enough hooks to recreate a plugin as we know
it, but no one has yet constructed a complete proof.
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Michael Schlenker
> I was just wondering...
>
> What would it take (aside from time) to get our old browser plugin all
> modern again? http://www.tcl.tk/software/plugin/
>
> The old netscape plugin API is no longer supported in the current MSIE.
> Just for fun, what would be a development plan for getting it working
> again?
Hmm, i think for windows at least it would need to be converted to an
ActiveX Control, to be used inside IE. Microsoft provides an article
about building an ActiveX Control hosted inside an Netscape Plugin, so
it can be used with older netscape browsers.
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q282168#Overview
For other platforms, hmm, a KParts wrapper for Konqueror ..., etc.
Michael Schlenker
Jeff Hobbs
> >modern again? http://www.tcl.tk/software/plugin/
The "old" plugin still works in Netscape/Mozilla (tested not too long
ago, but pre-Mozilla 1.0).
> >The old netscape plugin API is no longer supported in the current MSIE.
> >Just for fun, what would be a development plan for getting it working
> >again?
Following MS' decision to nix all Netscape-style plugins in IE, you
needed an ActiveX control instead. Gary Lee produced a variation of
TclControl that does this:
http://www.ecosine.com.tw/~garylee/
If someone is interested in integrating this (project-wise) into the
current tclplugin sources and/or making whatever mods necessary to
have the Netscape-style and ActiveX control work about the same, I
would be glad to add you to the tclplugin project.
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
Join us in Sept. for Tcl'2002: http://www.tcl.tk/community/tcl2002/
Kim Letkeman
traditional plug-in interface. How hard can that be?
"Jeff Hobbs" <Je...@ActiveState.com> wrote in message
news:3D06AB4F...@ActiveState.com...
lvi...@yahoo.com
According to Kim Letkeman <kim.le...@rogers.com>:
:Perhaps the ideal solution would be an Active-X wrapper that reenables the
:traditional plug-in interface. How hard can that be?
It would take time and energy from someone enthusiastic about having
such a thing.
To date, that person hasn't been located.
--
Support Internet Radio <URL: http://saveinternetradio.org/ >
Join Tcl'2002 in Vancouver http://www.tcl.tk/community/tcl2002/
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
lvi...@yahoo.com
:traditional plug-in interface. How hard can that be?
Think of it this way - the IE situation has been like this for a year.
If it wasn't that hard, wouldn't someone have already done it?
Pascal Scheffers
>>The old netscape plugin API is no longer supported in the current MSIE.
>>Just for fun, what would be a development plan for getting it working
>>again?
> It would take, among other things, a bunch of philosphizing. The
> original plugin architecture was a Netscape creation (to abbreviate
> somewhat), designed to fit with different browsers.
Microsoft has a 'Windows Scripting Host', with 'Windows Script Engines'
(their words:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/engines.asp
) If you implement a tcl interpreter from such a COM object and install
it, you can simply write HTML with inline scripts like you use JavaScript
and VBScript:
<script language="Tcl">
puts "something here"
</script>
Is that what the existing ActiveX (COM) object does?
The ActiveScript interfaces don't seem terribly hard to implement,
although debugging/error handling and browser state access is probably
non-trivial. I would love to have it, though.
-Pascal.
Cameron Laird
>
>According to Kim Letkeman <kim.le...@rogers.com>:
>:Perhaps the ideal solution would be an Active-X wrapper that reenables the
>:traditional plug-in interface. How hard can that be?
>
>It would take time and energy from someone enthusiastic about having
>such a thing.
.
.
Also critical judgment in regard to thorny security issues,
and possibly a deployment confusion I don't yet understand
well.
lvi...@yahoo.com
According to Cameron Laird <cla...@starbase.neosoft.com>:
:Also critical judgment in regard to thorny security issues,
:and possibly a deployment confusion I don't yet understand
:well.
I agree - I started to say something about those of us located at sites
which refuse to permit any activex components from being used, because of the
innate problems with security they provide, but figured that someone might
argue that the tcl plugin could layer its own security on top ...
I mentally am not prepared to even consider all the possible bad press/
negative consequences of this going wrong ...
David Gravereaux
>> >What would it take (aside from time) to get our old browser plugin all
>> >modern again? http://www.tcl.tk/software/plugin/
>
>The "old" plugin still works in Netscape/Mozilla (tested not too long
>ago, but pre-Mozilla 1.0).
>
>> >The old netscape plugin API is no longer supported in the current MSIE.
>> >Just for fun, what would be a development plan for getting it working
>> >again?
>
>Following MS' decision to nix all Netscape-style plugins in IE, you
>needed an ActiveX control instead. Gary Lee produced a variation of
>TclControl that does this:
> http://www.ecosine.com.tw/~garylee/
>
>If someone is interested in integrating this (project-wise) into the
>current tclplugin sources and/or making whatever mods necessary to
>have the Netscape-style and ActiveX control work about the same, I
>would be glad to add you to the tclplugin project.
TclControl with Gary's patch looks sweet. I could modify it for Stubs
with LoadLibrary pretty easy, but I'll fall on my face regarding the
current registry catalog problem with Tcl releases. You know... The
"Where is Tcl?" problem.
HKLM\Software\Scriptics\Tcl\8.x <- not used any more
HKLM\Sofware\ActiveState\ActiveTcl\8.x.x.x <- single company specific
Are there any TIPs regarding cataloging installs for apps to read at
run-time?
Jeff Hobbs
...
> with LoadLibrary pretty easy, but I'll fall on my face regarding the
> current registry catalog problem with Tcl releases. You know... The
> "Where is Tcl?" problem.
>
> HKLM\Software\Scriptics\Tcl\8.x <- not used any more
>
> Are there any TIPs regarding cataloging installs for apps to read at
> run-time?
TIP 55 may be related, but another informational TIP could be created
that handles this. It would have to discuss the various fields of
importance for end-developers/users. Of course, how critical is it
that this be in the registry? You can always do the equiv of 'which
tclsh' to get the path.
There is nothing wrong with creating an HKLM\Software\Tcl key and
populating it - but it should be agreed upon what the minimum important
set of keys is, and why.
David Gravereaux
>David Gravereaux wrote:
> ...
>> with LoadLibrary pretty easy, but I'll fall on my face regarding the
>> current registry catalog problem with Tcl releases. You know... The
>> "Where is Tcl?" problem.
>>
>> HKLM\Software\Scriptics\Tcl\8.x <- not used any more
>> HKLM\Software\ActiveState\ActiveTcl\8.x.x.x <- single company specific
>>
>> Are there any TIPs regarding cataloging installs for apps to read at
>> run-time?
>
>TIP 55 may be related, but another informational TIP could be created
>that handles this. It would have to discuss the various fields of
>importance for end-developers/users. Of course, how critical is it
>that this be in the registry?
A windows app starts up for the first time. It was compiled for Stubs and
now needs to do a LoadLibrary/Tcl_CreateInterp/Tcl_InitStubs. Let's say
I'm still developing it and am running it in the debugger and want the
symbols build of Tcl. Let's say I want the thread build, too, and at
least version 8.3.2. Maybe I'll want memory tracing, too. The registry
seems like the logical place to store it. I don't want to put other
platforms out in the cold, but I'm just thinking of myself.
> You can always do the equiv of 'which
>tclsh' to get the path.
I think I want more than that.
>There is nothing wrong with creating an HKLM\Software\Tcl key and
>populating it - but it should be agreed upon what the minimum important
>set of keys is, and why.
I hear you. Now I'm thinking.
Chin Huang
> The ActiveScript interfaces don't seem terribly hard to implement,
> although debugging/error handling and browser state access is probably
> non-trivial. I would love to have it, though.
The page at http://wiki.tcl.tk/3166 points to a couple of Tcl Active
Script engines which are currently works in progress. The engine
included in the tcom distribution is really more of a demonstration of
tcom's COM server framework. It was remarkably straight forward to
implement the IActiveScript and IActiveScriptParse interfaces in
(mostly) [incr Tcl]. I haven't had time to figure out the debugging and
browser state access interfaces.
David Gravereaux
Wonderful. Let us know how it goes. I played around with Gary Lee's
TclControl mods today. I got it working with Stubs (version
independence), but can't seem to get Tk to load correctly. Tk is throwing
a fit and I haven't got it squared yet.
CTclControl::CreateControlWindow where Tk is fired up and attaches, needs
Tk at a ready state, but the windows message pump hasn't churned yet to
have Tk in a ready state... hmmm.. Sounds like a job for threads, maybe.
David Gravereaux
>CTclControl::CreateControlWindow where Tk is fired up and attaches, needs
>Tk at a ready state, but the windows message pump hasn't churned yet to
>have Tk in a ready state... hmmm.. Sounds like a job for threads, maybe.
I gotta get a book on COM/ATL. DECLARE_CLASSFACTORY_EX(CTclClassFactory)
added to CTclControl puts threads in the mix, but in what way I have no
clue yet. Fun stuff to play with, at least. This is all confusing when
you don't know what you're doing :)
What I'd like is to run Tcl single-threaded but in a separate thread and
following the thread rules of Tcl. Then pass jobs over the thread
boundary into the event loop and always keep Tcl servicing itself.