World: r3wp

actually VID is pretty unstable in R3 ... it's not hard to make the 
VM gets a hardcrash ...

The overall design is good, but it needs some changes and debugging 
:(

I mean the design of the gob system and infrastructure, not the dialect.

hum is there an anamonitor for R3 ?

hum i can't tell you what a gob looks like i don't know how to access 
them

system/view ?

No anamonitor for R3 yet. system/view will be going away when the 
VID is modularized.

vid will not be a default thing anymore ?

The plan is now to do a /Core and /View, with /Core coming out first.

anyway VID in R3  couldn't handle properly an anamonitor like script 
so ...

Even when /View comes out, VID will be in one or more modules.

brianh  i know htat what i read on the blog too but i though vid 
would be integrated by default in the VM ... a module is like it's 
external and you don't have it by default

to make it native like ?

There are internal modules, and some of them will wrap natives.

what will be concretly the interrest of having VID as module ? will 
it allow the community to enhance Vid without ringing carl's bell 
around every time ?

Yes.

Plus, modules are useful for organization. Work on VID had to stop 
because the process of organizing it failed, needing modules.

i'm currious to see that ...

Too much code, too much to keep track of. So, Carl took a break to 
start the module system and I finished it.

ok

i want a way to handle fonts the proper way on all os's and with 
draw . i want a given font to be able to speak with me or the VM 
and draw/text to auto adapt the rendering to it. (if i have to simulate 
a fake cursor i will need to know what is the real pixel size of 
each of the chars in my line;;;)

and i want so the fonts given to be rendered the same way on any 
os

That would be nice :)

i don't care having rebol on iphone i want it to wark the same way 
in linux, win7 and macOsX that would be just enough

my idea is to offer the user an easy GUI font selector  in viva-rebol 
and having the any fonts he use not disrupts the renderng  i noticed 
really strange effect with fonts on other Os's than winXP things 
rendered  like this :

winXP:
toto: func [ 

on windows 7 was producing 
toto	:	f	u	n	c [

things like that

it would be nice to thing the font system in a modern way ... I'm 
not sure how i can explain that ;;;

seems like a R2 version for Windows 7 might be necessary? is that 
what you mean?

maybe using freetype 2 embeded like gtk+2  does in pango could be 
an help in that behavior

I have Windows 7 running locally, so the next version of R2 will 
run on 7.

maxim exactly and even the linux rebol VM renderise same font from 
same font file in a different way  and the fixed font caracter is 
not kept at all all fonts become unfied like magic and some time 
along the document produce wrong spacing information

as brianH noted yesterday using freetype has some licensing issues 
which might not provide the best looking fonts when compared to OS 
rendered fonts.  but maybe AGG could render the fonts with coordinates 
given by freetype.

Don't know yet whether the current version does though.

yeah that's what is frustrating i can only say this works in those 
case it doesn't in that case

i'm sure  inwindows 7 the fixed fonts that turns to unfixedfont by 
magic is due to some unsuported instruction from win32 API emulator 
in winFX

cause rebol actually doesn't speaks the native vista/seven windowing 
API language it speaks the deprecated win32 API ...

there was no problem in vista that I remember.

strangge cause the lucidana consol fixed font just doesn't works 
on seven

Lucida Console?

yes

i tested even forcing rebol to use the tff file from windows XP  
and that produced the same sizing bug 

all the text motion turns around the idea you don't have much to 
care about each char size in pixel since it's always the same you 
do a size-text call on "MM" only when you change the font size (growing 
the text shrinking it) and that's all if we had to care about the 
rendering of each elements in the texts that woud be a real pain

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