AltME groups: search

I return the event, yet nothing happens. Oh, well, I've studied RebGUI 
code and it does the same thing as I do.

After loading RebGUI tab-complete gives error for undefined values 
also.

try 

clear head mydropdowndata/data

if using rebgui

Both make sense. We use a name generator on our RebGUI grid implementation, 
the nice thing about this is, that it's position independent. If 
the column order etc. changes, the names stay the same.

it's a RebGUi issue

Leaving all RebGUI specialities aside, can't you just patch the widgets 
FEEL/ENGAGE to allow objects being passed to it? If there is a point 
where you're in control to FOCUS the face in question, that may be 
possible.

Thanks .. looks like send-keys solves my problem too :)  I needed 
to send a backspace to a rebgui field to initialize it and this works

@Henrik:  I now understand the "hoops" that need to be jumped into 
in order to get graphics to happen in REBOL. 
Is REBGUI an extension/replacement for VID? 

I sure hope that the answer to Kaj's question is "yes" - cuz that 
would make the "help sytem" much more useful, IMO.
Thanks for the input!

Rebgui is an alternative to vid ... it has more widgets but is less 
flexibles

RebGUI SHOW is not the same as SHOW for VID

I know. The problem is however the same with RebGUI's SHOW-NATIVE.

Well, I think that there should be some debate before a long standing 
behaviour is changed.  I have lots of users using a rebgui application 
that depends upon the previous behaviour.

just manually downloaded latest SVN changes - gee, the design is 
getting worse and worse. Those rounded buttons are so bad it is not 
really funny or question of ones aestethic feel. RebGUI was initially 
not pretty, but at least nearly XP look. Now it is what?

I think that Rebol community really is in need of getting some graphician 
on-board. Not only for RebGUI, but for future VID too ...

I haven't checked up on RebGUI lately. Does it look the same?

Maxim - your glayout looks consistent, as buttons fit the rest. Current 
RebGUI buttons are a bit ... ehm, strange ...

hmm... aesthetically pleasing draw block, you say? how does that 
work? do you skin RebGUI that way?

http://trac.geekisp.com/rebgui/browser

Ashley, what controls the highlighting of the word in the spellcheck? 
 I note the tour demo keeps the suspect word highlighted, but my 
change somewhere doesn't.  Is it an option in the behaviours in rebgui-ctx? 
 Or coded inside the spellcheck function?

the current rebgui buttons look too rounded for me .. so if an alternative 
were available ...

is there a difference between how INIT works in RebGUI and INIT in 
VID?

http://rebol.hmkdesign.dk/rebgui-btns.png<--- well, it's a start.

what do you mean by "more consistent look"? Overall refactoring of 
RebGUI? Hmm, maybe Henrik needs to be put on contract for one week, 
to change default coloring and styling, to make RebGUI more attractive 
:-)

I am not either ... in fact I held way too long off from rebgui, 
becuse it looks dull, much worse than default VID

in that case http://rebol.hmkdesign.dk/rebgui/button.r

but OK, your button is definitely better than initial Ashley's attempt. 
Well, IMO, but I think most would agree here? I will let you adapt 
further some styles and let's see how feel of RebGUI changes in  
general ...

I haven't delved to deep.  The last cut of RebGUI I pulled out of 
svn causes a segmentation fault on my Debian Etch RC1 system.

>> do %tour.r
Script: "RebGUI widget tour" (16-Feb-2007)
Script: "RebGUI system" (18-Feb-2007)
>> q
Segmentation fault
[blue-:-dev]:~/gui/rebgui$

Note I did nothing other than start tour, and close it

REBOL/View 1.3.2.4.2 16-Mar-2006 Core 2.6.3

[blue-:-dev]:~$ uname -a

Linux dev 2.6.18-4-686 #1 SMP Wed Feb 21 16:06:54 UTC 2007 i686 GNU/Linux

Just so ya know.

Try:

	do %rebgui-ctx.r

then a simple display:

	display "test" [text "Here"]
	do-events

They'll be fixed when the RAMBO detect face bug referred to previously 
is fixed. In lieu of that I made two changes:


 1) Optimized tooltip checking (saves about 5-10% CPU in the case 
 of tour.r)
	2) Tooltips now default to off


