AltME groups: search

Ogre3D is the probably the best open source 3d rendering engine there 
is .. I followed it's path a long time..  his simpler "follower" 
is irrlicht .. maybe there are some new ones now I am not sure , 
since I am not actively following this area any more

yep, programmatically binding the engine is what I plan to do... 
especially since it will allows us to rebuild the binding at any 
moment just by flicking a switch and update it without any user-intervention.

so far, my options are:

 -a direct wrapper generator coded in REBOL using C++ sources, with 
 an advanced  C++ declaration to R3 Extension converter, 
	-I try out SWIG build an R3 extension output module for it, 

 -I use another language binding as the one to base mine with, and 
 make a specific tool to convert it to an R3 extension.

 -do a manual (and painfull) convertion, using a few generic scene 
 interaction commands.


One thing I'd like, is to add some way for the OGRE extension to 
be able to call REBOL code directly via callbacks, using their Extensive 
hooks throughout the api.


Although this will be slower than if the callbacks where in C, obviously, 
some parts of REBOL are swift enough (like series management) that 
they just might make the cut for REAL time rendering hooks.  Well 
implemented, they would be fast enough for common GUI interaction 
events for sure.

ElixirOS and some other commercial stuff which needs serious scalable 
views rendering tens of thousands of objects in real-time.

GLASS is a general purpose GUI using advanced dataflow programming 
at its core.  I've got some prototypes of various pieces of GLASS 
using R2 and AGG which work really well, but I've been waiting to 
be able to do HW gfx before Investing time on the real GLASS, which 
integrates the prototypes and new stuff too.

I know... but we can build code around the fact that its symbols 
won't be used for a long time.  like I say, its not something you 
do without knowing what you are doing.  any commands refereing to 
the old lib, can be replaced with no-ops raising errors... this would 
make it safe.

I haven't read everything here--just trying to clear a few groups 
so it's not as overwhelming next time I make it back here, but shouldn't 
it be possible to write the equivalent of R2's library interface 
*as* an extension in R3?

there has been talk about the possibility to declare the functions 
differently within the extension libs themselves... but I haven't 
had time to play around with this yet.

thanks for giving it the time, brian and I didn't have, to make it 
work  !

none... just reposting it for jocko... 


I believe he wasn't around at the time... and he was asking about 
other work done with extensions so far...

so, Robert, not sure if you understood all of these replies as even 
I had a bit of a tough time to "get" them.


Right now, Extensions only allow REBOL to call functions from a dll. 
  What I would like is to simply improve the extension model so  
it can also call REBOL code, as a callback or something else, but 
there are a few issues which make this a non-trivial thing to do.


So far there seems to be a generalized idea that there should be 
a different kind of extension which allows this, but I see no reason 
why it should be another, different. api.  having one DLL   for  
REBOL -> DLL  and another for  DLL -> REBOL  makes absolutely no 
sense to me.   IMHO we need a single DLL able to do both.  Even if 
it means a little bit more work to design it.

Hm, I'm not sure right now, I think it was possible to change it, 
but I may be wrong. But I think there were no error checks, it was 
just a basic version that can produce something working and I haven't 
much time to improve it since. That has changed recently.

But I must say that I currently use my time on getting SQLite up 
& running for R3. So far works already very good.

It's the dispatch. Right now with extensions, when you make a command! 
it makes a function that is dispatched by a function in the extension 
based on a number (which you can think of ay a key), to code that 
handles the command (the value associated with the key). In theory 
this is not that different from an object! grabbing data from one 
of its slots based on the keyword you pass it. Apparently commands 
will be able to dispatch to objects soon, and the functions assigned 
to slots of that object will handle the command code.


The DELECT dialect model was based on rebcode, mostly on its JIT 
binding. DELECT added the out-of-order, possibly optional argument 
handling to the dialect decoding phase, but the dispatch phase was 
mostly left out (I commented on this at the time). The command! type 
has the dispatch model, but uses the function call model for calling 
the commands. The overlap that Carl mentions is in the mapping of 
keys to command handlers.


