World: r3wp

we would have a draw/text call for with precise sizing for each and 
every char  making the draw block cliped to our area-tc/effect/draw 
a gigantic size

hello word imagine it as text 0x0 "H" text 0x10 "e" text 0x15 "l" 
text 0x17 "l" text  0x19 "o" and each time you have to retreive the 
precise size (an hash table could be done with char => real_pix_size) 
but then you need anyway a good way to retrieve that size in formation 
being sure it's not a wrong information and size-text  doesn't works 
well on char from unfixed fonts

and we are not even speaking of unicode OMG lol

man when i will have to deal with the sizing of chars in chinese/unicode 
my head is going to blow

Indeed VID3.4 is far from done. You can probably use it for a few 
things, like getting a name from a user in a text field or submit 
a very simple form, but not much more than that. To reiterate the 
state of the UI:

- No unicode yet in graphics (when Cyphre gets around to it).
- Resizing acts like a drunken sailor. (Carl)
- Skin is not published. (Me)
- Style tagging is not implemented. (Carl)
- Reasonable requesters are not yet implemented. (Carl or me)
- Layers are not yet implemented. (Carl)
- Guides are not yet implemented. (Carl)

- Better font rendering. We are not taking advantage of what AGG 
can do. (Cyphre again)
- Event system is from Gabriele's VID3. (Carl)
- Many features are untested, like drag&drop. (Me, I guess)
- Proper material management for skin. (Me).
- Many styles are not implemented, especially lists (Me).
- More elaborate animation engine (Carl or Me).
- Form dialect (Carl talked about this).
- More/better icon artwork (Me).


Plus, Maxim has some ideas for DRAW, to greatly speed up rendering, 
but I don't know if they can be implemented.


The overall design of the GUI engine is very good. Whenever a change 
or addition is made, you alter 3-5 lines of code in one place, and 
it works. I doubt the entire engine will be rewritten.


You won't see GUI bug reports in Curecode for a while. There could 
easily be 2-300 reports, once we get to that point.


My work regarding skins is rather big: I need to work out the basic 
styles first, so we have a reasonable way to build compound styles. 
These are being done using a very simple, but pixel accurate GUI 
using plain colored surfaces. This is easier for testing out, as 
draw blocks are small, but as Pekr likes to complain: They are not 
pretty to look at. Once the real skin goes into place, the draw blocks 
will grow a lot.


I would love to see a low-level GOB management dialect, like Gabriele's 
MakeGOB.

Wow, seems like lot's of work, but maybe not. The nice thing is, 
that sometimes few lines of code might make big difference in the 
end ....

I would like Cyphre to devote 5-10 days to core engine. E.g. transparent 
windows (not absolutly necessary for initial release, just an example) 
is just question of setting particular bit for API call, at least 
under Windows. I would like to see - Unicode, better fonts, cached 
gfx (we don't use bitmap caching yet), eventually switch to AGG compound 
rasterizer, some draw suggestions being implemented - so much for 
a low level ...

Shadwolf - you are too quick on your reactions, you pretty much remind 
me of .... myself :-)

Shad: I complained a lot about unview. It has to take some parameter. 
So Unview none, Unview my-win, Unview 'all .... but - what is a big 
deal? Just type help unview in console ;-)

Shad: as for text, you forgot we have got rich-text. Dunno if usefull 
for your purposes, but I just want to remind you of that ...

http://www.rebol.net/wiki/Text
http://www.rebol.net/wiki/Rich-text

font rendering not taking advantage of AGG i'm completly agree since 
anti aliased doesn't works properly but this should be the time on 
that particular area to see the font rendering area under a new line 
of real time text processing and their is alot  of amazing things 
to be done . 

