World: r3wp

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.

As far as I can tell there are animation effects in it as well as 
a small suite of debug tools. Each source file is really small, around 
2-8 kb with a few going above 10 kb. Fully commented and very clean.

Running the GUI now. It's... colorful :-)

elastic?

meaning?

resizing is automatic and good?

resizing is automatic, but buggy. there is a list of known bugs.

there are animations in the GUI and I can resize the entire window 
while they play.

They are transitional animations and are fully interruptible.

http://rebol.hmkdesign.dk/files/r3/gui/001.png

Skin is for testing purposes.

Carl says the animation system is a simple prototype.

Mostly because events are not yet pushed correctly to it. So it's 
an event based animation system.

automatic scrollbars?

meaning?

aaaah, what a mixture of colors :-)

Pekr, well, that's Carl's work. :-)

so we've got "transition" effect? What are they used for?

.e.g. change of tabs/windows?

The GUI feels fairly quick, but Carl says there is still a lot of 
optimization and caching to be done. This won't happen until he feels 
the entire system works correctly.

btw: what do you mean by "each source file" - is the code now organised 
more in the RebGUI way? E.g. each "widget" being one file?

the transitions right now are simply each element you see in the 
right side sliding into view one at a time. I've not yet studied 
how that works.

each style is a separate file

Alphe, ORCA is way, way underpowered to run any VID

the source is divided in two parts, with files beginning with g-* 
being the GUI system and s-* being style files.

are there any editable styles yet? I mean - text area, fields? What 
about focusing?

So, Orca is where Rebol was 10 years ago?

... those colors remind me of first VID version, which was called 
CID :-) http://www.xidys.com/rebol-view-screenshots/- the first 
one :-)

Yes, but ORCA is also where REBOL may be in ten years: open source 
:-)

It's also where REBOL will hopefully be next year: an embeddable 
library

r3 already is an embeddable library :-) it is just host source codes 
were not released .... yet ... :-)

As you just said above, R3 is not out. ORCA is

REBOL [
	Title: "REBOL 3 GUI - Development Module Loader"
]

files: [
	%x-funcs.r
	%g-defs.r
	%g-debug.r
	%g-funcs.r
	%g-styles.r
	%g-faces.r
	%g-panels.r
	%g-events.r
	%g-text.r
	%g-effects.r

	%s-fonts.r

	%s-panel.r
	%s-button.r
	%s-bars.r
	%s-text.r
	%s-image.r
	%s-lists.r
]

code: collect [foreach file files [keep load file]]

len-kb?: func [s] [round/to divide length? s 1024 .1]

src: mold/flat code
gui-cmp: compress src
gui-size: len-kb? gui-cmp 

print ["GUI Size:" gui-size "KB /" len-kb? src "KB"]

do code