If you unify the command mapping models between DELECT and command!, 
then that code can be shared. This means that the DELECT function 
could do the out-of-order dialect decoding, then dispatch the operations 
as commands. Values of the command! type would continue to be called 
like regular functions in DO code or by APPLY, and then dispatch 
using the same dispatch code as above. On the other end, commands 
would either dispatch to objects (including modules perhaps) or extensions.


By the sound of it, this might also allow the command! type to serve 
as a method pointer, but we'll have to wait to see about that :)

I think I could have something working for non multi-threaded stuff 
in a little while... I'm working on this now... its the time I have 
to do it ... after that...
I return from a sanity preserving week of vacation.


and yes I hope I can help with the development, especially since 
I have two different devices which need to be added.  

with the current host I might make my hackback do some usefull tests 
to help shape a working model aka prototype.

but the coupling with the core run-time is practically abscent.  
there is only one function I can use to have the run-time do anything 
and thats a pretty simple... do_rebol_string() which basically runs 
a block of code in the global space... beyond that I've only got 
network/file like ports, which basically are streamed I/O.  


I can't create data directly and leave it at the port, in a block, 
like I'd do for a proper event queue.   This is currently my pet 
peeve about the host... 


but let's not be judgmental... I'm VERY happy I have the host, so 
I can at least try to rig something up with bailing wire, duct tape, 
pliers, a bit of string & epoxy glue.  


 Extensions & the core allows me to hide this under a nice fiberglass 
 body  ;-)

there is no secret channel AFAIK.  R3 chat is the best place to reach 
him.  he still doesn't reply in real-time... it depends if he's in 
the batcave or not.

I can make a simple /library like dll loader for windows if anyone 
really needs it.    I won't put time on this unless there is a real 
need, but if you need it, just speak up, its fairly easy for me to 
do.


a simple struct dialect would take a few hours to iron-out tops. 
 it would be much more flexible than the struct! datatype for sure.

I can make a simple /library like dll loader for windows if anyone 
really needs it.    I won't put time on this unless there is a real 
need, but if you need it, just speak up, its fairly easy for me to 
do.


a simple struct dialect would take a few hours to iron-out tops. 
 it would be much more flexible than the struct! datatype for sure.

Max: "on windows its a simple function call" Could you tell us which 
one? I don't remember seeing such thing in win32...but I didn't looked 
at it since a long time.

tom, yes.    that will start out simple, but will be handled in the 
rebol & extension part of the code.  


once I have the actuall subroutine jump (ASM call) code in place 
with an unlimited number of run-time functions registering, we'll 
see how the community wants to evolve the struct! dialect.


I am thinking of a rebol to struct converter and a way to keep handles 
to those structs, and even use them within sub structs, so that we 
can easily reuse allocated structures without doing the convertion 
over and over.

There is a module inside the extension, and it gets wrapped around 
the extension automatically at LOAD time. That REBOL code in the 
string constant that you return from RX_Init is the module that I 
am talking about.

I agree with Andreas, when I looked into the hostkit code it looks 
that table of 'names' of the devices is hardcoded in the r3.dll at 
the moment. My only idea (workaround) was to try use for example 
'clipboard device name and try to replace the internal code with 
custom one for testing purposes. I haven't tried that though from 
that time yet. Not sure if it is worth the time. Better wait for 
new hostkit ;)

The main thing: linear command evaluation blocks. The replacement 
for the delect method.


Once that's done, I'll release View, but only with the windowing/event 
system, not rendering... then, Cyphre can bring the rendering method 
back online as his time allows. (Or, you can do your own in OpenGL 
if you feel so inclined.)

dinner time.

I have a client which might need R3 parsing but needs to use the 
R2 run-time...

Yes, but the ARM make tool looked like 1982 the last time I tried 
it.

The method I use for R3 simply uses REBOL to generate the host-kit, 
the makefile, and other related files at the same time.

and now is probably as good a time as any to move this discussion 
to !REBOL3 Host Kit

I too vote for an  A101 numbering the next time a package is released... 
its going to be MUCH easier to follow for everyone.   IIRC the A97 
created this strange pre-release condition too and it had to be specified 
each time we talked about what we downloaded.

Lack of time, but I'm also waiting for more specs for the extensions 
(image datatype, callbacks ...)

