extending IE with Rebol was RE: Re: Easy-Vid
[1/7] from: bry::itnisk::com at: 6-Jan-2004 11:38
>It might just be a question of patents. Maybe MS has patented loading
of >scripts on web pages or something else obscenely vague.
Well no actually Microsoft got sued by eolas:
http://www.betanews.com/article.php3?sid=1065601616
The desire to have some sort of way of plugging rebol more closely into
Windows, especially the protocol architecture as handled via IE, was the
reason for the asynchronous pluggable protocol article:
http://www.devx.com/webdev/Article/17120
The rebol example in there is pretty trivial (not to mention being
spaghetti code), but I was hoping that others would have some ideas as
to how such a protocol should actually work.
If one of the things one wants is to just load .r files the protocol can
be used to pass info as to the location of that .r file and then load
it.
Last night I actually started doing a useful script to run when I call
reb:// 'addresses', I decided to have it have the structure
Reb://password=skjuiquig&gobject=window&oid=1576&oname=IEXPLORE.EXE&load
=myscript.r&exec=loadwindow http://www.rebol.com
A password would be obligatory, this way the script can keep track of
links authored locally, and those passed external to the system.
Depending on what the password and security settings are it would allow
one to do specific things.
The gobject parameter refers to various objects recognized by the script
that allows it to lock into the system. An object referencing window
tells you that the script wants to do something to a specific window.
Oid tells you the pid of the object passed (not necessary for each
object)
Oname tells you the image name of the object passed.
Load tells you what scripts to load, probably should be a list.
And exec tells you what code to execute.
In the example link above I'm thinking that the link tells the script to
get the window from which it was called, and to load that window with
the address www.rebol.com to be able to do stuff like pass an actual
windows id from IE, I'm extending the right click context menu, so
unfortunately it can't be 100% rebol.
Anyway, the scenario given above might not be the best way to do things,
and it may not be what people want. So other suggestions would be
welcome.
[2/7] from: gerardcote:sympatico:ca at: 6-Jan-2004 8:48
i Bran,
I also thought about addind some COM interface for REBOL to be used instead of Javascript
as the scripting language for IE but my
programming knowledge was falling short too soon. Sorry about that but life is like that.
I also asked myself how could be added a MySql protocol to REBOL without using the external
call mechanism of the PRO versions of
REBOL and why we couldn't do the same about IE but again this is exceeding my actal knowledge.
But I think you are in a good idea to explore this avenue. May be someone more experienced
can explain us SIMPLY what has to be done
and if this can be done what we need to get as information to start with.
I also remember when IE could launch REBOL scripts and it was very spectacular to me.
I know a lot of apps that could use this
approach to help promote the use of or at least the interest about REBOL ...
Regards,
Gerard
[3/7] from: bry:itnisk at: 6-Jan-2004 15:43
>But I think you are in a good idea to explore this avenue. May be
someone >more experienced can explain us SIMPLY what has to be done
>and if this can be done what we need to get as information to start
with.
Well I think it's not so much what needs to get done, as in what people
would like done. Some things, like using Rebol to get a window by name,
would of course require command, and I don't think I could do that. But
most of the browser interaction, whether IE or Mozilla I could handle.
So here are a list of things:
Click on a link in windows - link can be in IE, link can be in a word
document, excel, open office documents, could be in a htt template for a
folder in the local filesystem found via explorer, etc. This link call
rebol and passes it commands, what kinds of commands should rebol be
able to accept?
I figure to make this powerful it has to pass info about what
environment the link was clicked in. The window name, the process id,
etc.
Extending the right click menu in IE and Mozilla:
This is basically a registry hack in IE and if I recall correctly an XUL
hack in mozilla. In IE clicking a right context menu calls a modal
dialogue window, which can be a local html file, depending on registry
settings the particular page is visible or invisible. If invisible the
page should just be a script.
I don't have any of the ones I was working on at home so I'll just use
an example extension from google:
If you have the googletoolbar installed you also have a registry entry
something like this:
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\MenuExt\&Google
Search]
@="res://c:\\winnt\\downloaded program
files\\GoogleToolbar_en_2.0.95-deleon.dll/cmsearch.html"
Contexts
=hex:10,00,00,00
res: refers to a html page found as a resource inside of the
GoogleToolbar_en_2.0.95-deleon.dll but it could in fact be a local file,
if instead of the res protocol file: was used
here's a copy of that file:
<html>
<object id=gg align=top
classid="clsid:00EF2092-6AC5-47c0-BD25-CF2D5D657FEB" width=1 height=1
border=0 vspace=0></object>
<script language="JavaScript" defer>
var parentwin = external.menuArguments;
var doc = parentwin.document;
var sel = doc.selection;
var rng = sel.createRange();
var strhtml = new String(rng.htmlText);
var str = strhtml.replace(/<[^>]*>/g," ");
str = str.replace(/\s+/g, " ");
str = str.replace(/^\s*/,"");
str = str.replace(/\s*$/,"");
if (str.indexOf(" ") != -1)
str = '"' + str + '"';
var bnewwindow = external.menuArguments.event.shiftKey;
var url = "http://www.google.com/search?sourceid=navclient-menuext&q="
+ escape(str);
try {
url = gg.Search(String(str));
bnewwindow = gg.OpenNewWindow();
} catch (ex) { }
if(bnewwindow)
parentwin.open(url);
else
parentwin.navigate(url);
</script>
</html>
so if we wanted to add in right click on explorer that called rebol and
passed it some info, all we would have to do is to write a javascript
that built up the info we wanted to send and then used location.replace
to call the reb:// protocol and pass the info.
The technology is pretty simple, what I'm wondering is - what would
people want of such a protocol?
[4/7] from: bry:itnisk at: 6-Jan-2004 15:57
Okay it looks like Paul Tretter has done a lot of the ground work I
needed for user32.dll
http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=topwindo
ws.r
[5/7] from: petr:krenzelok:trz:cz at: 6-Jan-2004 16:11
Gerard Cote wrote:
>i Bran,
>
>I also thought about addind some COM interface for REBOL to be used instead of Javascript
as the scripting language for IE but my
>programming knowledge was falling short too soon. Sorry about that but life is like
that.
>
That is not imo needed. AFAIK even RT is interested in browser plug-in
resurrection. Of course I have not studied consequences of the plug-in
problem MS was sued patent-wise for. As a start, I would welcome
something like following:
1) View engine - encapped app
2) minimal desktop - current View desktop is way too much similar to
typical OS desktop. As for browser-plugin kind of app - users are NOT
looking for rebol and its related docs, but they visit certain sites and
want to try to run certain x-inet-apps. I have seen Java Webstart - it
is very similar of "GO" View desktop button section, just nicer and with
some auto-update abilities
3) autoupdate - 3 levels - a) core engine (plug-in) update - only needed
when new version of View is released b) desktop (navigation app, call it
whatever) package update - kind of similar functionality as how IOS
desktop is updated c) particular end user app update - default setting
via context menu (or other way) to allow or disable auto-update,
notification of user of new updates etc. with ability to download them
manually
4) installation - it would be good if ti could be installed as other
plug-ins ... users brought to certain download area, detection of
browser platform, offer of certain app. User would select place of
installation
(placement) and if possible, settings like proxy would be set automatically
5) new apps. So - once some site posts .rpl (whatever .rpl = rebol
player), user would click it, and if rebol player plug-in is already
in-place, it would be started and added to player's list (desktop)
6) in some distant future RT does plug-in with ability to display inside
of browser window, but I think it would not be needed imo for kind of
apps as demos, game packages, but would be handy for VID based forms
embedded in your html presentation ...
That is my pov, I even dare to think it may be a killer app, if promoted
a bit and if it would be deployed into user's web experience and would
not be difficult to set-up ...
Let's hope View 1.3 and 1.4 bring-in some more innovations to View low
level, as current demos are just too jerky, animations slow (show me
someone smooth and fast scrolling and I will send you bottle of beer
;-), keyboard navigation insufficient and making small games almost
impossible to produce ...
-pekr-
[6/7] from: rotenca:telvia:it at: 6-Jan-2004 16:34
Hi,
> That is not imo needed. AFAIK even RT is interested in browser plug-in
> resurrection.
RT should do the source code for plugin open source or better public domain,
so people can improve/change/adapt it.
> Of course I have not studied consequences of the plug-in
> problem MS was sued patent-wise for.
This is a fool thing for me, and, up today, i am not able to speak with logic
about fool things.
---
Ciao
Romano
[7/7] from: ptretter:charter at: 6-Jan-2004 10:53
Getting the windows titles would be much easier if RT would include callback
functionality at some point. ;)
I can't seem to comment about that enough.
Paul Tretter