World: r3wp

(this is on a window not using r3-gui, btw)

hmmm... I'm not sure yet. the closest thing is probably IMAGE or 
DRAW faces.

view is probably broken with non-standard windows. I made a few changes 
in it to make it work properly, but it could use a rewrite.

it could be nice to add a simple style called gob, which just uses 
a gob! as its setup data


basically, it would be a static gob, which only displays itself, 
doesn't resize or just doesn't respond to the resize re/actors.


this would allow integration of different graphics tools which weren't 
setup using r3gui.

just a thought.

I'll pass this on (if it's not already in there)

thxs


are the online docs usable for style definition or has it changed 
so much that there's no point in trying to make a custom style right 
now?

new build is up with uncompressed source:

http://rebol.hmkdesign.dk/files/r3/gui/r3-gui.r3

oh cool!

please download to local disk

style building has only changed with regards to resizing (which I 
haven't entirely figured out yet), but otherwise remains the same, 
so feel free to build some styles.

later, Cyphre will come up with some modifications to draw blocks 
for styles, so we can use positional keywords that work together 
with the box model, so it becomes easier to create draw blocks.

ah there is a box style I can easily use.

thanxs for all.

ok, cool

hum... using stylize doesn't seem to add to the global style sheet... 
is there a function to call first to setup or assign to a specific 
stylesheet?

such as to replicate stylize/master   in R2..

it should do that. it's a bug if it doesn't.

DOH!.... it would help if i used stylize  BEFORE  I use view   ;-)

seems to work now.  :-)

ok :-)

btw, I'm working on fixing the as-is event handler issue I found 
earlier...

is it normal that (out of the box) there is nothing happening to 
controls when I press on the mouse?

if you don't add any reactors, then I think so, yes.

you mean.. buttons don't click (visually) unless I add an action 
to them?

cause right now, the gui looks totally dead a part for the fact that 
it resizes (though its late by one window resize event.)

ah wait... its my fault.

oh, that's because the materials are not defined for click actions.

since it's a temporary skin to test the materials system

ok, I removed the hack which I had in place.

ah ok

the materials system specifically maps various surface appearances 
to the face states. perhaps it needs to be refined as I haven't looked 
at it in two years, but the intent is to do this in the material 
specification instead of inside the style. so you say "I want material 
X" and then all variants of it are used in the style.

yeah, sensible.

does the material support some sort of accumulation?

a very loose example

I want gui in style dark
I want aluminium

the issue here being that dark is not a value but a process.

so you get dark aluminium ?

you select aluminium as material and some dark color to get dark 
aluminium

ah ok, so it doesn't accumulate the materials.  since color is a 
property, not a process.  here dark is a concept... 

which might ultimately apply to all styles, but which isn't resolved 
by the aluminium, but by dark itself...


it was just a question, I wasn't expecting a yes ... its a very advanced 
shading (are rare, and complex) process.

(its definitely not a limitation on the part of the engine, for those 
who might mis-interpret my question)

you can have a look at the materials section to see the specs for 
a material

yeah I did briefly.. but there is a lot of code to sift through... 
it is 216 kb after all  (which is pretty lean for a GUI complete 
engine ;-)

There are two primitive formulas used to create a simple specular, 
but one is broken. I'm terrible at that kind of math, so maybe they 
should be revised. I could use some help in creating a designer friendly 
few speculars that emulate brushed metal, plastic, glossy, glass, 
etc.

I'm still trying to resolve the as-is handler bug... getting closer.. 
now it doesn't crash, but it doesn't use my handler neither.

yeah, without some support libs, designing shader stuff from scratch 
is hairy at best...


the only help I can give you is to use light energy-based math instead 
of color math.  I've seen some VFX compositing tricks where  you 
can simulate this by scaling colors with a gamma of 2 blending your 
colors and then applying the inverse gamma of 0.5.  the way the colors 
will merge usually provides better results, but still doesn't clip.


the idea here being that the gray areas won't merge the same way 
as low and high-color areas... might be usefull to play around with 
gamma in the draw block too... though I'm not totally sure how it 
all works in agg.

shaders must be very simple for speed. I'm not so terribly interested 
in actual realism, just a way to map a linear value to a specular 
value, which then gets tinted with a color.

Henrik, why not just put the gui on devbase ?

and then you won't have to worry about your bandwidth

these are my private builds and they will not come in a regular frequency 
yet.

ah think I found the handler problem.


view's awake function now calls the do-event (it used to be handler).


so its just an adjustment to any code running after it loaded r3-gui.

Henrik - how is that you did not look into material for two years? 
I have bad feeling this whole project is driven very chaotically 
...

Pekr, wasn't going to be used until we started skinning.

how do we get time events in r3?

answer, look in the HK and see commented timer lines  ;-)>

I would suggest that the difference is the spacing that is provided 
around the check-boxes and the buttons is consistant and the group 
boxes properly surround the objects.

Pekr:  I had a contact who worked for Adobe and was a gui designer 
on many of their applications.  He is now an indepent contractor, 
but now that he's contracting he's enjoying his time to be with his 
family.  Adobe worked him hard for many years.  So, unfortunately 
he is not available to help out.