another approach would be to access a single attribute at a time, 
but anytime data is exchanged, I think re-using the current frame 
code is ideal... 


it already solves all of the type and memory marshalling, separates 
the external data from the core, solving the issues with the GC and 
stuff like that.


as long as the API copies data when its setting values back in the 
core (which I guess its already doing) then I see no point in inventing 
a second API just for objects.

There are changes in the design, files, and interfaces are made, 
so that, you will have to spend some time for migratintg your applications. 
I tried to maintain is as painless as possible, but still some concepts 
have changed. There some files were removed from the package, but 
not functionality.
 - probably ...

The concept of "just upload it" does not work.  Here's why:


1. Parts of the API may not work at all, because of course, they 
are not tested!


2. Parts may work incorrectly... and therefore are just going to 
confuse most developers, and they'll get frustrated.


3. Because the code is not tested, it floods CureCode with tickets, 
most of which should not even be posted there.


4. Without a testing methodology, there will be no consistent test 
suite over time... just a bunch of hacked together code pieces from 
various developers.

the current code is a single ~16kb file,  so its not too large right 
now.


obviously as more types are added, this will grow, but since I'm 
using a "rebol-formatted intermediate source tree", its easy to improve.


the parser just generates a version of the C source in this "RFIST" 
format, and the generator only has to convert this into something 
else.


in time, we might even build different emitters for the "RFIST" data.

funny thing is that getting an amiga version to work probably would 
take the least time of all OSes... its so clean.

internally that can work, but the issue arises when two threads share 
a series. if they write at the same time, even with a copy, things 
like indexes might not update atomically to the copy operation.

I think interop is important, but I don't know if there's a clear 
cross-platform choice. I looked at http://www.spread.org/some time 
back, but it doesn't support Windows and is probably best accessed 
as an extension. 


I can pull notes together for discussion, but I don't want to spend 
time on it without knowing that it has some chance of it being helpful 
and making a difference.

One enterprise service I did used EDI formatted information and allowed 
queued message sending and receiving, with order detection and re-sending 
on time-outs or connection errors.


funny thing is that I had to throttle my REBOL app because it parsed/replied 
messages faster than the remote service could handle :-)

I have no idea on how date values are stored in C, all that the docs 
say is that date values are 32 bit encoded date and time zone values, 
so I mainly tried with value.int32a but tried other members too. 
I have no idea about how the encoding is done and - as Anton said 
- I really don't want to reverse engineer it.

Hmm, I think I've to check this again. At least, a simple 

    RXIEXT int RX_Call(int cmd, RXIFRM *frm, void *data) {
        return RXR_VALUE
    }
    
returns a proper date value for

    test-date: command [date [date!]]
    
I'll see if I can find some time to work on this evening.

It really should only depend on the time I can piut aside to work 
on the driver.

Thanks, Brian, for the status update, that's good news in more than 
one way. I con stop trying and just expect it to work next time. 
.'J

this is what carl will be adding to the next host-kit.... 


//------------------
//-    #RXV_xxx
//
// REBOL EXTENSION GET Macros
//
// provide direct RXIARG access macros
// with these macros, the single argument should be an RXIARG *
//

// this is usefull when the RXIARG is NOT being used from an argument 
frame

// but as a single value, like when we use RL_Get_Field() or RL_Get_Value()
//
// if the argument is dynamically allocated, ex:
//    RXIARG arg = OS_MAKE(sizeof(RXIARG)); 
// then use the macros like so:
//     RXV_WORD(*(arg));
//------------------
#define RXV_INT64(a)		(a.int64)
#define RXV_INT32(a)		(i32)(a.int64)
#define RXV_INTEGER(a)	(a.int64) // maps to RXT_INTEGER
#define RXV_DEC64(a)		(a.dec64)
#define RXV_DECIMAL(a)	(a.dec64) // maps to RXT_DECIMAL
#define RXV_LOGIC(a)		(a.int32a)
#define RXV_CHAR(a)		(a.int32a)
#define RXV_TIME(a)		(a.int64)
#define RXV_DATE(a)		(a.int32a)
#define RXV_WORD(a)		(a.int32a)
#define RXV_PAIR(a)		(a.pair)
#define RXV_TUPLE(a)		(a.bytes)
#define RXV_SERIES(a)		(a.series)
#define RXV_BLOCK(a)		(a.series)
#define RXV_INDEX(a)		(a.index)
#define RXV_OBJECT(a)	(a.addr)
#define RXV_MODULE(a)	(a.addr)
#define RXV_HANDLE(a)	(a.addr)
#define RXV_IMAGE(a)		(a.image)
#define RXV_GOB(a)		(a.addr)

