World: r3wp

What are the memory management enhancement proposed ? We all saw 
how it was difficulte to manage the mémory in previous rebol. For 
small data content that not a big issue but as soon you start to 
play with grafical content the mémory stack is amazing ( for example 
this code http://shadwolf.free.fr/berlinClock.ziptakes 10Mo  when 
running and in my opinion that from far 9M mega wasted ...). Can 
it be a way to make the recycle function more efficient to trap all 
non in use data

preset in the memory stack

next thing is the VID2 event system in same code we can see the rate 
face feel function don't allow the  event handling for the other 
face the Quit button for example.  (still in same code). Those things 
are trivial and i don't imagine to have to search hours and hours 
a way to solve them.

last thing is the "extension" modules  I would like to know how  
it's planned to handle them  when u add an external DLL to rebol 
VM your goal is not to have to rewrite a brigde code for each of 
your DLL you want to work with and you don't want too your rebol 
application code to be over complexified in regard to the regular 
rebol code wich use shaped  dialects. I know that's not easy thing 
to do ....

I want to be able to use any DLL in a rebolist way  to resume that's 
maybe an utopy but dreams allows

made the humanity advance  ^^

VLC is handling MPEG2  too and hum it's patented and hum lets say 
the authors hum .... how to say ..... hum .... well they just don't 
care

I believe efficient memory use is going to be a major focus.

There's no reason that the authors of VLC should care about software 
patents, shadwolf: Where they live (France), software patents are 
illegal and can be ignored. Go France!

Memory management: R2 gets a bad rap for this because Windows doesn't 
report the working set seperately, so the numbers it reports are 
a little inflated with page file memory. Nonetheless, R3 should be 
better with memory.

The extension modules spec (as you call it) hasn't been specified, 
or even discussed at length yet. That's next.

I think the graphics engine is much more memory efficient in R3. 
A single GOB takes up 64 bytes of memory where a FACE in R2 takes 
up much more memory.

Making sure to minimize extra references to data will make them more 
collectable too. The change in function contexts helps with that.

but of course we don't know what is happening with Vid3.4 yet

this gives greater performance scaling: R3 can easily handle thousands 
of GOBs, while R2 may suffer performance wise when handling hundreds.

of course a face and a GOB is not directly comparable, but just run 
the 1000cows.r demo to see the difference :-)

VID is at a higher level than gobs, but Graham has a good point. 
All we know is that it will be good code, because Carl is doing it 
:)

well, hopefully it will have actual features this time. :-)

although I'm not really that worried. if VID3.4 will be very different 
and inferior to VID3, it's important to have Gabriele finishing VID3 
to have a viable alternative as soon as possible for proper GUI development.

Why would Gabriele finish it for ?

if VID3.4 does not live up to our requirements of completeness and 
scalability. basically all the things that are currently wrong with 
VID, then VID3 will be the way forward.

I just don't see that there are enough users to support two VIDs

I agree, which makes it essential that VID3.4 is good enough. Perhaps 
it would help pushing Carl to make VID3.4 as complete as possible, 
so we won't need VID3.

there are usually only alternatives to something if the things already 
in place are inadequate.

Well, I don't see how Carl will have time to write all the widgets

So, I guess we all have to pitch in as soon as the prototype appears

He doesn't have to write the widgets. He only has to build an engine 
that will let you write most widgets with ease.

Yes, that was what I was meaning.

For example in VID it's very hard to build a well-functioning popup 
menu due to some restrictions on panels, clipping your content and 
you can't put things outside the window. in VID3.4 it should be simple 
to make a popup.

We need access to all the information that we can get to place those 
popups in the most appropriate area

we need to be able to replace Rebol native fields with OS type fields 
too eg. handwriting recognition

I had proposed a system to abstract input from the GUI a while ago, 
but it was mostly ignored. it's probably not that easy to implement.

Suggesting the impossible?  Or improbable ?

I don't know :-)

but what it would do, would be to let you use very different devices 
for regular input, such as a Wii controller. there would be no changes 
to the UI itself. if you need additional graphical controls like 
an on screen keyboard, it would be part of the abstraction rather 
than a part of your GUI.

then you make an input model, which maps controller behavior to what 
you want to get out, and then you could use it for regular input. 
this would work the same for input devices that some handicapped 
people use.

Have you done some work on this ?

only theoretical.

Or, is it just a gleam in your eye?

it's just an idea

but I think it makes sense. I've studied the problem a bit. Everyone 
else makes special cases out of it, rather than a generic system 
for strange input devices. I had hoped that VID3 could be the first 
GUI ever to do this. It would mean that you can write a GUI and a 
handicapped person or a person using handwriting recognition would 
be able to use it without modifications.

There was the Tao which scaled output to fit the devices available.

So, the reverse?

It was prompted by using the speech recognition system in MacOSX. 
While it's fun to use, it only lets you speak certain commands and 
only within the currently active window. There's no real system there, 
but if there was, it would be awesome.

Yes, this is input. the output is not relevant to the input in that 
sense. There are usually certain combinations, but they should not 
be depending on eachother.

we should aim for this

input systems are changing all the time .. we should just write the 
HAL just once

how does the hand writing system work in tablet windows?

do you write directly in the field and then it's translated to normal 
chars?

you just write in a text box