AltME groups: search

I hardly ever email, but if he has no plans, it would be a nice second 
backend that I could make for my GUI dialect

Yes, I had a copy of your newer C library binding.  I compared the 
relevant sections and added in the appropriate parts.  Now I have 
a different problem, possibly due to me not running a gui on my Raspberry 
Pi.  Don't know yet if OpenCV requires a GUI to operate or not.

I think OS X GUI apps are fundamentally dual-threaded, with one thread 
for the GUI, so in the best case, it uses two cores more or less

Red executables (like R3 ones or any other language compiled to native 
code) are not supported directly by mobile OSes. So, it needs to 
be loaded and called from Java or obj-c, hence the need for shared 
library support.


The experiments with Red/System on Android was limited because using 
such approach, you can't have access to the higher level API, can't 
access GUI and need an hack to get it loaded. My goal was just to 
check that Red/System toolchain was able to produce code that runs 
on Android.

Petr, in the currently available code, the GTK binding can't function 
without a callback from Red/System into Red; as Doc says, to pass 
GTK events into the Red GUI dialect engine. So far I constructed 
the callback the ugly way, but there's official support now

Actually, it's fairly simple, think about a GUI app that sends a 
click event to your Red/System binding, how do you pass the event 
to Red code if you can't call it from Red/System. ;-)

Is the Android GUI AWT?

Nope, AWT is an old GUI built-in Java, so it's handy for doing simple 
GUI demo.

I will do a prototype wrapping of the Android GUI API in a few days, 
so you'll be able to put your VID-like dialect on top of it. ;-)

what kind of GUI is Android using? It surely is not AWK, nor Swing? 
Just trying to orientiate myself ....

what kind of GUI is Android using?
 Its own one. See the Android.* classes in Android docs.

Working in Android Studio a bit, looking into structures, what does 
it support, etc., I can't foresee, what our aproach is going to be, 
so lookinf forward to it. E.g. the IDE generates GUI definitions 
into XML files, ditto various configs, translations. So - what I 
expect is that you create basid .apk with certain featureset, and 
from that on, it will be manipulated from Red side. Justo wondering, 
if we will be able to dynamically generate UI elements, etc? Or will 
you suggest ppl to use your basic .apk, do certain work in Android 
Studio, and the supporting backend in Red? Or is your idea that ppl 
should not need to eventually touch sw like Android Studio?

When I talk about spped it's related to display and GUI ...

I'm not sure you're much interested in learning how to do it using 
Java objects, do you? It can be done already, but in order to implement 
proper abstraction for Red, we need at least objects support. Also, 
getting the GUI layer done is higher priority.

Actually, you got an error message sent to your logcat. :-) Once 
things will be stabilized for 4.x support, I'll redirect printing 
to the GUI.

Also, to be able to see any output in DOS console from an encapped 
Rebol app, I needed to change a flag in the executable file (sub-system: 
`console` instead of `GUI`).

R3 droid is a nice work. Hope to see it with nice GUI elements.

so, can you make a GUI out of all this?

There's also the other way around: most GUI toolkits such as GTK 
have an OpenGL widget, so with my multi-backend design I can make 
OpenGL backends for the widgets of those toolkits. You'd have your 
regular widgets and then the option to use part of the window for 
3D

Kaj, I ran into Carl today in Home Depot and we talked about your 
SDL binding for Red.  Do you think it would be difficult to make 
a binding for R3?  Carl was saying that he thought it wouldn't be 
too hard to convert R3-GUI to run off of OpenGL instead of the current 
foundation (was it AGG?) so it could be hardware accelerated.

Just curious.

Carl must've been talking about writing SDL into R3-GUI then.  Sometimes 
(often) he speaks above my level.

In contrast to libraries like Qt and wxWidgets, FLTK uses a more 
lightweight design and restricts itself to GUI functionality. Because 
of this, the library is very small (the FLTK "Hello World" program 
is around 100 KiB), and is usually statically linked. It also avoids 
complicated macros and separate code preprocessors, and does not 
use the following advanced C++ features: templates, exceptions, RTTI 
or, for FLTK 1.x, namespaces. Combined with the modest size of the 
package, this leads to a relatively short learning curve for new 
users.[citation needed]


These advantages come with corresponding disadvantages. FLTK offers 
fewer widgets than most GUI toolkits and, because of its use of non-native 
widgets, does not have native look-and-feel on any platform.