(never mind, time to sleep for a while:)

Yeah, time for bed here too, good night.

Here's how I explained to myself how things went:


With A102, the time I started playing around with extensions, there 
was this RL_FIND_WORD which is supposed to map words against an "extension 
local" word block. But sadly, I never got that working.

It was the "temp hack" comment from which I concluded that the preferred 
method then became RL_MAP_WORD, which maps a word to a global word 
id, hence the 1381 number you've got yesterday. With that, you don't 
need to ENUM in your code but can just compare words supplied with 
words known.


But, I may be totally off track with that reasoning ... wouldn't 
take me any wonder :-)

I'm so stupid! I was testing on wrong data all the time.. the last 
one is correct:)

Brian, I'm not sure about that. IIRC the value slot of double passed 
as command! arg is just on the 'function command frame' at the time 
the command! is executed so it is a copy of the real value you are 
refering to.

ok.. no problem.. I was just asking as I'm learning. It's just something 
like educative free time project for me as I don't need it.. I use 
maybe 20 functions of IM in real life.

I used to develop a Chinese Font Engine in R2 using Win32 API GetGlyphOutline(). 
Now I am trying to do it again in R3, but this time I will get the 
glyth data from OpenType font files directly. Basically, I can read 
the Glyph data now, However, when the glyth has zero contour, my 
OpenType font format parser got error. The OpenType Spec offered 
by Microsoft is not clear to me on this.... Hope I can solve this 
problem soon. I cannot wait to see Chinese Characters in My R3 GUI. 
:-)

my opinion is, that most of the time I just want to unview everything, 
and only from time to time I want to unview particular window

I don't agree with having 0x0 as hidden. It is an implied state, 
that would occur any time the X or Y size becomes zero. There are 
behavioral issues to consider, such as, whether you want to obtain 
data from the face, using GET-PANEL, or how tabbing and disabling 
behaves with a zero sized face. If the layout is dynamically created, 
so that a face is inadvertently presented as zero-sized, you will 
get topological side-effects.


For animation, you would have a start and end position. Animations 
should not express anything about face states. Only dimensions, offsets, 
transparency, colors, easing are relevant with animations.

Animation should be an entirely separate part, to make it easier 
to discuss, design and change when the time comes, possibly an extension 
of SHOW-FACE.

I prefer to have it designed properly, rather than to rush the implementation. 
And I agree with Max - there is imo long time plan to have extension 
API for devices ...

Maybe RMA team could set-up a blog too (re Amiga group post about 
OS 4.1 progress). I know there's probably not much time for that, 
but I do remember some of Henrik's articles, and it was really nice 
to read :-)

The GUI is still changing too much for particular blog articles. 
Around on a daily basis I get updates on 5-10 source files, which 
I don't have time to go through, otherwise I would publicize more 
information.

Win Vista, 32-bit. RMA A110 build, tried with downloaded and also 
on-line r3-gui.r3 populated using load-gui function. Do the script 
once, press some button, close it, do the script the second time, 
press the button - crash ...

unload" window (layout)" - possibly just by setting the window face 
to NONE. Most of the time, you don't want to do that, so I don't 
think any special functions are needed.

Guys, time to crank up the volume and build a concrete roadmap for 
the GUI. I have a suggestion to further accelerate the development 
of the GUI: RM Asset will over time require some specific, but complex 
styles, that the community will need as well. We are developing a 
SCRUM tool, which you will need to use as a basis for discussions 
and development of these styles. Consider it also training to become 
a good style developer. For any needs, Cyphre, Bolek, Ladislav and 
I will be available to extend the UI base as needed to create the 
styles mentioned below. We also provide examples, training and help.


