World: r3wp

Anything releasable for us to try?

not yet, but I know Bolek and Cyphre are working hard in the background 
to complete the resizing system.

I t hink within the next 1-2 weeks a major milestone will be reached. 
host-kit with fully externalized graphics, resizing system mostly 
working and a couple of styles using it available.

An internal milestone?  Or an alpha release?

IMO this can be a next host-kit release.

i'm lost  i haven't being following here closely but why VID is externalised 
? well it always was and optional thing ... the main thing being 
rebol/core... so this tendency is made more clear. Will this allow 
 people to access the graphical side extension and modifies it independently 
of  rebol/core (the host ?). Are they other side package planned 
?

is it possible to know who work on what in the GUI topic and have 
a slight idea of the steps done and the steps to be done ....

sure:


Robert - DB interface, messaging, state machine, cracking the whip
Cyphre - Resizing, low level AGG, rich text, host kit interface

Me - Dialogs, form validation, database interface, reactors, messaging, 
state machine help system
Bolek - Styles, resizing
Ladislav - Resizing, state machine


The above is basically what needs to be done for the first customer 
app.

hum ..; can i crack the wip too ? it seems fun !!!

ok so then does ritch text is a really something to be set as default 
inside the VID extension or isn't it wiser to let that as a side 
project to make research about the perfect way it could be done... 
and we let in draw a set of basic commands related to draw (a revamped 
set ofcourse) for instance I think that a ritch text engine is too 
much for the syntaxe colored editor we made ... it's like taking 
a nuke bomb to kill a single little fly .... but such an engine by 
default can anyway open new perspectives. but what annoys me in the 
process is to do this  raw script -> conversion to ritch text dialect 
-> conversion to draw by the rich text engine ...  instead of doing 
this raw script text from file.r -> conversion to draw using parse. 
But maybe i'm wrong ... anyway one way or another i will do a port 
of area-tc. and i assume that if the rich text engine seems too much 
for me then i could still do my proper engine relying on the draw 
for text lower level instructions.... (not to mention i like the 
idea of learning parse through  experiements)

and if the rich text engine doesn't handle clickable link display 
how can we add that to the rendering engine ? for example during 
a moment Steeve planed to add to area-tc the hability to render url 
in the rebol header block in a special way  in order to have them 
click and open the navigator with tthe url you clicked over. in an 
open engine like area-tc adding this isn't difficult  but adding 
this to a black box called rich text rendering engine seems to me 
to be harder... but i'm certainly wrong ...

with rich text come a lot of  troubles like handling paragraphs resizing 
things etc... how and where images are inserted withing the text 
paragraphs etc ... Can at some point the image inserted within text 
can be a draw set instruction rendering (for graphics or SVG image 
rendering ) etc... how will that engine grow ?

if it's just a cheap intent to mimic rich text that will make people 
laugh but if it's a  main concern and a constant work then it can 
become something really awsome.

I don't think it will be a black box.. richtext will be part of host 
kit, I think. And tight integration of text rendering with richtext 
engine is good imho.

Henrik .. that's a big job everyone has.

shadwolf, I suggest waiting with further comments until a release 
is made, so there is an actual base for commenting on.

Graham:


First prototype ready for review: DB interface, resizing, form validation

Coding: State machine, styles, messaging, reactors, dialogs, low 
level AGG, host kit interface
Pending: Help system

What does this mean?

Something to test now?

no, not until these parts are done.

i'm not commenting what will be  done ofcourse i didn't see it.


But i already looked at the richtext engine carl proposed 2 years 
ago and that's far to be good.... 

In fact richtext engine is supposed to be dialect layer on top of 
draw. 

That dialect layer is adapted normally to handle text rendering the 
proper way which implies that the lower level text functionnalities 

in draw for text related effects is better done than previously. 
That's all i say ...


Building a layer richtext what ever it is if the AGG /draw dialect 
exploit poorly the text related effects that will be a pain and a 
very small benefit...

This won't happen.

and more complexity you will add to your engine more unexpected problems 
you will face...


 Like what we experienced in area-tc... suddently our perffectly working 
 engine under wnidows XP shows strong bugs in rendering just by arriving 
 on windows7. After 6 month in searching the why  and not finding 
 any cause to that rendering jam I by chance tryed the ultimate thing 
 no programer does i retro versionned back like 10  version below 
 the rendering engine and there suddently i found that rendering problems 
 disapeared by miracle...


I spend 10 times more time searching why the rendering was defective 
on windows 7 than doing area-tc and viva-rebol.r.  And that's too 
what  completly killed my mood. What else can i do than try to make 
this community know my experience with extensive text processing 
in draw with R2 to not have the same conceptual lacks repeated in 
R3.


