AltME groups: search

On distros where it is not working, we are waiting on Cyphre to fix 
this.

[Cyphre example]..other applications dont work because of the font 
path issue ..indeed ;-)

Ok, very good. :)

I thought I might try to analyse the Cyphre's tree + Anton's scroll-panel 
problem you spoke of before.
Did you just happen to make a minimal demo showing the problem ?

added fps counter to the file. No difference for rotated display 
on my notebook, the same report received from Cyphre. So - it has 
to be some bad driver on the testing PC. Case closed (hopefully), 
thanks for assistance ...

Systray? Systray was done by Cyphre for me on contract, and released 
for free. IIRC Cheyenne used it at some point ...

Its also possible that Anton, Gabriele or Cyphre have found a trick. 
 I'd be interesed to know in any case, cause this could be a problem 
for me in the future too.

Is Cyphre's gui console source around anywhere?

start a desktop, go to Sites/Cyphre ... there is vconsole script 
...

just workarounds too ... before Cyphre fixes/extends Draw ... but 
I doubt any native changes are going to be backported to R2.

Try contact Cyphre ... or I will ask him ...

Doc - Cyphre confirmed bilinear filter is missing in R2 draw. It 
could be added, if we wish so for R2 updates. In R3, there is new 
parameter for such purposes, called RESAMPLE

Cyphre: great, so we will get downscaling bilinear+lanczos filters 
in 2.7.8 next month? :-)

Doc - nconvert is an exe, but xnview package has complete API to 
wrap. We even did some basic stuff in the past with Cyphre ...

I don't want to give up dynamic GUIs, and I think we have a perception 
that everything should be as easy as VID, or at least not too much 
harder. We are missing some key ingredients, which makes things much 
harder, but if you ever tried to develop a custom Windows control 
in the early 90s, you might not say REBOL makes it too hard. Then 
again, you might. :-) Entire companies were built around, and devoted 
to, providing small sets of custom controls, sometimes just one. 
TrueGrid comes to mind.


Great things have been done, even without docs or all the right pieces 
to make it work well. If R3 can provide the necessary hooks, events, 
and docs, I think we can do the rest. Honestly, at this point, I 
would be happy to have RT *just* provide the core pieces. If Henrik, 
Gab, Ashley, Cyphre, and a few others can agree on what to tell Carl 
they need, all Carl has to do is be willing to give their work an 
official blessing.

Not sure low level code changed in that regard ... I will try to 
ask Cyphre. We imo definitely need to add support for combinations 
like ctrl + tab, etc.

Cyphre - and as for R3? btw - what does it have to do with the system 
port? Are all keyboard events captured via a system port, or just 
only special keys?

cyphre, here is a script which crashes. 


http://www.pointillistic.com/open-REBOL/moa/files/draw-clip-crash.r

Cyphre, I didn't get the 'down event at all, which is what confused 
me.

Cyphre, it's possible there is some recursion problem.

Cyphre, ok nice to know.

I thought I remembered some pretty fast animations (with effects) 
done by cyphre some years ago - he bypassed view effects for those?

Nice work.. it would be even more interesting if Cyphre's JIT could 
be used to speed up some of your functions one day.

Max - interesting achievements. Do you really think, that the draw 
dialect interpretation is the culprit and performance killer? IIRC 
Cyphre said, that time to interpret the draw block dialect is really 
negligible ...

I've looked (briefly) in the A104 R3 host C code and it doesn't seem 
like it by what I understood of the extensions I found.  cyphre might 
illuminate me if I just missed it.

Max - so far, all AGG functions are mapped just like commands, nothing 
more. Cyphre is working on a dialect right now, but it is not in-there. 
Each dialect keyword then maps to such a function - or how do you 
think the REBOL to AGG mapping is done?

We should ask Cyphre then .... I think that you might discuss all 
your concerns with him, maybe together you will find out something 
generally usefull :-)

I'm not sure if it's easy to fix. Cyphre would know whether it's 
possible.

In general, using chroma keying is it possible to vary the level 
of transparency?