Well, I have mixed feelings ... Carl simply gave up on Rebol and 
its message imo ... felt strange: " I'm no longer in the mode of 
convincing the world about Rebol. I've learned a lot over the last 
couple years in the trenches." ..... later .... "So, I know really 
well now that Rebol is not for every developer.... but it would get 
more interest if R3+GUI was easy to download an get running on a 
variety of those devices on your list."

Kaj, need full GUI.

Yes, no REBOL then. Red has the GTK GUI on Raspberry, but it's basic 
so far

Henrik, it looks like your wait for GUI on R3 on RPi won't be long, 
based on Robert's announcement he just made.

What is the link to download r3-gui.r3? There's incrrect link on 
the webpage, leading just to the same page, not target file ...

gui docs ...

Robert, Thanks for the R3-gui release.  Do you have a date for Rebol 
and view engine also being part of a source release?  


These where one of the most frequently recurring discussions at the 
devcon.

r3-gui.r3 is exactly as long as the MS build script for a Windows 
driver :-)

Thanks, Robert. Could you briefly describe somewhere (in just a few 
sentences) the workflow you use when working on/debugging r3-gui? 
i.e is it possible to stay in the same R3 instance and rebuild (do 
you even need to be using the monolithic r3-gui script when debugging?), 
reload the script safely, etc.

