World: r3wp

ah :-)

Brian, i'm sorry i made a mistake, it was not the /seek refinement 
i used (which don't exist) with the 'read function but the /skip 
refinement.

Anyway, it seems that we can do a seek position with an obsolute 
index only when opening the file. After that, we can only skip the 
port. with relative offset. I think a /seek  refinement is missing 
in 'read function

(to seek in an opened file like with can do with R2)

*like we can do

Henrik, Pekr, the VID3 of Gabriele was really hudge (IIRC only the 
style sheet was 100Kb). 

It should not be too hard to do better even if the Gabriele' contribution 
was great.

i'm especialy curious how Carl managed the dynamic inheritance of 
styles (if i hunderstood correctly its ads)

Well, if I compress ALL of my VID, I get 37k. So, I'm not really 
sure it is that much bigger...

... and ... your VID was almost complete, whereas noone really knows, 
what Carl's version can('t) do ....

Steeve, the public build doesn't reflect what you will be able to 
do with REBOL 3. The docs refer to later builds.

Petr, anyone who reads the docs, has perhaps talked to Carl, and 
has done some deduction can tell quite a lot about what Carl's new 
VID will do. We aren't totally in the dark.

For instance, Steeve's question about the dynamic inheritance of 
styles can be answered by looking at the docs and the blogs Carl 
wrote about the extensions to BIND and IN. IN could handle dynamic 
inheritance, BIND handles static inheritance.

BrianH: I know. But we were talking size here. And the engine itself 
might be rather small, but once you add new styles, it grows. And 
also - to save some space, Gabriele e.g. introduced another abstraction 
- make-gobs dialect. Carl has another preference here - not abstracting 
this one, so it might make source code even larger. My point was, 
that current measure Henrik posted compared to Gabriele's almost 
complete VID3 is no measure at all, unless we know, what is inside 
in Carl's version ....

He posted this Monday, and am not sure it would hurt to publish it:

Delay in upload caused by:


1. Resize needed some more work.  That has been done, and it is much 
better.  We will probably see a few more bugs, and may still want 
to make some general adjustments.  The main idea of resize has changed 
from earlier VID releases. I will write a DocBase page on it to explain 
how it works and why I changed it. 


2. A few styles broke in recent changes. These need to be fixed. 
Should only take a few hours.


3. A few weeks ago, when making larger changes, I removed some of 
the compound styles. I want to add back at least one or two, probably 
LIST for text lists at minimum.

nice, thanks ... wondering why resize model needed to change - it 
looked good ...

Gabriele's resize model was a bit slow and difficult to understand 
- no offence to Gabriele, he just adapted the TeX sizing model. The 
problem is that the TeX sizing model was designed for desktop publishing 
and that doesn't require fast resizing, just complex layouts. It 
was overkill for UI layout.

The main reason that Carl's UI is so small is that he simplified 
the implementation to the point where something like make-gobs wasn't 
required to make the UI fast. The resize model is so easy to use 
that most of the time you don't need to specify sizes at all.

I wonder if there are specific needs for resizing document layouts?

BrianH: user-wise,  TeX model was rather easy to understand. It is 
a proven model. I hope Carl's model works .... when I can hear overkill 
for something which works, I fear underfeatured in Carl's terms ... 
I don't want VID3 to be built on compromises.

IIRC make-bogs was not here to make UI fast ...

According to your words, it seems that you and Henrik have access 
to the code, right? :-) Have you studied Gabriele's VID too? How 
do those compare?

I have no access to the code.

but how would BrianH know details about new resizing model, not having 
the code? :-)

Carl does write occassionally..

occasionally

Since I have implemented resizing models in the past, Carl discussed 
his new model with me when he came out of hiding. I don't have access 
to the code yet, but I can figure out things based on knowledge of 
REBOL, conversations with Carl, and mostly his writings and docs.

Petr, I am aware of the TeX model and its tradeoffs.

Every system is built on compromises, even TeX and Gabriele's VID. 
The trick in design is making the right ones.

Actually, make-gobs was implemented to make the UI fast. Gabriele's 
VID had to do a lot of calculations in the Draw blocks, and when 
you combine that with the resize overhead it added up. He added make-gobs 
to precalculate some of those Draw calculations.

Interesting. VLC player 0.9.2 used cross-platform own file dialog, 
0.9.4 uses native one.

Brian, I disagree that my system was slow. Indeed, I don't think 
you can do it much faster unless you make it more low level (ie. 
users need to specify more). Even then, I still think the speed would 
be the same.

make-gobs wasn't required
 - let's see what happens when Henrik tries to add his graphics.

Brian... it's not like my vid had to do a lot of calculations. ANY 
VID will have to do a lot of calculations. You can write all that 
manually (my proto2) or have a system that writes the code for you 
(make-gobs). There is no third option (well, you could interpret 
instead of compiling in something like make-gobs, but you won't like 
that).

I never got the chance to try out make-gobs, but it did seem to solve 
a complexity problem on the DRAW level by giving it for example an 
internal resizing model, which is very important for properly made 
GUI graphics..

Hmmm........

Gabriele, you can make it faster by simplifying the resize model, 
thus needing fewer calculations and less precompilation.

A simpler resize model is also easier to write code for - less fiddly 
for the less supreme programmer.

I may have not been clear. Given the goal of having the system figure 
out how to best resize in all conditions, I don't think you can make 
it simpler or faster; the TeX model is the simplest and fastest (because 
you can precompute most of the values) that I know.

If you have a different goal, then you can be faster. For example, 
if you use something like my make-gobs for faces too, then you can 
compile a resize function that will be as fast as if it was hand-written 
(if you optimize well).

That is a simpler resize model in that you have to specify all the 
constraints yourself, and it does not do tabular alignments automatically 
for you.

When you want tabular alignments, I don't think you can do much better 
even if you code the resize function by hand, with the exception 
of special cases like all faces being the same size and things like 
that.

Gab, do you plan or already do continue your VID approach? I think 
we have to do some trade-offs between what VID can do in terms of 
simplicity and features.


I think we should try your approach and Carl's on a realy world app 
to see what fits best. Maybe it's a good idea to have a Simple-VID 
(for smaler tools) and a Fullfledged-VID (for big apps).

... especially in the case when Gab's VID was 90% complete?

robert why not  but that will make again another rebolVM split  how 
to differencie what VID  version the app you are  going to use need

don't that will lead to a "Ho man that program is bugged it crash 
when i try to use it !!" and in fact the rebol script just needs 
the VID++ 2  turbo alpha ++ version

the rebol politics is rebol is all you need to do software

I'm agree that's a pity to abandon a work such advanced  and that 
demotive alot the comunity

gabriele worked hard to get his new VID and when it's all most complet 
Carl come with a better plan and trash out Gab's work that's not 
a good example to motive the comminuty to participate on further 
project where rebol content is directly conserned

How about adding the GAB  VID into ORCA ?

i'm sure Sillabe would like it even if Carl doesn"t

I'm now able to study the R3 GUI source code.