World: r3wp

In that field, if you press backspace, do you get a crash?

only 3 styles are written for material system so far

And plese - tell me if you are interested in such hints, as it might 
get you nervous :-) We like pre-releases, but so far my feeling is 
- Gabs VID3 was able to show us Image Lab demo - resizing IIRC, drag 
and drop, alpha channels, changing mouse pointer ... then came the 
VID3.4 from Carl, it felt lightweight, but did 70% of Gabs VID? And 
now we are seing some XY percent of functionality of Carl's VID :-) 
I just hope it' still just work-in-progress, but I really wonder 
if stuff like validation is important now, in a state where there 
is very few usefull styles?

Henrik - dunno what you mean by crash - but no, R3 console does not 
crash, but I get rebol level crash:

handler added
** Script error: cannot use pick on none! value

** Where: second all resize-text-face remove-text-face switch either 
do-text-key

 if actor all do-style until either do-event do-event either applier 
 wake-up loo
p applier wait do-events if view

** Near: second get-facet face 'viewport-size tgob/size/x: face/facet...

>>

(that was caused by pressing the back-space in a field widget ....

Petr, as said: We release our stuff, it's early work and it's not 
of much use yet. But we still do it.

... but maybe I should use some precompiled R3 executable, to aviod 
possible wrong settings of my enviroment? But  - I have not found 
any in the link posted here ...

Pekr, it's ok, keep posting bugs.

As long as we don't explicitly state: Please give it a try and provide 
us feedback on A, B and C things might not work at all. you can give 
feedback but don't expect that we always care about it.

Cyphre says the bug is due to a missing box model. Will be fixed 
soon.

This is all in high flux at the moment.

ok, whatever the box model means in new gui :-)

Robert - this is OK with me. In the past, I worked with Cyphre, Romano, 
to do personal testing ... lot's of errors and misconceptions caught 
on my side. In such early phase, I might cause a flood, so if you 
want, I might stop for few more releases ...

It is just there is not much to test, if there is only 'check working 
so far for me :-)

I simply tried to go via http://www.rebol.com/r3/docs/gui/guide.html
, and to test those examples ...

so - if anyone wants - Cyphre, Rebolek, I can test privately in early 
phase, and report privately too, to not cause much of the flood here 
.... or I can simply shut-up for a while :-)

You can? ;-)

It depends ... upon what you want :-) If you want misconceptions 
or bugs reported, and you are releasing in early stage of development, 
you have to take the consequences. The same goes for us - everybody 
wants early releases, but then we complain, that released stuff is 
not of much use :-)

and the solution to this problem is... ? :)

there is no solution :-)

A106, text-test3.r - when I position caret to the last position:


** Script error: caret-to-offset does not allow word! for its position 
argument

** Where: print switch handler while applier wake-up loop applier 
wait do-events
 if view catch either either applier do
** Near: print [
    "otc:" mold otc: offset-to-caret gobt event/offs...

btw - is there any reason, why 'move events are generated, even if 
there is no mouse movement? Referring to text-tes3.r for example 
...

With a107 (that I build with the MS compiler), go.r3 seems to run 
quickly when launched, but slows down dramatically after just a little 
bit of mouse movement. If I stop moving, the speed resumes after 
a little while. I don't remember seeing this in older builds. Has 
something changed wrt event processing?

Works for me.

Are we tracking R3GUI errors anywhere??

Try this 

 view  [ button "" ]

** Script error: path styl/faced is not valid for none! type
** Where: make make-face make-panel make-window-panel case view
** Near: make guie/face [
    options: opts
    facets: make styl/fac...

no one answered my call for more versions in curecode

no A107 yet?

No one is home today

Hm, seems someone (I guess Brian) added A107 to curecode already.

Is BrianH the only person who has access?

I am one of the admins on R3's CureCode instance, but not the only 
one.

who else ?

I guess I'll add the issues above to CureCode - not sure that anyone 
will look at GUI issues though since it's known to be in flux - and 
Henrik's probably already modified the source enough that this couldn't 
be replicated

added as issue #1648
http://curecode.org/rebol3/ticket.rsp?id=1648

Graham, can you add the last issue you noted above? My browser is 
running like molasses for some reason and I have to get going.

sure ..

something wrong with CC

you don't get the error I noted above when you do the following?
view [ button "" ]

Hum... It's not my problem currently. What is the hosting address 
?

Adrian, this is using a core without r3gui compiled in and just run 
normally

i see that some people recommend that your GUi should run in a separate 
thread from the rest of your application so that while's it's busy 
doing things, the GUI still remains responsive.  How can we apply 
that to R3?

I suppose the event model that Carl talked briefly about could rectify 
that, so there would not be a need for threading.

can anyone explain why there is a 'MOVE event every second when we 
have a gob! window open...  ?


I'm guessing its for blinking type handling.... but it should have 
its own type.  This also occured in R2 and its extremely annoying 
when handling events.

is the gob/image parameter supported in A107?  I can't seem to make 
it work...

gmask: make gob! [image: bmask]
gmask/offset: 30x0
gmask/image: bmask
probe type? bmask
probe gmask

== image!
== make gob! [offset: 30x0 size: 60x60 alpha: 0 image: none]

weird.  maybe the image gob type has been dropped?

Maxim, I have no idea whether it's related, but there is currently 
an issue with TO-IMAGE.

box clipping of gobs is making them harder to use than they should 
for general graphics use when gobs are nested into panes. 

it would be nice to be able to support a clip? parameter.


for example, it would be nice to be able to use 0x0 as the origin 
in which to draw (so that negative offset values be used in the draw 
block), but we can't unless we always add a transform to the draw, 
which has to managed along with the size at any change in size.


go three pane deep, and we have to manage all the hierarchy all the 
time its pretty complicated for nothing.  


pane grouping should allow them to be used, just for transform, not 
only for visibility.

henrik, ok, in any case, we can use them within a draw block, which 
isn't that hard to do anyways... in the meanwhile