Many of these styles are focused for development of particular types 
of applications that open many, small windows inside a large work 
area for flexible construction of data analysis tools and other traditional 
Windows or Linux applications.


It could be a combination of how graphics shader networks are built 
(though without the need for zooming), to regular multi-document 
management. The ultimate goal is to build styles that allow a highly 
user configurable multi-document GUI to be described, using only 
the R3 GUI dialect and some helper functions that we already have.

These styles are generic enough to be usable in plenty of apps.

Inspirations for window arrangements:


http://houdini.dreamerzstudio.net/wp-content/uploads/2010/05/reflectiveShaderNetwork.jpg
http://www.codeproject.com/KB/docview/TabbedMDI/TabbedMDI.gif

Inspiration for segmented area management:


http://www.solidsmack.com/wp-content/uploads/2010/12/modo_501_RayGL_sample_002.jpg
http://jedit.sourceforge.net/jedit-snap-12.png

A list of general styles that definitely are needed:


- Style for doing multi-document window management, using various 
arrangements, window linking features, as borrowed from apps like 
Photoshop.

- Style for segmented area management, editable by users, for arranging 
tool areas, view areas. Segments are adjustable in size. Inspiration 
is JEdit and Modo.
- Multi-document window style, for use in window management style
- Tool window style, for use in window management style

- Tear-off style for toolbars and tool windows, for use in window 
management style

- Regular Windows-style menu bar with submenus, also for right-click 
popup menus.

More specific styles that will be needed later:


- High-performance style for graphing points and curves in a coordinate 
system, with zooming and panning.
- Gannt chart style: http://en.wikipedia.org/wiki/Gannt_Chart
- Harvey Ball style: http://en.wikipedia.org/wiki/Harvey_Balls
- Year calendar style
- Month calendar style
- Week calendar style
- Day calendar style

- MacOSX style tag field: http://kitara.nl/wp-content/uploads/2010/05/31.png

- Console style for input and listing results. This could eventually 
grow into the base for a View based R3 console.

- Highly ergonomic numeric input styles, that support unit conversion, 
inline math.

The question is where to start and what fits with you.


The time table is simply ASAP, and preferrably want some results 
within the next 2 months.


If you are planning R3 apps soon, it would be a good idea to have 
a look at the list to see where you may be able to contribute, as 
the GUI moves to beta status. RM Asset needs to spend time building 
end-user apps for R3 and the GUI is becoming ready, except for the 
above mentioned styles.

Carl is the one to release host-kits. He has full access to our code-base. 
As Brain said, from time-to-time RMA changes are merged.


IMO it doesn't make sense that we fork the host-kit and have two 
release in the wild.

It makes sense... because I could save some time if I could work 
with your version or to be able make a diff between Carl's and yours.

BrianH: there is no need to "defend" Carl here. I don't need to speak 
in a way for anyone to feel comfort on not to feel comfort. Let's 
follow facts - no matter what HostKit allows us, there is still the 
need for Carl being involved. Oldes is right - repos should be merged, 
period, or it still feels like we are somehow blocked. Yes, RMA or 
anyone else can experiment at will, and this is cool about the HostKit 
indeed, but as you can see, some developers might get reluctant to 
waste their time, if repos are not merged for a long period of time 
....

is not it possible to keep the compatibility with the Carl's demo 
and gui, which achieved a rather good level of usability up to A94, 
and which were rather well documented ? From this time, where alternative 
gui's were launched, we have nothing, apart from low level graphics 
programming, with almost no documentation.

Docs about the system before the system is done would help people 
prepare, so their ideas will be ready by the time the system catches 
up. Plus, it's not so difficult to make minor changes to the docs.

Pekr, I can't be sure at this time, because currently the styles 
are worked on via immediate need for fixes for things like the SCRUM 
tool, which is partially why I couldn't complete the roadmap. It's 
probably fair to say that the styles currently present in the style 
browser will be completed by RM Asset, but that may change.


What I imagine is that some of these styles that I mentioned will 
be comprehensive, long running separate, autonomous projects. A style 
like graph will need a ton of features, possibly separated into substyles 
and it would hopefully not depend on anything, but low-level features 
in the GUI system. Someone like Maxim could do this as he knows how 
to do high performance graphics. A windowing system can also be run 
as a separate project. Each project could be immediately stored on 
github.