So to work on / debug R3-GUI (Cyphre please correct me, if I'm wrong):

;; Load INCLUDE (once)
>>  do https://raw.github.com/saphirion/include/master/include.r


;; (Re-)load R3-GUI (multiple times; assumes you are in the R3-GUI 
toplevel directory)
>> include %loader/loader.r3

Yes, the most efficient way(in Windows) is to setup INCLUDE+R3-GUI 
loader to be executed everytime you click on *.r3 script. I'm using 
that and every change to the R3GUI sources is then automatically 
"propagated" once I run any R3GUI script again.

Yes, the strategy Cyphre describes is ideal for immediate testing 
of any changes made to R3-GUI sources.

Is this the best way to perform this check in http://www.rebol.com/r3/demo.r:

errout case [

 not value? 'size-text ["This R3 release does not provide a graphics 
 system."] ; this one
	load-gui <> 0.2.1 ["Wrong GUI version for this test script."]
	true [none]
]

ah, those services. I wrote some doc about what do I don't like about 
them (naming conventions, other design issues (from my pov)), and 
Carl told me, that he is going to completly overhaul them once GUI 
is finished. That never happened though ....

I didn't use R/S except for testing/playing but I like to see it 
working. But I think we have other priorities like GUI, Android etc., 
R3 itself..

Has anyone had any contact with Steven Solie about the Amiga R3 build? 
 I see from his site http://solie.ca/that in 2010/11/23 he had R3-GUI 
up and running.

It's actually pretty easy to see how they managed it. It was:

- A multi-language IDE (not a programming language, people already 
get those for free)
- With a GUI with an emphasis on modern graphic design (pretty!)
- With a fancy demo (more pretty!)

- With an initial focus on programming languages and development 
platforms that are already popular (built-in customer base)


Powerful IDEs are some of the only development tools that people 
are still willing to pay money for (i.e. Visual Studio). Most people 
can't choose what language they write in, but they more often can 
choose their IDE. And for crappy-but-IDE-friendly languages, an IDE 
can make all the difference in your productivity. They're not as 
helpful for really powerful extensible languages like Rebol or Perl, 
unless the language is so bad that just about anything would help 
(Perl). Plus, since an IDE is an end-user app you can afford to GPL 
it, since the only stuff built on it are add-ons - that doesn't work 
for programming languages unless they have a clear distinction between 
user code and built-in code that is distinct enough to not violate 
the GPL distinctions, because most of the competition is permissive 
- and without the GPL restrictions there is nothing to sell, so there 
is no business model to get a return on investment.


It's nice to point to other open source projects and say "See! We 
could have done that!" but unless those are comparable projects their 
success isn't comparable either.

OK, so it's a single-language IDE aimed primarily at the education 
market, still with a nice-looking GUI if not as modern, with an appeal 
based on Apple-fan nostalgia for HyperCard. That's a tougher sell, 
but since it's education market you can get away with GPL/commercial, 
and since it's Apple-nostalgia you can raise that much money from 
merely thousands of investors instead of the millions that you'd 
need if you were going for a less-well-off target market. Makes sense, 
but it's still nice to see.

And a better console, built on R3-GUI. And better text-mode console 
support for systems where you can't use a GUI.

BrianH: well, I was long time a proponent of R3. What attracted me 
most were devices, even more modularity, etc. But - let's not be 
deluded. If you are careful enough, you could see, that ppl mention 
some things here or in regards to Red, eg. asking - is View going 
to be available? Let's not ingore, that many ppl started to use REBOL, 
because it was kind of complete package - console, call, dbases, 
networking, gui ...

Still, all of that can be added on or retrofitted, that's the whole 
point of being modular. Having them implemented and available before 
3.0 would be a good idea for marketing reasons (don't knock those, 
they're important), but not having them done before 3.0 won't break 
user code the way not doing core semantic changes before 3.0 would. 
People will be working on these before 3.0 comes out because they 
need them, and the ones that we as a community consider to be the 
most important to include in 3.0 will likely be worked on the most. 
But the great part about that stuff is that it doesn't have to be 
developed as part of R3 itself, just like the GUI is being developed 
separately.

The generic problem to solve is this: You somehow have to specify 
what should happen for different actions. 


Let's start with the "somehow have to specify what should happen". 
For this you have some options:

1. Write the application logic code in the GUI spec block. For sort 
stuff OK, for long not.

2. Just call a function from the GUI spec block and write the rest 
somewhere elese. That's IMO the best way. I used FSM and just send 
"application logic events".

The next part is the "for different actions". Same here:

1. Name them explicitly on-* and specify the code with one of the 
options above.BTW: IIRC R3-GUI has click and right-click blocks for 
convinience.

2. Define an implicit mappging from block order to event type. 1st 
block = click, 2nd = right click, 3rd = double left, 4th double right, 
etc. IMO that's not a good style.


Overall what I never liked about VID was that is was not explicit 
enough. For big projects that's a must. For small you might skip 
this but if those projects get bigger, you are hit again.

We can always build a "shortcut" dialect like VID on top of R3-GUI, 
for common simple patterns, once R3-GUI is complete.

The problem is, that while the R3-GUI is now more flexible by removing 
reactors, it is also more difficult to understand. I remember trying 
to understand the 'on-action issue in the past, now I briefly re-read 
the doc, and I still can't understand the design. I need following 
things to be cleared up for me, so that I can both use it, and possibly 
explain it to others:


1) If you look into Actors docs - http://development.saphirion.com/rebol/r3gui/actors/index.shtml#
, there is no mention of 'on-action actors. There are many actors 
listed, but not the 'on action one


2) The 'on-action actor is mentioned in the attached doc at the same 
URL, describing, why reactors were removed. So here is the definition 
of 'on-action: 

        a) "The ON-ACTION actor is useful if the style needs to call some 
        default action from multiple places (actors) in the style definition." 
        - understand the purpose, but why and when I would like to do such 
        thing? Any example easy to understand? Just one sentence maybe?

        b) "For example, the BUTTON style needs to call the default style 
        action from the ON-KEY actor and also from the ON-CLICK actor, so 
        it is better to call the ON-ACTION actor from the both code points 
        to avoid the necessity to override multiple style actors." - looking 
        at button or even clicker style definition, I can see no such stuff, 
        as 'on-key or 'on-click calling anything named 'on-action. That is 
        the part that is most confusing for me, and which did not help to 
        understand the 'on-action a little bit. Are we talking about the 
        'do-face here?


There is also a question, if better name could be found for 'on-action. 
Unless I can fully understand, what happens here, difficult to suggest. 
Now to make it clear - I am not judging architecture, just trying 
to get my head around the docs and button/style examples. And being 
average reboller - if I have difficulcy to understand it, the chances 
are, there is more ppl, which will strugle in that area?

I think ppl in kind of an wait mode. Some interested in Android in 
general, some interested in Red progress, som interested in Ren, 
most of us busy other way.  Max in fact is doing a good job - he 
tries to use the system in a practical way. My questions are just 
theoretical, just by reading docs and looking into the code. I know 
I will be back to GUI at some point, just dunno when ...