I've been playing with cyphre's "Transparency window under View" 
script  and I do not seem to be able to change transparency levels 
when using chroma keys.


I know this script is using window's user32.dll and it's not using 
draw to do the effect.

I wanted to create a near transparent window onto another windows 
app so I could draw/sketch over it like they do on tv during a football 
game.


playing with Cyphre's script the transparency works on the whole 
window including title bars and borders.
 

Perhaps I could use a chrome key to get full transparency on the 
area I want to see throught to and lay over that a draw based semi-transparent 
object to draw on....I'll do some experimenting.


Else I will need to make the whole project Rebol and not use this 
"cheat"

I was playing with Cyphre's "Transparency window under View" script 
trying to get a transparent overlay that I could use to draw over 
other programs like they use to doodle over plays in football. I 
was able to get it to work in vista but not xp. Anyone know what 
might be going on there?

It's known bug. At least Maxim was talking about it with Cyphre in 
OSX group a few days ago.

yes, its a BUG in AGG, using more than 2 values in line pattern will 
cause the crash.  its the oldest AGG bug I know of.


spoke with cyphre, its possible that this will be fixed in next release 
of R2, which shoudn't take more than a few weeks IMHO.

I'm studying a possible font alignment bug with Cyphre:


view layout [origin 0x0 space 0x0 t1: text 100 black white "Boo" 
right t2: text 100 black 200.200.200 "Boo" right bold]


Does the last "o" line up to the same pixel for you (correct) or 
is there a slight misalignment (wrong)? State your OS, please. Thanks.

so far, the best Rebol related designs, for me - Henrik's stuff, 
Detective, Cyphre's styles pack - compact designs ....

cyphre styles - http://www.xidys.com/cyphre-styles.jpg- the design 
works, maybe because of darker background. I will try in the evening, 
to put tabs not on the dark background directly, but first in the 
group box ....

btw - I like Cyphre's fading group-box styling - http://www.xidys.com/cyphre-styles.jpg.
That fade-out should be possible with new draw even more. And maybe 
it could be used even for your field effect :-)

Simplest way is, log into XPEER and take a look at D:\rebol\link\xpeers\users\cyphre\tooltip-test

The same goes for menu. When I was testing for Cyphre (his stylepack), 
I pushed Cyphre to solve menu resolving screen position, to enable 
it to always fit the screen = menu displayed always to be visible.

Ashley - Cyphre was supposed to strip tree vidget from drop-tree 
IIRC. Dunno the status ...

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.

RebGUI2: Cyphre and I will take a look.

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 ....

Cyphre's spell checker http://www.rebol.cz/~cyphre/spell.r

the version I just sent to the ML is now almost 4 times faster than 
Cyphre's

It's more efficient for Cyphre to fix his drop-tree widget

I asked Cyphre to do so, even to upgrade Grid to follow beta 2. I 
hope we have only one system, not incompatible forks.

I wonder what does it mean "simple" tree widget :-) it will not be 
full-blown tree? Will automatic scroll bars, hilite, keyboard navigation 
as in OS? I will ask Cyphre if he was successfull in extracting tree 
widget from drop-tree ...

it is a pity Cyphre is busy. I asked him to adapt grid, and he also 
promissed to extract tree out from drop-tree. But otoh I am glad 
he works on some parts of View for R3 :-)

TimW - there is very robust grid style, done by Cyphre, under contract. 
It is just there were some API changes, so the grid was never further 
adapted ....

There is much better one, done under the contract by Cyphre. It is 
called grid. It allows you to have visible/non visible columns, row 
or cell hilighting, whatever content in a cell, vertical plus horizontal 
scroll. It's only drawback is, that first release does not contain 
column resizing.

I hope it should not be a problem to adapt. IMO Cyphre would do it 
in one day, but let him work on R3 :-)

Graham - Cyphre's styles pack contains tabs with arrows, so that 
you can have more than is visible space. Horizontal only though ... 
You could contract Cyphre to do it for RebGUI ....

Is there anything that can be done easily about implementing Cyphre's 
grid into latest Rebgui?

