World: r3wp

And I agree, the current linking is quite annoying. Here's a patch 
how I fixed it: https://gist.github.com/d1c120789a4b7acb635d

Andreas - any enhancements could go into default host-kit distro,no? 
:-)

Yes, just didn't yet get around to opening a CC issue for it.

Pekr, I bet the AGG part will be easy to compile on AmigaOS. I compiled 
AGG on quite few platforms and it went smooth. IMO More work needs 
to be done on the event loop and window management in this case.

Yep, the R3 specific interface is fairly elaborate

Considering I was the one who ported AGG to Amiga I don't think it 
will be a big issue... :-)

The tricky part will be the event handling and such which I have 
yet to figure out.

well, Amiga's event model is so clean , and actually the R3 event 
stack... well, its closer to it than the R2 was.

I got the A107 host kit working on Syllable Desktop

congrats!

Thanks. This is still using the same trick as the first port almost 
a year ago, by using the Linux binary of the R3 interpreter library

How did you test it Kaj? (I'm curious about testing these things)

It's become a bit more complicated because R3 is now using the dynamic 
loader, but the Linux library still works on Syllable Desktop

R3 Chat still doesn't work, though, but for a different reason than 
on Syllable Server

I'm only testing it by starting the interpreter and trying a few 
commands

Please don't use it to control nuclear facilities ;-)

just reading up on syllable... neat looking os

I like that it is amiga inspired ;-)

Thanks

Anyone know if we can shorten a block supplied to us in an extension?

it has to be the same block, not a copy.

something like the 'REMOVE function, but accessible from within the 
extension/host-kit

I think I'll be able to run the custom Gob Renderers in a multi-threaded 
setup by next week.


This means one thread will simply be rendering while the other will 
be handling events and manipulating data.


it should work since I've got changed state control built-into the 
primitve API, which lets the renderer know when to update its internal 
data... this will simply be set by the other thread.

if I can get the MM_timers to trigger the rendering refreshes on 
the renderer's thread, then the custom gob renderers can live on 
their own, and not even require explicit calls to refresh by the 
main thread.   


all you will need to do is manage data in the main thread, update 
it once the renderer is sleeping and it would update on its own when 
it awakes again.

if a data change takes more time than a single refresh interval, 
(i.e. the change is still occuring when the renderer awakes for its 
next refresh) then the renderer simply reuses the previous internal 
data. while its new user data is being setup.

primitives will have the possibility to setup run-time manipulators, 
which modify the internal primitive data on their own.  


this means you might not even notice that there is a frame jump in 
setup because the manipulators are still active, using the old data.... 

ex:  

'PRIMITIVE-A  has a targeting manipulator which keeps this model 
always aiming another model, 

'PRIMITIVE-B has a manipulator using a constant speed which ends 
up moving it in space.


now picture a situation where the scene update where taking longer 
than the sleeping time (or it just started at the wrong moment and 
occurs just before rendering starts).

if the main thread where responsible for triggering the refresh, 
you would see a noticeable lag. 


 but with this setup,  both primitives  would still continue to move, 
 while the speed is adjusted... when all the setup is done, the renderer 
 knows it can update and it then adjusts its internal data to reflect 
 the high-level changes made by the main thread.


the manipulators are C functions, so they will be very fast.  (there 
will be a special REBOL callback mode for testing, but it will be 
much slower)

now because both threads can work independently, we can do much more 
processing in the main thread and simplify the rendering so that 
manipulators just "use" data and process as little as possible, allowing 
for much higher scene density.  :-)

( and CPU fan noise  ;-)

Added a few recommendations in the host-lib section of R3 chat.... 
please add comments there, if you have any... 

just saying you agree is good as it shows Carl that the ideas are 
shared by several of us.

Added a few recommendations in the host-lib section of R3 chat.... 
please add comments there, if you have any... 

just saying you agree is good as it shows Carl that the ideas are 
shared by several of us.

and by the way, all the suggested macros are actually being used 
in real code, so they work.

I have published 'unofficial' proposal with improvements to the current 
RichText dialect in R3. If anyone is interested in this topic you 
can read the proposal here: http://www.rebol.cz/~cyphre/docs/rich-text.html
Any feedback is appreciated.

not found

Cyphre - what about using direct rebol.cz plus subfolder - you've 
got access to it. ClearOS is crappy in that regard - I sent bug report 
to them, with no result at all ...

everyone - hit reload several times, then you will get the document 
....

where should we discsuss it, here?

What does it mean?:

- Embedded GOB containers in text
- Gob - Renders GOB embedded in text


I can't imagine, how this stuff works, and is organised. However 
- i am buying a book on text typography and layout, but so far from 
what I have read, you basically divide page into columns or boxes 
section, you can link them, those columns/rows have those typical 
margins, origings, etc. set, but we are talking DTP tools here :-) 
Are we getting something similar here?:


It is possible to have multiple paragraphs defined in one Rich Text 
block. Paragraphs are positioned one ofter another vertically. Vertical 
space between pargraphs is defined by PARA/INDENT/Y values. Use COLUMNS 
command(see below) to define how many paragraph columns should be 
used for paragraph layout.


... some wireframe model showing the terms on the image would be 
usefull ... but maybe others will understand, what's your idea ...

Pekr, sorry, I forgot to upload the paragraph layout example image. 
Just reload the page it should be there.

Embedded GOB containers in text: that means you will be able to insert 
gob! objects inside the text flow

The document has been moved to http://www.rebol.cz/docs/rich-text.html

Just a detail... first paragraph should not be indented. The indent 
should be used only between paragraphs.

yes, the para/indent values depend on you so you can set it as you 
need..or am I missing something?

indent is not typically used as a term to mean spacing between columns 
- is the dialect already set?

the inter column space is called alley, usually

nothing is set in stone so if you know better wording I'm open to 
changes...

Maybe it would be good to see and example how the multiple paragraph 
text is supposed to be specified.

Btw.. the columns support is interesting, but will it be possible 
to select text from multiple columns?

And is it normal that glyph-metrix returns pairs for advance and 
kerning?

yes, text selection should work in multi-paragraph layout

pairs for advance and kerning: yes, that should be possible as someone 
may need to layuout text vertically. Not sure in how many cases/fonts 
the vertical values are used but they are supported by the system.

What about right-to-left direction?