About excuses - there are imo no excuses. As I said - we are just 
few, and ppl are busy with other things too. As for those really 
needing GUI right now (it's not me for e.g.), I think, that some 
ppl prefer what they know R2 VID, RebGUI, just because of typical 
entry barrier. There is nothing wrong with R3-GUI imo, and from what 
I studied in the past, it is much better system than R2. Sometimes, 
it is difficult to find out real reasons, why ppl react this way, 
or that way, I just dunno ...

I think that there is no way to take it as offense. Noone said a 
bad word against R3-GUI today imo ...

To all people who want to dare in Documentation R3 GUI labirinth 
, you may use http://rebol.informe.com/wiki/view/Main_Pageto help 
community.

100% of voters on http://rebol.informe.compoll aske for Linux GUI

Is there a GUI that currently works with Carl's last r3 alpha?

Is there an equivalent to Henrick's list-view in R3-gui?

Josh, there's an r3-gui group that might be a more appropriate place 
to ask.

I'm just wondering (really, just that): is dev capacity (i.e. Cyphre 
GUI. other's on OSX, 64 bit) the limiting factor to accelerate in 
the short term? Or money?

I would want R3 on Android with GUI, GPS, Camera support. And R3 
64 bit Linux server side ("Core").

Than we have fundamental frameworks and libs like R3-GUI etc. this 
is a mix of Rebol code and enhancements on the C/D level.

eg. the descriptive text of rebol 

--

It's a messaging language ` 'rebel' not 'ree-ball' ` code is data 
and data is code ` CGI? Yes ` 40+ platforms ` only 250K-500K ` console 
or GUI ` Yes, just a single file ` commercial versions = same core 
+ ODBC, SSL, and more - shallow learning curve, amazing depth ` keep 
IT simple ` if you liked "The Matrix"...
--


is lengthy and not focus... it also do not need to be at the top 
of every page...maybe it should go below 'About'

Could add/replace some of that with "cross-platform, CGI, console 
and simple GUI dialect etc.."

Back in February (!), Anton wrote:

<<By the way, something that I never really liked is the short rebol 
description at the top of rebol.org.>>

OLD TEXT: <<It's a messaging language. 'rebel' not 'ree-ball'.

 code is data and data is code. CGI? Yes. 40+ platforms. only 250K-500K.

 console or GUI. Yes, just a single file. commercial versions = same 
 core + ODBC, SSL, and more -

 shallow learning curve, amazing depth. keep IT simple. if you liked 
 "The Matrix"...>>

We may be slow, but we get there:   http://www.rebol.org

The banner text has been updated to ready pretty much what Anton 
suggested.

Thanks Anton!

I attempted to rename button.r to vid-button.r so the new script 
should be deleted and the old one renamed if possible.  As for the 
rest of them...

wizard.r  TO vid-wizard.r
group.r TO vid-group.r    
drop-down.r TO vid-drop-down.r   
dragbar.r TO vid-drag-bar.r       
date.r TO vid-date.r


Since we won't be calling the GUI Dialect in R3 VID the new names 
should make what the scripts do clear even after R3 GUI scripts start 
popping up...

maybe, we could eventually have more than one picture, like pics 
which are specifically tagged as gui screenshots, for example.

MDP-GUI to be the interface for writing datas to Carl's blog script. 
does the idea sound usefull for you ?

I tried an earlier version of MDP-GUI but did not keep up with it. 
 I would like to try it to understand better its functionality.  
I think you have some good ideas there.

I use IOS to keep version control of my website...so I usually have 
things integrated with that...but the GUI could make it easier...does 
it run makedoc2.r as well?

well i thinkif you exit movable text i will include it a soon as 
possible to MDP GUI that was part of the defaukt fucntionnality I 
allways wanted in it  but has I don't get the knowledge to handle 
the task i send it to futur time

a good editor i think is the SCITE made for GUI4CLI  it includes 
all this kind functionnality

that not the applicable to MDP-GUI but for rebol rad tool it could 
be very nice

eFishAnt for moving text if you arrive to a good solution send me 
a post thru altme I will integrate it asap into MDP-GUI

that could be a good point to explaine to newbies how to influe dynamicly 
to default area text :)

Azureus - very good Java based client with all stuff needed - auto-updting 
etc., nice and responsive GUI. I wonder if REBOL would handle such 
app :-)

OpenOffice 2 is a good candidate, though, because they've made the 
GUI much more native

Dont know that eally well myself. what i firued out: usually (debian, 
suse) startup-scripts are in /etc/init.d. on debian there is a /etc/init.d/skeleton 
as base for own script. then there are the runlevels in /etc/rc?d/. 
links there go to /etc/init.d/ an tell the system what to start/stop. 
the numbers in the filenames are the priority, lowest run first. 
Usually there is a gui-tool like yast or ksysv which scans /etc/init.d/ 
for scripts and makes the appropriate links. tricky things are to 
write the startup-script, to figure out which runlevel to use and 
how the os figures out what to stop. although if you dont need that 
runlevel smartness, because you call it on boot and let it be killed 
by shutdown, you can just use a normal bash-script.

