World: r3wp

Or am I missing something?

try this:

load-gui
stylize [red-button: button [facets: [area-color: red]]]
view [
	red-button
	button options [area-color: green]
	button
]

I think this wirks just fine no?

The faced block is similar to facets block, but makes them local 
to each instance of the face. Now, they can be modified without effecting 
any other faces that are of the same circle style.
 It is taken from: http://www.rebol.com/r3/docs/gui/styles.html

Why Carl introduced it then?

In fact this never worked correctly in the old Carls version IIRC.

In our version FACETS are 'local' to each face instance. To use shared 
properties(among the instances) you can specify INTERN block in the 
style definition.

OK - so - is there a need to distinguis local vs global style settings? 
Because in fact, I think that pushing user to use make edge [] just 
to prevent sharing, was pretty much crap in R2. That should be avoided 
if possible, as it creates burden on a user to know, that subobjects 
are shared in REBOL.

what's intern?

OK, I will try new version, and see how it goes. I would welcome 
an example on 'intern, maybe I will find it in sources. Starting 
to warm-up to new gui :-)

As I said you can use the INTERN to store shared (static) variables 
among all face instances of the specific style.

faced/facets, I like that it's gone. I never really learned what 
the difference was. That introduces sloppy coding, when you don't 
realize it.

Henrik - then you never read docs :-) Old docs are removed from wiki, 
but when I first saw faced, I reacted like most ppl - what is that 
good for? Then I read an explanation, and the difference was very 
obvious to me ....

Cyphre - any quick example of inteern? Just:

intern: [area-color: red] ???

I also remember the discussion with Carl, if we should change naming 
- e.g. attributes (attr to be shorter), local, global ... and in 
the end I liked faced :-) I can live with intern - it just reverses 
the aproach - it creates all facets instance-local by default, and 
shared stuff should be stated explicitly, right? It just might mean 
more memory consumption, but I don't know how much :-)

yes, that is enough...then every face of the style will be access 
face/intern/area-color as shared value

(but this will be used mostly by internal style code, that's why 
we called it INTERN)

ok, then I like new aproach more ...

BTW what was the difference if you had:
faced: [area-color: red] ?


In the end the 'area-color was local to each style as well in face/facets. 
In Rebol you cannnot have mixed 'shared' and 'local' values of direct 
type in one object together.

(the only way how to make 'shared' values is using indirect values 
(object! string! binary! block! etc.)

I think that the difference would exist in the dialect translation 
phase, when new style is instantiated? If there is 'faced, it would 
be in object field, whereas where in facets, it would be in some 
subobject = shared.Well,but then I don't know, how accessor would 
look-up style attributes, if those would exist in two places, but 
you have to somehow solve it with 'intern too ...

Don't loose your time with further explanations, time to read sources 
and do few tests ... some things will become obvious, some not, and 
then I''ll ask ...

From our expereinece with R3GUI styles, properties that user should 
easily access (like colors etc.) are meant to be usually local to 
each face inastance. That's for what FACES are good enough. If style 
creator think he could 'save' some memory by using shared values 
among faces of the style then he(she) can use the INTERN 'shared 
context' as storage.

BTW how is the R3GUI demo conversion is going? ;)

not going at all - coming home from work at 19:00 and later :-) First 
thing I want to try is trying to play with different draw blocks 
:-) E.g. trying to "port" Carl's button :-)

playing with draw blocks? - I thought that's a task for your dog 
:-)

exactly - Charlie is going to be here too :-)

Simply put - it is supposed to be a fun. We (rebol community) forgot 
about the fun a long time ago :-) I looked in some R2 demos, and 
was amazed - we need new demo contest, and the condition is simple 
- R3 only :-)

Any tip of how to play with gradients, trying to simulate some existing 
ones? IIRC, there was some R2 script? In the end I would like to 
mimick my HTC sense environment, as I like it and it looks decent, 
albeit maybe too white - http://204.145.67.138/shared/ScreenShots.png

got to go, later ...

Oldes, you have to reload, for new stuff to appear on the website. 
I noticed also some docs are released (resizing). What about publishing 
even doc, which is in WIP format included in the archive? Well, but 
that would probably mean maintaining two versions - MDP one, plus 
WIP for rebol.com ...

We are working on it.

OK, good to hear. OTOH - what is the stage of acceptance of RMA's 
stuff into official RT distro? Any discussions with Carl yet? I know 
that you will continue working on your version anyway, just curious 
....

No action so far.

Question towards style tagging. I noticed some styles are tagged 
as 'internal, and some as 'compound. I would like to know, if it 
serves any other purpose, than for style listing/grouping, to distinguish 
it? 'Internal is probably just a tag, but does 'compound has any 
meaning further down in the code?

they are opposites. a 'compound style may not necessarily be 'internal, 
but may consist of 'internal faces. an 'internal face can be 'compound, 
but is not necessarily that.

And, the tag system is generic to flag styles as necessary.

That one looks weird :-)

styl: guie/styles/:style

Styl
 is czech translation of english "style" :-)

I can see you use empty rows to separate some items in facets block. 
Why is that? I did not find any example of 'internt being used, so 
I think that might be the reason? To simply separate/group some items? 
Aren't we wasting memory here?

Doc style is buggy - doubles the content:

view [doc "test"]

I am still not sure I am comfort with group having different semantics 
to panel :-( .... trying to do some tests with Carl's demo, and it 
is going to be pain-in-the a..., to insert returns in there. From 
the very beginning of the R3 GUI projects my opinion was, that group 
should be just de-stylised panel (no visual borders), but identical 
in behaviour ...

I hope I will change my mind later in the proces ....

Hmm, but then we would probably loose flexibility of different layout 
model if those two were identical ...

rendering/refresh bug -  view [vpanel [text "test"]] ... I can see 
the content of underlying window next to the vpanel ....

I can see, that along the min-size, max-size parameters, we can now 
set init-size parameter. Why was option to set max-size removed from 
panel? Because resizing system does take care for that? I also noticed, 
that make-panel can't anymore accept options block. So you found 
it not being necessary?

btw Pekr, from an API designer's standpoint, these types of questions 
are all very good  IMHO.  they force us to reflect on decisions and, 
often, trying to do so will either confirm them or with discussion 
might give new ideas.   I'm not part of this gui team, but I'd really 
like if someone asked pointy questions like this on my stuff.

(I'd really like == I really like it)

those come from concrete effort to make Carl's demo translated to 
the new GUI engine  :-) First and second screen is displayed, but 
make-panel just differs, and options argument does not exist anymore, 
it also has reverse order of arguments, and does not accept style, 
but face instead, and so on ...

are you supposed to use make-panel?

Henrik, when switching panels, there's following function I need 
to adapt:

	unless pan [
		pan: make-panel 'group pick test-blocks index [columns: 1]
		poke test-panels index pan
	]

1) make-panel does not accept third options argument anymore
2) the first two args are reversed

3) make-panel does not accept block (style) anymore, but a face object 
- I don't know how to do this one yet ...

I simply need to make a block with layout elements a face. Trying 
with make-face, but make-face accepts two arguments - style name, 
and options, I don't know what should I submit for the name ...