I'd like to know how they seem to work for Robert as the code was 
a 100% cut & paste job from his. I suspect the key is to run it under 
windows and ensure that not only is Task Manager up but that the 
RebGUI app (tour.r in this case) is in the foreground. I noticed 
that clicking between a running tour.r and Task Manager (with tooltips 
on) makes a big difference between the reported CPU usage. Perhaps 
Robert is only seeing the later (or is running it on hardware that 
obscures the problem ... I'm on an old Pentium M 1.1GHz here).

can you provide a small demo of your rebgui with tooltips like this?

To use our latest RebGUI version, just create a distirbution from 
projects/rebgui and use this rebgui.r file instead of the one included 
in the test directory.

RebGUI expert needed on REBOLTalk:
http://www.reboltalk.com/forum/index.php/topic,739.0.html

I keep investing into RebGUI and it will continue, but at the moment, 
I think we drift to far away. IMO it doesn't make sense to have two 
forks. I really want to backport/merge things but for this I need 
some help.

Further: http://trac.geekisp.com/rebgui/wiki/WidgetList#drop-tree

I think we drift to far away

 ... depends on the extent to which you have changed/enhanced core 
 RebGUI functionality (e.g. rebgui-*.r scripts). If most of your changes 
 are isolated to new/enhanced widgets then there is really no drift; 
 you can plug your widgets into the standard RebGUI engine and it 
 will all work. If you want to keep your changes in sync then I suggest 
 2 simple practices:


 1) If you need a version of a standard widget (e.g. radio-group) 
 to do things that are app or design philosophy specific then create 
 your own widget instance and suffix it with an identifier, say XP 
 for XPeers in your case (e.g. radio-groupXP). Suffixes are preferred 
 over prefixes as the alphabetical sort order of the widgets determines 
 their load order which may affect dependencies ... see text.r and 
 label.r for examples of this.


 2) Only keep and maintain a divergent Widgets directory ensuring 
 that your widgets continue to work with the standard RebGUI engine 
 (i.e. rebgui-*.r scripts). If you need the base engine enhanced (e.g. 
 to support tool-tips or proportional resizing) then let's isolate 
 those changes and get them into the base distribution.


You should be able to create and maintain your own widgets without 
worrying about divergence as most of the design effort should be 
going into the functionality of the widget(s) themselves. If your 
widget needs specific changes/enhancements to the base engine then 
we need to sync those changes at the point you need them. Trying 
to retrofit these after the event, and after multiple divergent engine 
changes, is going to cause problems as you've discovered.


From my end, the 3 major changes you should probably try and work 
back into your fork are:

	1) UI settings: mostly confined to rebgui-ctx.r

 2) rebind func added to all widgets prior to init and rebgui-widgets.r 
 enhanced

 3) tab-panel rewritten to operate significantly more efficiently 
 (tab-panel.r and associated rebgui-edit.r changes)

And, RebGUI has shown to be asolutly perfect in this. It's simple, 
efficient, and comfortable enough to write big apps. My app's code 
base is about 400K now, than we add 190K RebGUI, and some other stuff. 
So overall the  pre-processed script is about 1MB in size.

problems with tooltips

 ... note that since 11-Mar these and other problems have been solved 
 in the latest RebGUI Beta 2 builds.

Isn't Ashley making a Chat widget?

 ... chat, icon (SVG) and a simple tree widget (suitable for request-dir) 
 are in development.

RTF Style ... possible to use it in Rebgui

 ... RebGUI had this initially, but it was more trouble than it was 
 worth IMHO as (a year and a half ago) TMD (Text Markup Dialect) was 
 going to make it redundant. I believe R3 includes rich-text support.

http: ...

 ... I based my %render-rich-text2.r on this code but improved upon 
 it dramatically as we (shadwolf and I) were trying to use it to render 
 MD2 and MDP documents. Remember all the MDViewer and MDP-VIewer stuff 
 that was floating around a while back? ;)

Ashley, you will find it in the RebGUI directory on xpeers. That's 
the code base we use. Just log in, and take a look at projects/rebgui. 
That's our distribution.

BTW: Can we somehow align while you do RebGUI 2? I want to follow 
the new release and provide our code to it as well.

I was on xpeers recently .. didn't see a rebgui directory.

Projects/RebGUI

you will find it in the RebGUI directory on xpeers

 ... got it the first time, just making sure I was looking at the 
 most current version. FYI, tooltips had me baffled for a long time 
 (they worked for you, consumed tons of CPU for me) until I realized 
 they were only a problem with the new tab-panel implementation ... 
 which now stores all tabs in a pane and uses the show? attribute 
 to work out which one is visible or not (the original stored hidden 
 tabs in a data block). The fix was simple, change the tooltip code 
 to ignore faces with show?: false.