(runlevels tell which servers etc to run. so there is one with everything 
off for maintenance, one for console-use, console with network, console+network+gui-login, 
these with and without network, maybe some others)

Festival is a software made in Scheme ( a Lisp clone) that allow 
voice synthésis (debian pakage are available on bedian.org website 
and can be acceded using Synapse GUI debian DLand Install software).

To run my solution I simply make a bash that tests if festival is 
yet running or not and then runs it (I'm using 1.2.1 REbol version 
for linux ...) and then runs my GUI software ;)

Does anyone have any ideas about how to approach a web-based gui 
that allows users to upload multiple files at one time without having 
a series of  "inputs?" I'd like to have users do a ctrl select when 
they are browsing for multiple files to send. Thanks.

My uplink speed kinda (no, it pretty much completely) sucks but I 
offer free hosting to any rebol that wants it at peoplecards.ca. 
 I just ask for patience if a new service needs to be installed while 
I work out kinks and the user needs to know that it's home based 
with a not-so-speedy delivery pipe and I offer little in the way 
of frills; meaning it's sftp or ssh cli, not cPanel or other gui.

we have looked at it and at the same time looked at phpsavant 
 http://phpsavant.com/yawiki/index.php?page=StartExample


for us, our key concerns is maintenance from the developer point 
of view. We want the team to stick to one language (or markup)... 
there will be times in a project, that you may not have the luxury 
of a designer...so the developer still end up working on the apps 
GUI (or look-n-feel).

have you seen http://www.nvu.com/? Gecko based. They aim for something 
like Dreamwaver. IIRC, with dreamwaver, if you have e.g. some module, 
you can provide "plug-in", simply that web designer will parametrise 
you module using GUI and the rest is done under-the-hood ....

I do intend to make glass the standard high-end GUI engine in REBOL 
.

rebol.org library already have tagging for the scripts.


Both in terms of levels ["Beginner" "Intermediate" "Advanced"] as 
well as the domain ["cgi" "gui"] etc...


Perhaps there is a way to feed the cookbook examples into rebol.org 
and let the Library be the holding place for future cookbook examples.


There are '3 major' rebol sites (those with rebol in the domain). 
And they are rebol.com, rebol.net, rebol.org.

It is not incredibly clear whether certain docs should be in .org 
or .net. 


Other suggestion to consider is how can we leverage off works done 
in various sites and avoid duplication. Why not let rebol.org be 
the host for cookbooks as well?


I would think new comers will prefer to find both cookbook examples 
and other contributed scripts all in one location. Rebol.org also 
lets you search the mailing list.

Good points, Maarten about accessibility.


If I were looking for an alternative REBOL GUI and typed REBOL GUI 
into Google, I'd probably soon conclude that there wasn't one. And 
that might end my evaluation of REBOL.


Having many useful tools scattered across personal websites has other 
weaknesses too -- look at how hard it's been for people to find Gavin 
MacKenzies's XML libraries after his personal website went offline.

that is the set of proto functions - those string manipulation functions 
- you do use them everywhere ... even in graphics ... you have face, 
which has pane (container), and you insert, append, find, replace 
another gui elements, and then you call 'show ...

the better way to gauge useage is not by frequency within one script 
but by useage amongst many scripts... where useage within that script 
many times still only counts as one.  I'd use the rebol.org site 
to scan scripts from any given group and put usage from them.  Thus 
networking would score view as almost 0 where gui would place view 
as the most used word (in every script)

My colleagues suggest that we use the View GUI. He feels that it 
is simple enough to code a graphic interface with this. I admit I 
have not looked into View much. My preconception is that adding the 
graphical layer complicates things too much (like Windows/C++). Maybe 
I'm wrong as Rebol is concerned?

Terry, I understand Oldes'  POV,  their tools but really hard to 
use. The language as the foundation for GUI programs is beter than 
the actual GUI programs.

Thanks Oldes, I will try that. The dialect and AS are becoming clearer 
now with all the info you have given me. I look forward to writing 
lots of cool things. Thanks for the hint about the two main parts. 
I wondered how they were connected as most of the AS tutorial have 
you create something with the GUI then add the AS part.

