World: r3wp

hash! being redisigned and enhanced how could i get that as a lame 
thing that great I don't know personally if it will benefits me  
but it's cool to have this for the one needing it

The "more 3365" error in chat is because we are not under the correct 
topic, when trying to get that file. I will try to figure out how 
to fix that.

for example for the area-tc (which renders full live colored text) 
during long time I expected to organise the date to parse or the 
line as hash! to be able to locate them faster  (since my data structure 
was pos char color making hash getting the position as indice was 
a good idea (well a much better idea was proposed by steeve simpler 
but all mighty efficient)

but in R2 hash! keys can't be indice and all is key so i never get 
to get a hash table based system

for area-tc project

shadwolf - then it is time to start to move your project to r3, no? 
I think that View kernel itself might be in slightly better shape 
than in R2 (but maybe I am wrong - I noticed some font ugly display 
problems)

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

since work is in progess and unstable it's hard to get serriously 
depending on it...

that's not that i don't like R3 or the new VID etc ... but what guaranty 
i have the actual R3/VID won't get the same destiny VID 3.4 got ?

pekr font ugly problem have been solved in a way and if font ugly 
issues are not of my consern you want to blame someone blame CArl 
since the time we say him that there is still bug in R2 and he doesn't 
 want to fix them ... in that matter you can see R3 as a way for 
carl to escape the pain of fixing  R2 countless bugs

font-fixed seems to not exists on MacOS X ... and since the whole 
positioning system is base on fixed-font that means no area-tc for 
mac OSX

You should be able to find a fixed-width font on Mac somewhere and 
specify that using  font/name: "your-fixed-font"

the actual situation is a pain R2 doesn't evolve and R3 is not stable 
and evolve so much that it's hard to base any serious developement 
on it yet .Where is the point if you have to restart your project 
from scratch every weeks because all changed

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

as for rich-text - you don't have to use VID at all, just gobs. Besides 
that, VID 3.4 (Carl's VID, Gab's was VID 3.3) is the official one, 
and although we expect some further additions/changes, basic principles 
are in there and they will not imo change much ...

PEkr hum gtk+  lol

no i'm kidding around ...

Don't understand gtk+ joke .... (probably because I know little about 
gtk itself :-)

but having a VID 3.4 means we got a VID 3.0  a VID 3.2 a VID 3.3 
and those free where abandonned how can i be sure in the 6 month 
to come carl won't change again his mind

and since text editing is related to UTF-8  better to get all the 
things ended to not have to constantly have to redo part of the job

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 :-)

Pekr > you said we need to find a better way to handle fonts in AGG 
cause part of it was pattented (or OSE related) and i sugested GTK+ 
 with is os independent and GPL 2.0 (pango is a heavy but really 
complete way to handly richt text rendering )

btw - once we have plug-ins/dll back (integration methods being stronger 
hopefully), I wonder if anything prevents us from not using View 
at all, and linking Core to stuff like SDL, Qt?

but gtk+ is 10 time the  size of a rebol VM ...

:-)

maybe doing a server/client style project ... but even then we need 
 people to maintain that solution to fit the gtk+ cahnges through 
the time

but the thing is i really like VID

for me VID from far the best  graphical library ever made

even if it lack functionnality even if it's a raw ...  when you find 
a raw diamond you don't throw it away just because it's not polished

I agree. So - let's wait for VID 3.4 to be finished to certain state. 
We still miss on some concepts there ..

the day Carl say R3 is stable get it I spend the 100% time I have 
to port area-tc that's a fact

Again.. when talking about fonts.. I want bitmaped font support. 
For example I create font's for my Flash apps in Rebol using simple 
image where I draw pixel precise glyphs:
http://box.lebeda.ws/~hmm/fonts/fixedsys.png
And provide the needed informations in Rebol format:

http://box.lebeda.ws/~hmm/fonts/fixedsys.png.txt(using UCS2 to map 
the glyphs)
Then I use my vectorizer to get the Flash font format.

The last step could be skiped in Rebol. And just the bitmaps could 
be used. So as in my Flash apps I can be sure, that the font will 
looks like I really want it!

But first we must have the R3 core stable and opened host sources. 
I will wait:)

but using font bitmap doesn't that will be slower than normal font 
/ text anti-aliased ?

I think it could be faster if you bypass the fon't engine. At least 
I suppose that font engines are using bitmap caches to speed up the 
rendering anyway. But of course it should be used to render in the 
size for which the font is created.

the means you need to create a font for each use that's a pain no 
?

How often do you change font in your text editor?

never

because to make it easier to handle the tete live motion we decided 
to fixe the size once for all

since that's do the makes the rest of the work more easy to grow

tete = text

and that's mainly because of a lack of a suitable fast way to determine 
size of a bunch of text (we can use a face dummi and sizetet to calculate 
but that not fast

Shadwolf, R3 have rich text dialect built in so it should be much 
easier to write RichTextEdit widget.

hum having the dialect doesn't' means you have teh proper low level 
set of drawing function to handle properly the text rendering

well i imagine that since the TDM (Text  Dialect Markup ) exists 
than AGG will follow and offer brand new things to handle conveniently 
the texte (and please please forget once for all about teh caret 
system please i beg you T___T)

what is in my opinion import in text handeling is to be able to get 
heigh and width taken be each letter or each set of letter (can be 
a word or a line ...

for example actually we are able to handle properly the text motion 
because we use fie font with a fixed size but this because what we 
want is to handle text in color and not mixe differnt kind of font 
styles and size like it would be the case for a MakeDoc format richtext 
rendering /editing widget

sure in our area-tc taht would be a plus to be able to handle ctrl+wheel 
action to grow shrink the text size (like you can do in any modern 
web browser for example) or to be able to set through a config panel 
the font size and type of your choice

Solved the other bug by commenting out one line of code. :-)

do http://rebol.hmkdesign.dk/files/chat.r

If I can get a couple of confirmations that the bugs are gone, I'll 
submit them to curecode.