it was a working implementation, but then Ashley changed RebGUI and 
broke it.  At that point the funding for Cyphre had already been 
completed as he had delivered a working grid.  Not sure if anyone 
is able to take it up again and get it working with the latest RebGUI.

Robert - is it the same grid Cyphre did for me? That would be really 
good, because imo it was well and sufficiently abstracted (e.g. visible, 
non-visible columns, without the need to resort data block, etc.)

Robert, what build# did you fork on? From memory Cyphre had to make 
a lot of grid-specific changes to rebgui-edit.r

BTW Robert, please don't feel any of the work you and Cyphre have 
done is wasted or unappreciated. You created a solid fork early on 
that meets your requirements. The chart widget in particular just 
blows me away whenever I see it (you should post an image of %test-chart.r 
somewhere, it's one of the most beautiful displays I've seen). Even 
though none, or only a few, of the widgets you sent me may ever make 
it into the standard distro; they have proven invaluable as a source 
of ideas, coding techniques and motivation. Many specific things 
you did (e.g. tool-tips) have slowly but steadily migrated across.

Karim, then I think it is a bit preliminary to consider porting:


- mysql, postgress - while those schemes are built upon raw TCP R2 
stack as a schemes, someone would have to port them to async R3 networking 
kernel

- sqlite - requires mostly DLL access. There is no DLL access in 
R3 and maybe there will not be one like we know it in R2. Carl is 
not decided yet, if we go via DLL layer like in R2, or via standardised 
plug-in interface, which is not ready though, as it needs modules, 
which are not ready either

- GUI - Gabriele was working on new VID. It is now called VID 3.3 
(third prototype). It is still not complete. But - Carl is trying 
to follow slightly different obectives, so he decided to rewrite 
it and bring us VID 3.4 prototype (probably called GIDI)

- View, unless Cyphre fixes some harsh bugs in its kernel, is pretty 
much buggy and makes VID3.3 crash in few secs to minutes.

It is not possible to do any serious development or planning. VID3 
was supposed to be done in 3 - 4 weeks. Then "one month" break came 
for you to work on Qtask, which, in fact, took 6 months? Cyphre is 
fixing critical View bugs for 3 months already, with no result. And 
those are the facts. Just don't understand me wrongly - that is nothing 
about your, Cyphre's or anyone's skills, or Qtask causing it - but 
those are still the facts.

Shadwolf:


- development has to be vital. There is IMO noone contracted right 
now. Gabriele, Cyphre, simply noone. Cyphre has not fixed deep View 
bugs for some 4 months or something like that

- there is nothing complicated about cross-platform nature of R3, 
as right now, kernel is imo not under development

- according to available info, VID should be the focus now. And maybe 
it is the focus. But it is not communicated. I hate those periods 
and they do happen once in something like 2 years, last one was probably 
during the rebservices period, which were not finished btw anyway. 
So - the blogging about Vista being broken or California fires is 
good, but look at frequency of R3 blogs. If it will not change, I 
recommend to remove personal blog from REBOL.NET, as it gives overal 
impression of RT breeding wine, instead of coding. Not that I have 
anything against personal life or wine :-), but can you imagine some 
system integrator, potential investor or tech.company willing to 
use R3 in their cell phone would look at REBOL.NET blogs? It seems 
to scream for - "... but where's the development happening"? And 
once again - all is about communication imo. If VID3 is in some stage, 
one blog per week would not hurt - whatever - principle explanation, 
simple glimpse of code, a screenshot, whatever ....

there used to be a running joke in my workplace that whatever startup 
company i got excited about was doomed to failure.  Be Inc. with 
BeOS (focus shift), Constellation 3D with their Flourescent Multilayer 
Disks (FMD) (factory bombed in start of Palestinian intifada), and 
now Rebol?


Each of the technologies was/is paradigm shifting in their field 
but through mismanagement, mishaps and miscommunication something 
along the way seems to get lost and the excitement they originally 
engendered fades from the public eye. 


If, in the case of Rebol3, it simply is too much work for one person 
- then perhaps now would be the time to open such areas as View development 
(the underlying system) and advertise to the 'World' "Come, see what 
you can do!".