RM Asset can do everything ourselves, but in the end, this will just 
take much, much longer, perhaps an additional year, which affects 
everyone interested in the GUI.

In the beginning the chances are high, that the general & common 
styles that everyone needs are done because we need them too. As 
time passes, we will have a stable set of styles, that will cover 
90% of every app we will do. The remaining 10% well be done on-demand, 
project by project.

We'll be releasing new version of R3GUI later today with the docs 
Ladislav mentioned.

Unfortunately I had not enough spare time to update the old 'gui 
demo'. So now a question to all who cried here :) Is there any volunteer 
who will try to convert the demo? I think this is great oportunity 
to:
-learn how the new version works

-found possible bugs and issues and report back to RMA team or even 
provide fixes
-give back something usable to comunity

So anyone interested?...

this quote implies any comunity work have to be based on a first 
step which seek the compromised best solution... which fundamental 
step wasn't done with the R3/GUI since their purpose is not to manage 
a  compromised vision of  R3/GUI edicted by the community but it's 
just to implement on top of the design edicted by Carl. In the actual 
design the least I can says is that you will need at least to do 
the work three time to support Win32API , X11 API and Quartz API.. 
+  any other windowed api. Knowing you are only 5 guys in RMA is 
it stupid to notice that and from this try to get the better solution 
the one that will give you best chance of success ?

my point is instead of having to do this interface 3 times for windows, 
linux, macOS X  why not  take the time to discuss the probability 
to do it with another library that could be use as it  on the 3 main 
OS ...

Repeating from above:


We'll be releasing new version of R3GUI later today with the docs 
Ladislav mentioned.

Unfortunately I had not enough spare time to update the old 'gui 
demo'. So now a question to all who cried here :) Is there any volunteer 
who will try to convert the demo? I think this is great oportunity 
to:
-learn how the new version works

-found possible bugs and issues and report back to RMA team or even 
provide fixes
-give back something usable to comunity

So anyone interested?...

TomBon - I think, and I hope, that not much changed in underlying 
architecture design. But you probably refer to Carl's Spring skin 
:-) First time I saw it, I found it strange, now I miss it :-)

Rebolek - my dog randomly drawing would come up with better aesthetics 
probably :-) One should have pleasure to play with the stuff in the 
process, while I have really a hard time looking at any single screenshot 
of new GUI. What I don't understand is, why it changed from the former 
look, if draw code for such style was already available?

And I bet his dogs learns faster, that we stated more than once that 
we currently don't spend any time on eye-candy. Maybe Petr learns 
it too ;-)

I apreciate the work put onto R3GUI. I am just a spectator, I am 
not involved into the development. So I whish to say thank you to 
all the people building R3GUI.

From time to time the community get nervous about lack of development 
or inadequate results. Please note that they are building the foundations 
for further work. One time in the future the GUI will have the look 
similar to MacOS or GUI found on mobile device. Until then an old 
fashioned GUI is better than nothing.

Please consider all the hard work put from unpaid people on this 
project.

from the page of RM-Asset.com we can read and I quote:

What's special about RM-Asset?

We are very productive. This is good 
for you because we need less time than you might have thought.

We 
are very efficient. Internally we joke and say 
All good software fits onto a floppy-disk!"


We keep things simple. Our solutions are simple, easy to install, 
maintain and use. Most solutions are designed to complicated. We 
have streamlined designs making us faster while resulting in higher 
quality."


Fine but since you took over this proect we don't even have a prospective 
documentation (list of the widgets you want in it, the condition 
of this project, the stepstones on the road)or an api documentation 
etc... this means 0 lines of code. you claim to be the best to work 
fast to be serious. I just ask you to prove it.

Shadwolf - this is not the right group to discuss advocacy/strategy 
kind of things. But here's my take:


- RMA is a commercial entity, and Robert made it clear enough - they 
develop GUI to the point, when it will be usefull for their business 
apps. The chances are, that if it is good for them, it will also 
be good for others


- Robert is a good guy! He pays several top community guys, and - 
he gives result of such work - FOR FREE!