strip tree widget from drop-tree

 ... the tree widget I'm working on is similar to text-list but with 
 leading triangles (indented by level) that toggle between sideways 
 (close leaf) and down (open leaf). Not sure whether Cyphre's one 
 is based on the same [simple] concept.

Can we somehow align while you do RebGUI 2?

 ... as discussed previously (see post from 10-Mar), with the key 
 points being:


 1) Use (and possible extension) of global UI settings (colors, sizes, 
 effects, behaviors) in %rebgui-ctx.r

 2) Widgets should define a 'rebind func if they need to change a 
 statically bound UI setting (e.g. color)
	3) Use the new tab-panel widget

and a fourth:


 4) Layout uses 'tip (not 'tooltip) to specify the widget's tip string!


Note that the current build has had most widget-specific exceptions 
removed, especially from %rebgui-edit.r; and that /dialog (hence 
popup) code has been rewritten to support true modal dialogs (that 
can in turn call additional modal dialogs). The later improvements 
are courtesy of recent REBOL/VIew popup changes.

I'm looking at adding a simple format mask attribute to RebGUI for 
editable widgets such as field, area, edit-list and drop-list. Basic 
idea is that if a bitset! exists in the spec it is assigned to a 
new 'mask attribute which is checked prior to every keystroke that 
would insert a char into the text attribute. This would allow specifications 
such as:

	display "Test" [
		field (charset [#"0" - #"9"])
		field digits
		area no-special-chars
		field phone-chars
	]


and has the advantage that the code resides within the RebGUI edit 
feel and can be used by any editable widget. Specification, as above, 
is also natural as bitset! is not mapped to any other attribute and 
is a natural mapping for character edit masks.


If an invalid char is encountered then the keystroke will be discarded 
and perhaps the field can blink or flash as a visual cue?


I'm also toying with adding a datatype! attribute to the spec which 
would be used like:

	display "Test" [
		field digits integer!
		field digits-and-seperators date!
	]


and create an on-unfocus trigger that tries to "set-text self form 
to-datatype" and blanks or blinks the field on failure (and prevents 
leaving the field).


Need to nut out exactly how this would work, but the question is, 
is this useful for folks; or is it more trouble than it's worth (given 
that it is not a fully fledged edit mask solution).

What font names look good? List them here and I'll add them to the 
default ones.


Note that as the new ctx-rebgui/font? function filters out fonts 
not available on the machine running RebGUI we can build up a superset 
of default font names for the big three: Win, Max and *nix.

Graham - why don't you use grid? Is it incompatible with current 
rebgui version? It is not as powerfull as Henrik's grid, but surely 
few light years ahead of table. You've got very simple usage help, 
but workable imo ...

Graham - IIRc I sent you very brief doc, which shows some usage. 
Even with such doc, you are able to have xy times better grid than 
table is. But - I have to check with Cyphre and I already asked him 
for upgrade, as his grid worked with his RebGUI version, and I would 
like to use official beta 2 definitely ....

As RebGUI is aproaching 1.0 release, I would like to know your opinion 
on following - how do you construct and optimise your GUI? So far, 
if you look at tour.r, it reminds me of one big dialog configuration 
box. Not sure what to do about it, maybe it is a given, as widgets 
we have do suggest such layouting. This debate could open discussion 
about eventual addition of potentially missing widgets. My questions 
are:


- are you missing kind of MDI application scheme? Parent window, 
containing one or more child windows, which are not able to being 
moved away from its parent. We used that design much, but I am not 
sure anymore it is vital, as with latest system, we use two monitor 
set-up, and by simple accelerator key we can navigate window being 
moved between displays. Having MDI available, we would probably need 
rebol/view native windowing system. So - is anyone missing something 
like that?


- do you somehow optimise your display? Isn't it like following? 
- with using tabs, everything is in memory, whereas it eventually 
is not needed? How do you divide your application, if you would like 
to have kind of load-on-demand aproach?


What styles do we miss, to further help us have more complete GUIs? 
I created screenshot of potentially two usefull widgets:

http://www.xidys.com/widget-drop-tab.jpg
http://www.xidys.com/widget-vertical-tab.jpg


Especially with the second one, I think it could be usefull. It is 
used by many applications. It is kind of mixture of tab and tree, 
but not necessarily with multi-level aproach, just one level of nesting, 
mostly represented by icons, text, or icons plus text. I would like 
to know your opinion.