Personally, I'd love to see Cyphre's work with View taken that one 
step further and translated into OpenGL and all that entails.  Not 
everyone today is looking to use Rebol only on their embedded devices 
;)

well, Cyphre is trying to fix basic bugs for few months already, 
but it seems to me he is really busy, or RT is not willing to put 
him under contract, I don't know. The only thing I know is - we are 
very slow ....

I think there are two levels to it at this time (on/off), but I think 
Cyphre has said that the gamma can be adjusted. Carl also once said 
that he hates antialiased text, which is probably why the smaller 
text is non-antialiased.

Status:


- Asset management is a big question. There are design questions 
to solve with regards to loading and unloading assets to make it 
easy to switch skins. Carl has mentioned the three skinning layers 
in his blog post.

- I proposed a method to specify lists of materials in a very simple 
way like FONTIZE and Carl liked it, but it's not yet implemented. 
This is inspired by what 3D modeler software does to manage materials, 
rather than what other GUI engines do. It's much more formal.

- I proposed a method to generate materials for gradients in styles 
in a very simple way. Carl liked it. This is halfway implemented.

- There's a function to generate a gradient from a description in 
a compact way and then apply a function to it to create a real adjustable 
specular highlight. This means you don't have to work with a big 
set of tuples in a block to create a good gradient. You can see that 
in action here: http://rebol.hmkdesign.dk/files/r3/gui/026.png

- Carl is working on panels and groups. We're building small apps 
to try to reveal bugs in the layout engine.

- Panels has a bug that cause cells to overlap when resizing. This 
is not evident in my screenshots though. 

- Resizing with refresh bug has not yet been fixed and you may see 
it sneaking in, in some of my screenshots.

- Text handling (cursor movement, selecting, etc.) is still pretty 
basic. I think it's due to the event system being grabbed directly 
from VID3, as it behaves the same way. There needs to be a person 
capable of writing this code, as it can be done as an isolated project. 
Gabriele is a prime suspect here, but he's probably too busy at the 
moment. If not possible to do now, then it will have to wait a bit.

- Carl talks about getting more people working with VID3.4 this month 
to get them to write real apps to reveal bugs in the layout engine. 
Needs lots of testing.

- Text fields allow text to be painted right out to the edge of the 
area-size, which looks a little silly. Carl wants Cyphre to look 
at DRAW clipping.
- Accelerator keys - no work done yet.
- Disabled or focused items - no work done yet.

- I have skinned button, toggle, slider, text, area and progress. 
I hope to skin scroller and panel today.
- Constantly working towards simplifying styles.

http://www.rebol.net/wiki/GUI_Note_-_Shapes_in_DRAW_Blocks- I think 
that we should be aiming at graph based low level AGG based design, 
with the ability to cache various nodes. IIRC Cyphre was talking 
about something like that, but not sure it is implemented ... good 
that such low level things are explained though ...

Henrik - thanks for third video. Still uses lower frame rate? Scrolling 
still seems being rather slow. It will probably need some optimisations 
by Cyphre in low level ...

I was referring to subpanel, seems slow anyway. When you run R3 alpha 
script called button-colors.r, it is painfully slow. I asked Cyphre, 
and he told me it would need some optimisations. Those things really 
should be realtime, or we will not be able to write Office 2007 clone 
in R3 :-)

Henrik:

- what do you mean by "overlays" please?

- what do you mean by pop-ups being done in separate windows? Pop 
up dialogs were always separate windows, no? Or are you talking menus 
for e.g. too?

- hopefully Cyphre gets contracted to do some fixes/enhancements. 
Do you think, that once it happens, community could dig most important 
bugs in draw layer, and ask for fixes?

Cyphre's in now, so we'll see.

Probably the first, since it's about Cyphre having time to do them.

I think Cyphre already has demonstrated editable rich text back in 
2005, before Carl began working on R3.

Cyphre's editable what? If we want to call that a rich-text attempt, 
we are really doomed. It was not really usable for real work.