- RMA guys are VERY open, to listen to other's opinion, it is just 
they will accept only REALISTIC proposals - trying to convince them 
to change to differet underlying toolkit CAN'T work at this point. 
Even if such a toolkit would be good time solution, there are no 
free resources to make such a big change


- RT (Carl), plus the community, should be gratefull, to have at 
least RMA's GUI, if there is not other gui in the spot, and RT itself 
is not active in that regard.


- If I should name at least something what I am not considering so 
optimal, then it is a bit of a closed nature of development. I mean 
- I might wrongly understand initial impression of a SCRUM model. 
I missed the big picture, plus particular reports ... but - ANYTIME 
I was not lazy to ask, my questions were answered. Anyone but me 
can do just the same - ask. This is called - communication :-)

So much for RMA and their relation to development of R3 GUI ....

As for the move to other toolkits. Reading some of your opinons, 
and not being good in low level details, I still dare to say, that 
you might get some things wrong. There would be imo no direct benefit 
in moving R3 Graphics to GTK+, Qt, etc. Most of those toolkits are 
just bigger. You also seem to overrate the difficulcy of porting 
View to different platforms. Just look at Steve Solie - he did Amiga 
port in nearly a no time - one month? Noone imo expected R3/View 
running on Amiga. All is needed imo is - free hands, knowledge, and 
will to do the port.

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)

The question really is, if we should not really support CSS box model, 
even if most of the time, you would not use some of parameters ...

Host code goes through a process at load time and loading most of 
the mezzanines happens later in the process. If you load your extension 
before the mezzanines finish loading, no REPLACE.

Something occurred to me after I left torun errands: You could use 
options: [delay]. Your extension object would be loaded, but the 
module itself wouldn't be imported until the first time you refer 
to it with the IMPORT function or a Needs header. That way you can 
run the RL_Extend whenever you want, but delay actually setting up 
the extension until the runtime is in place.

busy time

Let's just do a quick sanity check before wasting more time on this. 
Change the #define HOST_LIB_SIZE in host-lib.h from 31 to 33 and 
see if you still get the "wrong size" error.

ssolie: the only file that needs to be reformatted so it supports 
other platforms than windows is agg_truetype_text.cpp + .h

Otherwise there is already available FreeType wrapper so the rest 
of code can work  even on OS4

But the current hostkit code needs some more work to extract the 
font/text rendering parts so they can be controlled by defs.

If you don't want to waste time on this I can have a look at it over 
the weekend and make the changes so you should be able compile without 
the text code for now. Just let me know.

Cyphre, that would be great if you could make the necessary changes. 
I have simply commented out text support for the time being so I 
can continue to work on other areas.

(Let's just say I've been doing source control for a long long time. 
;)

Would have saved you hours of time in the course of R3 alone.

Time to get that going again for R3.

The BlackPad isn't even out yet, and people are only speculating 
that the new OS will be ported to the BB phones. I think you can 
afford to take your time :)

Only the linux libr3.so at this time. Will attempt to add the windows 
lib.

I seem to remember from last time we tried this... there's a special 
linker tool required on OS X.

I can have Cindy setup a new devl account... but I suspect this will 
all lead down a road that will cost me a lot of time.


I don't see why cross building from Linux or BSD is a problem.  It's 
just a lib, not an app.

one small step at a time

In user terms, if I hit the close gadget on my window then it closes. 
The only time it may not close is if the event queue is full. There 
is no "are you sure?" opportunity. This is why I asked about it. 
:)

Then how can it be that every single other video player under OSX 
performs at least twice as good, CPU time wise, as flash?

1ooo cows do not work? Time to rewrite cow as R3GUI style!

I have to catch up to what happened in the last weeks, haven't had 
much time to follow ... Thanks, Andreas.

No need for that, I can wait. I won't have too much time anyway, 
it's just that I don't want to fall behind with my ODBC extension, 
and A109 is lacking some functionality that A110 should already supply.

ssolie: looks good! The FreeType needs some fine-tuning as I made 
the conversion very quickly and had no time to look into the freetype 
API details to provide 100% accurate results as on Windows. But anyway 
it is great progress on your side. Keep up!