Pekr; If this is an open question, and not just to Ashley,


I use what I'm given.  In that I build apps (not many so far) using 
the toolkits I see in front of me.  I'll definitely retrofit my existing 
Fire and Rescue Management app with a Menu once the flurry of RebGUI 
development slows down a bit (and please don't slow down, love the 
flurry).


Unless my systems crash, I spend zero time optimizing, wait I take 
that back, I try and follow my own style guides while I'm writing. 
 There is the odd backtrack to get a tab panel to line up nicely 
inside another.  Other than fixing glaring visual ugliness, no optimizing.


I design with a 'small town business model'.  I hand deliver applications.


If I go and snag a feature that goes quirky during my initial testing, 
I dump the widget and look for another.  My 0.4.0 build of RebGUI 
had sticky persistent drop-list's so I used labels and a special 
requestor.  I'm not sure I'll retrofit these.


The easier things are out of the box for me, the happier.  Give me 
the tool, describe how it works and I'm satisfied (when it's as elegant 
as REBOL, RebGUI and RebDB).

well, vertical tab - beware - those are not rebgui examples, just 
external apps - for inspiration :-)

Understand, I like the "real estate handling" part of such a widget.
Is it http://trac.geekisp.com/rebgui/?

I'm using http://svn.geekisp.com/rebgui

Build 75 uploaded to SVN. Fixes some problems introduced in build#74 
and improves widget documentation. See here for a complete list: 
http://www.dobeash.com/RebGUI/widgets.htmland also the updated %tour.r 
Widget and Function Ref tabs.

trac.geekisp.com/rebgui

... and I must laugh, as we still think, that most ppl are able to 
sort out, what to actually do. That is total mistake, however, and 
prevents many from even trying rebgui.

http://trac.geekisp.com/rebgui/browser/get-rebgui.r?format=raw

noone should be forced to use some stupid helper tools suited for 
developers. We've got some users interested in RebGUI, not SVN gurus 
...

Where do I get it?

Just click the 'RebGUI' icon (under REBOL Demos) 
in the REBOL/View Viewtop (which can be started by typing desktop 
at the console).

would anyone agree to make following the default rebgui coloring/look? 
Basically to achieve this it is very easy:

1) set 'over to sky
2) change rounding to 1
3) set window color to wather
4) set effect to: gradient 1x1 white water

http://www.xidys.com/new-rebgui-default-look.jpg

I would call it "white water skin" :-)

it also somehow reflects rebgui website coloring. But I think the 
look is upon each of us. It is just that it looks better to me than 
default look ...

Note that the easiest way to grab the latest SVN build (without using 
any client s/w) is via a simple REBOL script like this:


 write %rebgui.r read http://trac.geekisp.com/rebgui/browser/rebgui.r?format=raw

 write %tour.r read http://trac.geekisp.com/rebgui/browser/tour.r?format=raw


%rebgui.r (the complete merged distribution sans %tour.r) is now 
regenerated and uploaded every build.

segmentation fault at quit on Linux is very common with REBOL. I 
don't think it's rebgui related.

I'm wondering whether, for RebGUI, this approach is actually "better" 
than the current soundex approach? If it means having to pick arbitrary 
literary works for each language then what's the point? I was hoping 
that someone had pre-generated some "standardized" dicts somewhere 
I could grab.

http://trac.geekisp.com/rebgui/browser/rebgui-edit.r?format=raw

The source code for area is here:

	http://trac.geekisp.com/rebgui/browser/widgets/area.r?format=raw

feel free to propose a solution.

Updating my script to latest rebgui .. have to do show-color: :set-color 
etc as too much code to change.

ctx-rebgui/widgets/rebind is what you're looking for. Note that if 
you're using request-ui then this does it for you. Basically each 
widget now knows how to refresh itself when relevenat colors, sizes, 
relevant or effects are set/changed.

ctx-rebgui/sizes/font: new-size
ctx-rebgui/widgets/rebind
reshow-main-display (if relevant)

Have you thought of adding them to rebgui ?

So they reside in the global name space, or do you define them within 
ctx-rebgui?

but one could put them into ctx-rebgui

this is my rebgui interface to the rebelBB.cgi script

Build 78 uploaded to SVN. Includes the following additions:

1) New chat widget

	chat data ["Bob" none "Comment." yello 1-May-2007/10:00:00

2) New on-fkey handlers

	ctx-rebgui/on-fkey/f3: make function! [face] [...]