But as Cyphre stated - 1) maybe we could get special licence, as 
there was good relation of RT and Maxim 2) we are far from fully 
utilising even 2.4 version ...

AdrianS: talked with Cyphre xy times. AGG does not support HW acceleration 
out of the box. But Cyphre plans to add it. Either as regular release, 
or as his own commercial project. Remember - whole View is going 
to be open-sourced. After all - it is mainly an AGG code plus events. 
There is a little bit problem with HW acceleration though - that 
stuff is not 100% compatible amongst the platforms - you might not 
get 100% pixel precise rendering ...

Henrik - were there any draw fixes done? Or Cyphre still not being 
involved?

- No time table given, so I can't say when there will be a release. 
I can only say that we're moving forward all the time, fixing bugs, 
adding new styles.

- No DRAW fixes yet. I haven't seen Cyphre since 5th November. We 
can work around most DRAW bugs for now.

- Skin lacked a CONTAINER style to put things in. Lining up scrollers 
with text fields, lists, etc. proved to be problematic. When one 
looked OK, the other would look terrible. We had TIGHT, GROUP and 
PANEL, but none of those are useful as decorative containers. CONTAINER 
works llike the frame of a painting, and now all styles that use 
CONTAINER look almost identical and pixel perfect. It also allows 
me to build complex field styles, like a search field with icons 
or numeric field with arrows.

- MAX-SIZE: It's a combination of weighting and maximum size of a 
face. When you set MAX-SIZE, it will affect the layout of the face 
in code, even if you are nowhere near maximum size, something I would 
never expect such an attribute to do. Setting MAX-SIZE correctly 
is an annoying process of trial and error, can't be predicted and 
depends on the MAX-SIZE of other faces in the panel, which requires 
debugging and studying other styles or setting them manually with 
a lot of typing. There are also magic numbers, so sometimes you use 
a size of 4000 and other times 100000 to achieve similar results. 
This is really the only part of VID3.4 that I don't like. However: 
There are still bugs, so intended behavior may turn out to be much 
better than I think. I can't remember what VID3 uses, but I would 
guess it's a more traditional weighting model.

1. Some kind of error, possibly due to the wonders of MAX-SIZE.
2. Cyphre will need to handle that.

But first someone must change Cyphre's task on Qtask from coding 
JS to work on R3 at least 3 days.

Cyphre is  not working on R3. He is working on Qtask. I don't know 
what exactly.. it was a joke a little bit. It has nothing to do with 
Carl and any BBS

Yes, but Cyphre is bigger:)

Henrik - I understand your attitude and am sane enough to know, that 
I make very often stir/noise. But you are typical example of elitism, 
and I don't like it :-) While you might enjoy being close to source, 
you might not understand frustration of other devs out there. I think 
that Carl is not used to work with larger teams, makes his decisions 
himself. It is very difficult to proceed faster, unless Carl finds 
some leutenants. Pity Ladislav is not here anymore. Hopefully BrianH, 
Maarten, Gabriele, Cyphre, Dockimbel are trustworthy coders, to delegate 
some work.

R3/View might get Unicode support till the end of January. I pushed 
Cyphre to release some info, but maybe he just wanted me to give 
him a break :-)

Maxim - try asking Cyphre - he is now our low level gfx guru. He 
might know, how it is implemented. Also - with R3, entire compositing 
engine is replaced by AGG one.

C is only Carl and Cyphre. Everyone else only work with REBOL. But 
we are allowed to contribute C code if he wants something specific.

well, there's me (GUI), BrianH (smart guy), Brian Tiffin (docs), 
Cyphre (graphics), Gabriele (network/GUI), Pekr (communications), 
Maarten (network), and about 10 others who've made contributions. 
Didn't really want to mention people in case I forget important ones.

I suppose both Carl and Henrik ar working on it while Cyphre will 
be back soon to fix some lower level issues.

If the data from users R3's command are correct, Gabriele last logged 
in 31 days and Cyphre 7 days ago. Both were here today.. so it was 
not good example:)

