World: r3wp

I can't find the /seek refinement on the READ function in the last 
public release. The OPEN, READ and WRITE functions changed quite 
a bit with the Unicode changes. All of the docs and my comments relate 
to the versions since the Unicode changes.

ok

There is not a public link to the internal releases for the development 
group of REBOL 3, and that includes the Unicode releases. There isn't 
much point in posting one either, since Carl's GUI changes are just 
as extensive as the Unicode changes, and we haven't seen them yet.

I'll be posting more information as I get it, but things are promising 
so far :)

Fun fact: Compressed size of the new R3 GUI is 13.8 kB.

Gabriele's VID?

No, Carls new VID

Uh, sounds oversimplified. Can it draw at least simple button? :-)

I don't think styles are counted in yet, but there are a few styles 
in the design.. Carl sounds very pleased with the design. He's working 
out a few bugs, before I can get my hands on it.

So how do you know its size? I thought you might have it already 
...

He told me. :-)

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.