Rebol/Flash dialect (RSWF) version 2.5.0 is available!
compressed: http://box.lebeda.ws/~hmm/rswf/rswf_latest.r(89kB)

uncompressed: http://box.lebeda.ws/~hmm/rswf/rswf_2.5.0.r(331kB) 

as colorized HTML: http://box.lebeda.ws/~hmm/rswf/rswf_2.5.0.html
 (885kB) 

What's new:

- New swf-parser included which replaces old exam-swf function (useful 
for importing foreign SWF files)

- Added implementation of Class definitions for SWF versions 6 and 
higher (I have to create some examples)

- Added new 'trace function into actions (which can be use to compile 
swf files with or without trace calls easily)

- 'require and 'include now accepts block of files or urls (I should 
modify my rswf code colorizer to show included files as well)


Here is also new example how to include first of GUI elements: http://box.lebeda.ws/~hmm/rswf/example/swf8-cliphandler

In the future I would like to create something like mini Layout dialect 
which will be used for better positioning of the new GUIs I'm working 
on.

Version 2.9.0 ... now with Calendar GUI and fixed one nasty bug in 
'IF compilation after 'EITHER rule
http://box.lebeda.ws/~hmm/rswf/example/swf8-layout-calendar

and one more reason - to hack a default Flash gui components is for 
me much more difficult than make my own from scratch

If I can throw my two cents here. Terry is right to complain, because 
you can feel he cares, it's not destructive criticism. Pekr is saying 
he's a realist, but to me he sounds more like a dreamer (no offense).Flash 
is a Virtual Machine that lives in the browser. Rebol is a VM that 
lives on several OSes. Flash VM is present on 99% of the browsers. 
Rebol VM is not present  on browsers (plugin doesn't count because 
last time I tried it wouldn't install, and last version is more than 
a year old), and it is present on OSes of a small number of creative 
developers and hobbyists. If I had to develop a commercial app for 
the web, Flash and Flex give me extensive documentation, and a whole 
framework. Rebol can't compete with Adobe, and should not. Last week, 
I developed a GUI in Rebol and Rebgui that would have taken me four 
times longer in any other graphical toolkit, and I had a knack at 
it. But this app is for internal use. Rebol is a great language, 
and I would like to see it evolve as a computer language, not as 
a throw it all in kind of gizmo. It should go Open Source, because 
RT doesn't have the means to provide versions for all platforms. 
Where is the rebol for NetBSD? Last version is 2001. If RT hasn't 
the resources, let the developers do it. I want to run rebol on an 
internet tablet. I had wanted to run rebol on a palm (not anymore 
because Palm is deas, sort of). But the Nokia tablet run debian linux. 
There is no reason for the unabailability of rebol. It is just a 
matter of building it and packaging it. Who has the time for this? 
Plenty of people, they're just not at RT, because there people are 
busy with more important things (like developing the product).

time limits are mostly annoying, but doesn't hamper usage in that 
time. I don't think the GUI or other things should be obscured

Yes, with the DLL interface you can theoretically create native-like 
GUI system according to your needs if you have enough time/motivation 
;)

If you write VID/RebGUI like dialect with binding to Windows native 
GUI why not? :)

Pekr: You can create and control any windows dialog if you have the 
API available. (and this can be applied to any other OS feature). 
So it is possible to create native GUI controlable at the higher 
level of some dialect(simmilar to VID/Rebgui). People who are making 
common apps don't need to access it at face level but ofcourse such 
system would be based on face-like objects with methods related to 
Windows GUI elements etc.

the same could probably be done for OSX/Cocoa... it would solve many 
issues with GUI nativity in OSX.

If you really need noative GUI then this can be the way but remember 
this is also *lot* of work multiplied by each operating system ;)

which is why it's probably not worth doing for anything other than 
Windows and OSX. For linux, it would be ... wow... how many different 
GUI systems do we have there? :-)

I agree that native GUI/feel should not be a main part of Rebol, 
but it should not be a luxury item either that you have to pay for

Let's see what a "neutered" plugin can do:
- REBOL/Services
- All of REBOL's GUI and graphics stuff.
- Access browser data (that is site-specific)
You can do a lot with that. Look at Flash.

Yep, understood. That's probably why the current plugin also cannot 
detect 'activate and 'deactivate events when you are focusing/unfousing 
the browser window. Do you think this could be also improved? It 
is useful for application to know when user switched to other window 
than the one with running plugin so it could manage the /View GUI 
appropriately (focusing/unfocusing fields, areas etc.)