I was just wondering, it there is someone else "who know the internals"... 
I know that Cyphre is waiting for new sources from Carl to do something. 
And of course it's good to have a place where one can write message 
to Carl and with a feeling, that Carl will read it one day.

I just visited AGG newsgroup after one year, and some interesting 
projects do emerge. Community agreed that any open work will be done 
to BSD version (2.4), which is a good sign (although RT has probably 
no problem obtaining special license).


Dunno why, but there are (apart from Cyphre) another few Czecho-Slovak 
guys, and one of them is doing rather interesting project. AsmJIT 
and BlitJIT libraries, with MIT licence. Author says about it:


Antigrain is great piece of software with great licence, 
but without 
better acceleration it's quite slow.  So blitjit can increase speed 
of 
your applications in way you can't imagine. For example is there
complete 
MMX/SSE2 extension for antigrain ? No, but don't panic, other
libraries 
also have problems with cpu specific features.


The reason why it might be interesting is, that generally there is 
no good 2D HW acceleration out there, and here is what author of 
LibNUI answered to Cyphre:


I'm the author or nui (http://libnui.net) which is a GUI toolkit 
based  
on OpenGL (and now OpenGL ES / Direct3D). This project was 
started  
some 8 or 9 years ago and I've been working on it and with 
it amlist  
daily for that time. My experience is that it's some 
orders of  
magnitude harder to have HW support for those features 
that to add a  
JIT to your engine in order to optimize your bottlenecks 
(I've done  
some of that for pro audio dsp code). The reason is 
that no two chips  
work exactly the same and behaviour even tend 
to change over driver  
releases. To diferent cards, even sometimes 
from diferent vendors,  
will not give you the exact same scan convertion 
or rasterizing, and  
I'm not even touching shaders diferences...


It seems to be x86 only so far, but maybe guys like Cyphre or BrianH 
or Anton or anyone skilled in those areas should keep an eye on those 
guys :-) Here's a link:

http://code.google.com/p/blitjit/

... as for those another AGG based Czech and Slovak projects:
http://www.rw-designer.com/
http://www.crossgl.com/

Shouldn't we get those guys hooked to REBOL? :-)

So - where do we write down our wishes for Cyphre to implement? :-)

I was thinking about CureCode for a while, as a "wish" requests, 
but not sure if we should "flood" it with such a stuff. Maybe a RebDev 
is better place, but Cyphre might not read it, because of its, well, 
"comfort" :-)

We should start to write-down our wishes for View/VID imo, maybe 
we are close when Cyphre will be called to continue his work :-)

probably something Cyphre needs to fix.

Generally we'll have to talk to Cyphre one day. His bug list is getting 
quite large.

posted question to rebdev, how far are we with March dev plan, in 
order to sync sources with Cyphre once again and let him fix few 
things.

Hmm, isn't jus alpha transparency enough? Why to do any shape detection? 
We just need the ability to define level, which will let events to 
go to underlying faces, just like Amiga DE did it. And if you look 
at Cyphre's irregular window shape, you will see, that it simply 
is not rectangular, or is it?

do http://www.rebol.cz/~cyphre/trans-gui.r

Cyphre can't do nothing yet, as Carl did some changes to the code, 
and Cyphre's version of R3/View is not compatible anymore. Of course, 
rebin isolation should help, and in month or two, we get there - 
modules are bing worked on right now, plug-ins and rebin are next 
one. Then some source-codes get released finally. In the meantime, 
Carl also updates docs - very important ...

Shadwolf - I am not blaming anyone. Font ugliness has something in 
common with font hinting. Cyphre told me, that such code in AGG is 
licensed (or patented?), and that we will have to find some other 
way around. But you would have to ask Cyphre, I don't remember exactly 
what was the reason ...

all previous VID's were Gabriele's implementations of Carl's/Cyphre's/Gabriele's 
discussions/specs. But for some reason Carl was not satisfied and 
decided to go with other design. And as it is Carl himself we are 
talking here, I would bet that the design will stay :-)

(Here you can see what can be done with the current R3 in ~5kb script. 
http://www.rebol.cz/~cyphre/stuff/r3-richtext.jpg)