in the end my request is simple i want my users to choose their own 
font they like on any ot the main OS brands and get the same result 
everywhere (even on online editing for example imagine the rebol.org 
integrating viva-rebol thrue rebol3 webrowser plugin  to allow the 
script sumiters and owner to share editing of a script with bunch 
of select people. That's the qualité we should aim for.)

when you talk about layer that means interfaction a visual area with 
extern library rendered visual contents ?

like cliping a video or a opengl/direct 3D rendered area to a vid 
box.

Pekr can we still keep win32 15 years old kid as base for VID  on 
windows plateform on a middle term  (5 more years) won"t it be better 
to start right now to support winfx enhancement and use part of the 
hardware acceleration in rendering?

Layers are just separate layers of gobs. That's all.

i feel  like this being focused on too many targets ( OSes where 
VID exists) make you loose from your sight what are the real interrest 
in coding on one particular OS among the others ..  wanting to be 
too much generic and too few specific gives a bad image to your product 
(that's my own opinion)  if you see port of  other libraries like 
GTK+ or OPEngl  they are ported to act the same way but they include 
 to some very specific plateform related obtimisations and functionalities. 
this should then mean the guy that need a basic set of instruction 
to quick to interfaces GUI forms to a database then rebol crossplatform 
 abilities will allow him to just don't care where his program runs. 
But in some high level area  optimising is 90% of your task  and 
it's a constently evolving task . If we want to bring rebol and VID 
to the Guru level to a solution that make people considere it serriously 
and not like another freak toy for freak kids then it's  obvious 
that area have to be digged up and brought to rebol too

rich-text is read only spécific rendering  based on a specific markup 
language... since we are not talking about the same goal ( i want 
real time text edition (read and write) and the hability to create 
extend or change the rendering process to feet not only colorize 
text but any kind of tet rendering with high performances and simplicity 
of code writing. area-tc is just the first step in that process it's 
just  a proff to show that VID and most largely rebol concept can 
bring to that area. But there is still alot of work to do and that's 
normal initially VID and draw were not designed to handle such duties 
and the tricks we had to use to achieve that goal in R2 only showed 
us the limitation of the existing. So what we do do we evolve to 
chase that area or do we just try to redo again a limited R2  version)

then i think ritch text is based on an old idea replaced by a more 
powerfull one....  based on area-tc way to work redoing the richt-text 
area to bring in it the write cncept is not impossible to be done. 
and what better way for a user to use a markup language not knowing 
you use it (MS word and all other advanced tet editing tools does 
that constently. from RTF to PDF)

and wysiwyg interfaces are the best ones for regular users

you have your wysiwyg tool you write your documentation you push 
a button to generate the documents and store it then you do a view 
[ doc load %./data/doc.mdp ] and that's all

you gained alot of time you absolutly don't care what is MDP liking 
like all you see is the document you created is rendered the properway 
exactly as you created it in your creation tool.

rich text is the internal specification, all your tool has to do 
is create the rich text block based on your desired looks.  rich 
text isn't meant as an output or an exported format.

yes but that's still read only

that's thinked to render help documentation in your own GUI  software 
that's not thinked as a document writing tool. you have to use an 
external way to easyly create large formated documentation without 
having to keep in mind the over all markup language

Shadwolf, no, rich text in R3 is also writable. there was a bug a 
while ago that would let you unintentionally edit parts of the DOC 
style. We are just missing parts for logical control of the cursoe 
between different styles in the text and text selection across styles.

that's true of any layout engine.  if you look at pdf.. it actually 
doesnt include any text layout algorythms.. those must be built externally. 
 all pdf does is display vectors where you tell it to.

When I showed it to Carl, he was surprised it worked. :-)

maxim i already long time ago worked in the Markup document creation 
tools with ashley MDP-GUI  and one of the limitation was that you 
could not create the markup data and the at same time see the rendered 
result at same time you had to use 2 separated boxes one for rendering 
the other for "scripting the document"

R2 doesn't have any rich text you can direct.  which means you have 
to do all of the layout work manually.  as long as we have sizing 
examination of rich text atoms, then we can tell it to position things 
like we want and measure the result in order to properly convert 
the data to other formats.

yeah but anyway markup had another conversion stack wich would be 
better to be done directly to draw dialect. and i'm not sure the 
markup language doesn't imposible limitations that will not allow 
you to go out of the box.

i read the scrip it speak to draw directly hading the conversionn 
to markup layer since it's not thought for that purpose will had 
a delay to the engine. I really need to speak directly to draw. that's 
all

you must realize that the format  of a document (encoding of the 
layout) isn't directly  tied to its content.

basically the rich text dialect looks alot like what you are doing 
manually... all its missing is better analysis of its rendering results, 
IMHO.

it will be much faster, since much of the heavy lifting is done in 
binary rather than interpreted code.

as long as you can detect what word is under the cursor at a given 
 coordinate using specified scrolling, you could use the rich text 
directly.  and then output to whatever format you want... as long 
as you can predermine how all the coordinates map in both systems. 
 This last part is what just about every importing/exporting out 
there tries to get just right... but in the end, its never exact 
because coordinate systems are different, font rendering engines 
don't use the exact same algorythms, etc, etc, etc.

in R3, all text is rich text, but you don't notice that, since it's 
only really taken advantage of in a few styles.

cool.

something that was sorely missing in R2 , and isn't readily available 
in all GUI systems. :-)

maxim that's like if i was asking you to do 3D secenes in XML format 
because hey man i have thet vid xml-opengl rendering black box that 
will do the work for you but hey you don't have any control upon 
the rendering engine

MD doesnt include images or complexe paragraph formating ... that's 
just a toy

no its like saying I must convert any kind of 3D geometry to any 
rendering engine out there.  Same if we want to export them... a 
model from maya has to be converted to another format if you want 
to use renderman.  all of the scene management is independent of 
the 3D atoms being used.

the rich text has all of the format and explicit position info... 
if you want to slide text in order to add an image inline... just 
do so.  ;-)

as I said, we need to know the offsets... if you really want to use 
another layout engine, just wait for extensions to support image! 
and go crazy  :-)

hum but  in general you do your best to select the best 3D file format 
 to go with your custom made 3D engine to get the best rendering 
real time speed and that best quality compromise.

and that's exactly what an imposed Markup dialect forbids to you 
point.

more low level instruction to make y world easyer why not ? ...  
being tied by the neck and forbid from freedom no way !

maxim with an imposed close format and an imposed close black box 
called "doc"  what you gain in a hand you lost it on the other hand 
cause you still have to convert your raw data into the specifiq imposed 
markup language and if that markup language have limitations then 
you have find again new tricks to do what wasn't planned to be done... 
 that's not like choosing your own format and then your own rendering 
line. That's why i said in my example we impose to you the use oof 
XML  sheets to represent your 3D data (which is obviously far to 
be the most performant and the most suited to that use) and you are 
stuck to what the black box is able to do no way for you to directly 
have an impact on the rendering line.

but there is no link between make doc and rich text.

The rich text dialect is a data structure, not a markup language.

It seems insert (and maybe even change, remove) are already implemented 
for parse? At list this is how I read between the lines of Carl's 
blog reply in Either related blog ...