And clearly  in R2 the text commands in AGG/draw were not suited 
for docuement rendering... That  doesn't means AGG can't do it ... 
that means at that time the dialect draw wasn't designed to exploit 
 intensivly text rendering. I always said before runnning you have 
to learn to crawl, then to stand up, then to walk. for me the way 
i  saw the realisation of a rendering engine text oriented for draw 
dialect was first step changing the color of  choosen elements in 
the text, then changing the font spécificity anytime anywhere in 
the document then being able to do strong text manipulations like 
moving by drag and drop paragraphs, inserting multimedia content 
in the document, scaling paragraphs etc... 

ROBERT: 

In fact that depends what  the rich text engine aims ... for example 
read only rendering is pretty different of  real time editing wisiwyg 
engine... The complexity betwin both approach is like 1 to 100...

Robert I know that you aim to get a WisiWyg editor for makedoc Pro 
format (wich in a time i tryed to provide in a totally deferent rendering 
technology)

therefore as you have the wip in the hand robert i think richtext 
dialect will go the way of a realtime wisiwyg  system able to be 
applyed over all the wigets we want... (like draw basically)

Not being an expect but IIRC R2 text rendering is not done using 
AGG. From this alone a lot of known problems might be coming.

In R3 text rendering will be through AGG. We will look into unicode 
as well right from the start.

I just hat a short chat with Cyphre about this. And on Windows & 
Linux the glyph outlines are used to render the fonts.

So, this uses OS native font infrastructure.

nice  :) beacasue R2 font system was a pain ... knowing what works 
where was difficult...

I experienced it when porting area-tc to linux ... the rendering 
was ok but as the font wasn't fixed size the editing part was messed 
up.

but once again R2  AGG/draw text  wasn't desinged to handle this 
... we used fixed fonts because we had no other why to obtain the 
x and y size of each displayed glyph so in other word that a lack 
of a basic lower level function.

We are aware of most of the text rendering issues and IMO it makes 
sense that we try to get a release out of the door ASAP so you can 
all take a look and give feedback.

and ofcourse fied fonts where properly handle only on widows ... 
 fun thing was i tryed rendering using the same TTF file on linux 
but it was managed as unfixed font on linux ...

so see assuming fixed fonts is a global concept is a wrong thing 
it better to say ok font will be not fixed lets handle this properly 
and offer a way to manage them the easier way...

we needed to know the size of the letters displayed on screen because 
first of all in R2 when you call 2 times a text instruction the rendering 
at piled up at same place and not disposed one after another on the 
X axis with natural spacing... so draw [ text 10X10 "a" text "b"] 
renders a "b" over the "A" and not "A" followed by "B". And it's 
logical ... text instruct was then designed to handle a serie a letter 
or several series of letter organised in distinct block we can call 
words... but you see that concept doesn't fit with the need of having 
an interaction anytime with any letter componing the words.

and in the richtext proposition of Carl made 2 years ago (times flyes..) 
we find again this block concept wich is related to the way MakeDoc 
format handle things ...  like in HTML  for example you have flags 
that defines a rendering style. But the things betwin the flags can't 
evolve... they are not supposed to change font style or font size 
or font color. See that's what i would call a we treat text as block 
and not as single element able to singularly evolve on their own 
without affecting the surrounding elements.

ofcourse you still can say a <H1> </H1> instead of the basic regular 
seting will take this font this color this size but that will affect 
all it's content and not only a part of it ...

and then if you want to have an atomical approach then MakeDoc dialect 
becomes too verbous to be efficient... like in HTML more you want 
stylised things more you pile up flags and more you have problems 
debuging and having a direct acces to your raw document content... 
So it's clear that a real design have to be set for this richtext 
even if in the end rendering html or MAkeDoc or makeDocPro  with 
that dialect means a conversion stage.

that's why the proposition of carl to have an open flag system was 
cool ... he presented it years ago as a variable inside draw dialect 
to hold styles ... And i think people didn't see the good points 
in this approach ...

Any reference to this concept?

The idea is that we will have the low-level font rendering stuff 
accessible. Further a standard richt-text dialect will exist. If 
htis doesn't fit, you can change it and use any other concept to 
make richt-text available in apps.

The low-level part won't change.

http://rebol.hmkdesign.dk/files/r3/gui/229.png

Text now works in hostkit.

ugly as always though

But I know, not the time for such arguing

correct

And be sure I appreciate your efforts to terminate the job.

Great news Henrik. Thanks for posting.

Cool. But those fonts still look kind of terrible :-)