World: r3wp

Cyphre, don't you have any demo of new View? Released somehow .... 
by accident? :-)

I wanted to post some cool demo with 3D accelerated hi-quality GUI 
from R3 on X-mas but got harddisk crash day before release so all 
my work is lost :-/

LOL

a new view ? is it accessible ?

(just kidding)

where can it be downloaded ?

Only to Cyphre - he's writing it. Isn't that right?

dl: on rebol.net ... in about 6 months , hehe

ok i ll be there ... if any need for beta testers i m ok, i got time

xavier: (we are all just kidding :-)  only Cyphre has a clue as to 
what is hapenning with R3/view

xavier: you can get latest View here http://www.rebol.net/builds/
AFAIK last update is 27-NOV-06

It's not R3 though. For that you wait, and provide suggestions and 
feedback to help shape it.

thanks

What I can say R3/View is evolving in a good way. I'm sure everyone 
who is willing to test first alphas(or whatever Carl release) will 
get a chance to test and make feedback/suggestions. Just please be 
patient. R3 is not just some simple update or bugfix ;)

ok, i ve followed some discussions about agg and i can only dream 
about what can be done with it.  I know that R3 is a major re creation 
of the virtual machine, but as a programmer i cant wait to see a 
version of rebol that interest the corporate world....  I	ll try 
to help as far as i can

Very cool demo Max!

Some people can break anything !!! Sorry 


** Script Error: find expected series argument of type: series port 
bitset
** Where: on-release
** Near: if find choice "/top" [
    face/stack/valve/top face/stack glob
    face/redraw
]

yes I've had that error a few times myself...

thanks to all of you who've tried the demo  :-)

Peter, is that error based on right-cliking and playing around with 
the menu?

Louis: (in reply to announcement)  Yes things are finally falling 
into place.  :-)  such as is with layered apis, you need each layer 
to be stable before tackling the next, and I've been slowly yet steadily 
building up a very nice set of tools.

Now I'm at a stage of refinement of the liquid core based on usage 
and desire for the most simplicity vs features.  In the last months, 
I've at least doubled the flexibility of the liquid I/O model and 
am working on a new iteration which should add yet another little 
layer of flexibility.

the canvas engine took a few hours to make, & then the demo took 
a few hours more (mostly handling the events)  so although you could 
choose to make the tool using custom code and trying to fix all data 
relationships manually... using liquid allows one to do so very quickly 
and results in rather speedy code.

(and then I know that liquid itself can be made 10-25% faster by 
removing some of the debugging stuff :-)  but I'm waiting for my 
code compositor before strarting to mangle with release threads.

Maxim : Possibly, I can't remember exactly and it didn't cause the 
script to abort. I  couldn't recreate the error today.

k

Henrik, just reading your blog on Toolbar. It says the toolbar will 
stretch if its initial width is 0. I would like to point out the 
standard way used by other VID styles is to use -1.
(I haven't examined the source, so not sure of your intentions.)

it is? I thought it was 0. oh, well, I'll fix that.

That button-bar is a good idea, I think.

please, test it, torture it, play with it. :-)

Yes, let me try to find some examples...

foreach [style obj] svv/vid-styles [if all [obj/init find mold obj/init 
"-1x-1"][print style]]
BASE-TEXT
VTEXT
TEXT
BODY
TXT 
.....
print mold svv/vid-styles/text/init

of course this will only count for X direction as I haven't implemented 
anything for vertical button bars yet

Most button bars seem to be horizontal so it makes sense to limit 
the scope for now.

it does provide a "fancy" background gradient. maybe it should be 
removed?

-1 fix uploaded

I don't think the gradient is a problem. There was a time when I 
shunned the extra complication.

It's working as you need it, and looks good, right ?

yes... although it would probably be more "correct". then again, 
the defaults in VID also have a certain look. as long as it's simple 
to override, then it may not be a problem.

I would wait to see what actual needs arise as you use it, before 
worrying too much.

I get the feeling you are trying to make something more generalised 
for the wider public.

Well, it is a "sideeffect" of TOOLBAR. I just found that it's a simple 
way to make button bars with right aligned buttons. OK-BAR and OK-CANCEL-BAR 
are even simpler. I do have my own system for requests, as I think 
the ones that are built in are too ugly and simple, but I'm not sure 
if they are general enough for publication.

http://hmkdesign.dk/shop9.png<--- This kind of requesters.

Ok, TOOLBAR is based on VID-FACE, so let's first check if it has 
a words dialect.
	>> print mold svv/vid-styles/face/words
	none
Good, so we can set our own without breaking anything.
	toolbar: FACE with [
		; define DATA function in the style-specific dialect

  words: compose [data (func [new args][new/data: args/2 next args])]
	]

All this does is allow a slightly easier spec. Your example from 
the blog:
	view layout [button-bar with [data: [ok-btn cancel-btn]]] 
can now be:
	view layout [button-bar data:[ok-btn cancel-btn]]

Ok, it doesn't save you much in this one example, but over time, 
it will.

Sorry, correcting that last example:
can now be:
	view layout [ button-bar data [ok-btn cancel-btn] ]

oh, thanks for that one. I've been wondering for a while how to do 
that. :-)

I want that in LIST-VIEW as well

The words dialect is not terribly obvious how it works, because it 
advances the index of ARGS by one for you. You still have to remember 
to advance by one for every argument that you understand and consume.

maybe one should make a document on that...

Good idea.