3) Soundex spellcheck logic replaced with new algorithm as discussed 
above


4) New, smaller, dictionaries (sans soundex codes) to be uploaded 
within the next few days

5) request-font enhanced (now has multiple refinements)

6) %tour.r updated


Note that the chat widget has a known display problem when it appears 
on a tab or is resized. The fix, adding a 'show in its feel/resize, 
appears to eat other widgets resize events. Not sure if this is a 
REBOL/View bug or not. Anyone who knows of a fix please speak up!

Ashley, what is yet not merged from my fork / the old rebgui release? 
(I assume this is already the V2 stuff).

Perhaps we need a "rebgui" for R3 as well ... ie. a simplified gui

The tough thing to appreciate is that VID is a general-purpose entry/mid-level 
dialect.  R2/VID has been in the wild for 6yrs(?) now and we have 
certainly gone through periods of isolating key weaknesses, but we 
all have a tendency to have had starry-eyed visions for what VID 
should be.  The practical gets mixed in with the possibility when 
it's time for action.


I think the community would be better served with a strong VID alternative 
(not as a slight to RebGUI which does very well acheiving its stated 
aims) not bound by Carl's constraints for the entry level language, 
and open (as in open) source with very clear aims.  It has to be 
independent and perhaps needs to span R2 and R3, at least initially. 
 We have the capabilities, resources and talent to do it, but instead 
try to hammer these ideas into VID.


This isn't intended to be a rallying cry -- it's just my assessment 
based on observation and involvement.  Such an undertaking would 
have inevitable difficulty overcoming the differing visions of interested 
parties.  Conversely, it's within us to create an enduring, enviable 
framework...

that remembers me how we started rebGUI with rebol community ashley 
and me. First ashley and me  were working on MakeDoc and MakeDoc 
Pro dialect to VID renderer we emulate each other alot and from this 
exange born the constatation that common VID face set was not adapated 
to usual GUI  or big amount of face handling. And from that constatation 
Ashley proposed to make rebGUI  wich we presented as a major enhancement 
to VID layer keeping the main idea alive "KEEP IT SIMPLE". Ashley 
proposed the community to share idea or suggestion and on every single 
widget the community proposed we got a discution and code proposition 
to achieve this goal.

sure the most of the work was lets say the assembly and diffusion 
part of rebgui was still done by 1 guy Ashley wich have the main 
vision of the project and was our guarant to get end edged library 
usable by any one but many were the  contributors and that leads 
to a really dynamic work i remember on the very beggining of the 
project a new version of rebgui was available every 2 weeks.

REbGUI is working on top of VID not remplacing it and remplacing 
VID is yet another step of difficulties. As I said befor the only 
way to remplace VID would be to make a DLL and then a bridge to make 
the "user code" able to use it and that means a more complexe way 
to share your sofware

yeah but hum with VID2 If you wanted something hum looking a little 
bit pro (before rebGUI) you was obligated to build your own widgets 
or customize the existing ones ...

well with vID2 we done a MDP Makedoc  renderer so doing HTML  one 
is not so hard with actual VID but the fact is MD GUI  and MDP GUI 
 gots a big lack of widgets for the none document rendering part 
wich I will call the IHM (menu bars, tab-panels, ability to resize 
easyly the whole content  or part of it   and that what lead us to 
do rebGUI ... to enhance that aspect.)

but that take us back to the main ask do we want a rebolvm that we 
can extend and make code over or do we want a monolitic VM  where 
you can't do any extend.  I like VID becaus it was enough flexible 
to allow rebGUI  and other VID based library to be done.

but the IDE is an IDE in rebol to do rebol software.... But why an 
IDE  in rebol ??? Well for a  lot of reason 1) promotion purpose 
.... Rebol don't need anything else than rebol to do his dev tools 
... and if we can do dev tools as sharp as you can see it with rebol 
that means rebol can do alot for your company too. 2) cause rebol 
 is what we are doing here  ^^... Other language are other languages 
More rebol to save the people  ^^.... 3) because who knows better 
what we need and what we want than us  maybe the strongest and the 
first to believe in rebol  4) because IDE in rebol can make us share 
the code and work together on a base project where anyone will apport 
his ideas tries and that's what is a community all about doing there 
own project on their sides sharing informations and experiencies 
and gathering around hudge project or mendatory projects  ( like 
rebgui  ^^)

hum but it's fast on my computer and that's a pre-alpha double dash 
++ X 2008 version  (that's way there is the probes) If I go enough 
far in the process obviously I will do a clean share. That's just 
to show  wich direction it takes and puts some animation here while 
we are pending for news from R3 ^^. I plan even to declinate it to 
wrok with rebGUI and do a synntaxe colored widget wich could be used 
for an IDE for example

btw: what do you mean by "each source file" - is the code now organised 
more in the RebGUI way? E.g. each "widget" being one file?

Many ppl suggested to accept e.g. SVN Trac, as RebGUI is using. But 
DevBase otoh gave us another good VID expert - Brian :-) He was also 
doing some fixes, which will be part of Core 2.7. Sometimes it is 
good to use your own tools. That is also why Carl is putting so much 
energy to new VID - trying to do some real stuff using VID.

Well, Rebgui has set the current working benchmark

yes, except the system friendly behaviour (accelerators, ocusing 
system, ctrl tab for switching tabs, etc.). Other than that, RebGUI 
is nicely feature complete.

simply put, button and even panel rounding, even if rather small, 
does not look good, when you place stuff one to each other. E.g. 
with buttons tied close together. While I like button as is, I don't 
like rounded panel at all. Once again it is my preference. IIRC RebGUI 
has it as a preference and all styles adjust. First thing I do is, 
that I go for strict boxy desing, no rounding ....

I found that when I tried to stick a few buttons together in rebgui, 
I always saw the rounded edges of one of the buttons

Why don't we just use Tortoise SVN? Some ppl know it from RebGUI 
project. Is SVN any less functional?

Simply put - when you look into RebGUI widget directory, you can 
see all widgets, which imediatelly make sense for user - when you 
compare it with the list provided, the difference is very obvious 
- every one single self-descriptory, usable, vs. chaos ...

My project still have everything they need in REBOL2. SQLLite, REBGUI 
and REBOL Itself.
When things will be mature I'll start to port my projects to R3.

First, I think JS is not something we should look at for models. 
It's new enought that it is just going to reinvent what's been done 
before, unless they come up with something truly revolutionary, and 
my gut feeling says that's not going to happen. It also depends on 
what kind of apps you're writing, and what you want the language 
to hide from you.


What's been done before that works, or not?  MVC has seen a resurgence 
with RoR and other frameworks being built on it. 


Now look at a low level approach, where you handle the main event 
loop yourself. Anyone remember writing C programs for Windows early 
on? Maybe some still do. You had a huge switch statement to dispatch. 
On the downside, that was hideous to read and maintain. A benefit, 
though, was that you could hook into it very easily, because it wasn't 
spread throughout the app.

Then there's the whole VB/event-driven model.


R2+VID is wonderful for very simple things, because you don't have 
much to do, actions are right there with their faces, etc. It starts 
getting in the way when you build larger apps that need to track 
relationships between faces and such. And it is not well-suited to 
large apps, just like REBOL itself. It doesn't provide the organization, 
tools, and features needed. Of course, we can build all that ourselves, 
if we have the inclination. RebGUI is the best example of that.

At present I allow users to write a custom screen in RebGUI that 
loads into a tab.  Of course they can write as much REBOL code there 
as they want.  But it would be safer if they just wrote presentation 
layer stuff .. and let my program allow the appropriate functionality.

is the same for rebgui............il would like to see a R3

a R3 demo that do all rebgui do

R3 will not be very compatible with R2. You will almost always need 
some kind of porting process, so this is up to the authors of rebdb 
and rebgui, if they want to do that.

I attracted Bobik to R3 once again. He was waiting, and waiting, 
and then he went into pissed off mode. So I told him to concentrate 
upon R2 (he is now using RebGUI) and Python, and just take R3 as 
- "might be" a good thing in the future. We now have good chat about 
the progress, and there IS a progress, although it might seem to 
be slower than we might wish for ...

Gabriele - I am not sure it is about stuff being open sourced. Even 
open-sourced development needs some organisation. Carl is organising 
few ppl around him, who are willing to work on some things. Protocols 
are open-sourced, RebGUI is open sourced, yet such stuff waits for 
real gurus to work on them - both to improve and to fix them.

Pekr r3 doesn't exist ... I know i'm a stubborn moron  ^^ that's 
my way to be 1st it's on R2 complete and full wrokking then i will 
adapt it to rebGUI then i will do REBOL IDE then in that time R3 
will be official released and i will do the port