World: r3wp

Even current source distribution is wrong for me. What would be cool 
would be system internal functions being separate. And all particular 
style functions being part of the style itself.

Images? No. I talk about logic of how things are organised.

And all particular style functions being part of the style itself
 - what exactly do you mean?

I mean - there is an engine. And then there are styles. My idea (maybe 
wrong :-) is, to have one file per style, containing everything style 
related. Or at least having max 2 files. panel.r3, panel-funcs.r3. 
I just don't know - looking into style definitions is a disappointment 
for me - there is only few basic things, and there should/could be 
more. First things which come in my mind is materials, then options 
block handling, and I can imagine even functions: [] slot, where 
all related functions could be put.


I'll leave it where it is now, before the system is more complete. 
But later on, if I have a feeling, that there is some usability problem 
for users, I'll restructure the system myself.

looking into style definitions is a disappointment for me - there 
is only few basic things

 - isn't it good thing if you can write new style with changing just 
 few basic things without need for long code?

No, because it is not of course true. What you show to user inside 
of stylise, is only part of the style. For some styles, as shown 
in the above link, it might be true. But when you start to add things, 
you need to go outside the stylize, and I would like if stylize would 
be able to contain everything, having following slots:

style: [
    about:
    tags:
    facets:
    options:    
    actors:
    draw: 
    materials:
    funcs:
]

Plus the naming of inline options, options block, and style level 
facets vs options - http://curecode.org/rebol3/ticket.rsp?id=1847&cursor=7
should be resolved too ...

If I would not meet with Ladislav, I would not be able to find out, 
how are those things related. That is time-waster to anyone trying 
to study the system ...

it might be that I'm understanding it wrong, but do you simply want 
a MATERIAL word for the style? that seems to be the only difference.

Not exactly. Because in fact, there are both material, and materials 
words in the final face object. What I would like to see is the materil(s) 
word(s) for the style/stylize phase.

My idea is to have style "simulator", having just few named code 
areas, representing above post style: [ ......] structure. Then by 
protytyping, you would be able to develop full style, by putting 
code into particular slots. Well, that could be done even now, but 
I don't find a reason, why e.g. draw blocks, or actors are there, 
but code like options block handling, supporting functions, materials, 
are not part of the process ...

But I think that ideas for IDEs will come later. The system is still 
not complete.

I don't see a single reason why code like option block handling should 
be part of every style, it simply bind words from options to facets 
and one function does it for every style.

Petr, maybe it helps when you think about "programming in the large". 
I like self-contained stuff too. It's simple and fast to use. The 
problem is, it doesn't scale.

Imagine 20 customers, all wanting their own branded version etc. 
with an externalized material system you just link in a different 
setup code and you are done.

One rule we follow with the GUI is, that everything that provides 
"additional features" should be plug-in able. If you want to use 
it, you can include it and you won't notice an artifical break. If 
you don't need it, don't use it.

I don't see a single reason why code like option block handling should 
be part of every style, it simply bind words from options to facets 
and one function does it for every style.

 - Rebolek - what function is that? I found that e.g. for panel, it 
 seems to be an init-panel function, which maps options block to facets. 
 And no, it is not about simple binding, it does more than that.

Yes, it does more, but this is clearly not part of style but part 
of GUI system.

Styles should be easy to write, so the system should provide funcionality 
that can be used by style writers. Why would you want this functionality 
be part of every style instead?

Robert - my long time experience is, that code reuse is very often 
being a trade-off. I can't even imagine, how you make new material 
for your new customer. You don't have any visual tool for that anyway. 
And I am not sure if I can if it is in separate file, or with each 
style. I can understand the plug-in mechanism, but I am just right 
now not sure, if it outweights the usability aspect. I simply remember, 
that I liked to use the AMOS basic. Because it allowed cool things 
rather easily. And if users like the system they use, they will use 
it, and extend it. And sometimes it is about how cleverly the code 
is organised. We will see, how it turns out ...

Rebolek - no, because it IS NOT part of the system, but part of the 
style, can't you just see that?

I hated AMOS basic because of how system-unfriedly it was.

Imagine I am writing new style. How on earth I define, in stylize 
level, how is options block mapped to facets?

Show me other basic allowign rather easy animations, sound, and game 
creation :-)

blitz basic  ;-)

:)

Rebolek - to not be confused:

button 100x20 "OK" options [here is the options I talk about]

actually better in all regards  :-)  but it had all the OS friendliness

Max - a good one :-)

their cow and camper racing game was hilarious  :-D

How on earth I define, in stylize level, how is options block mapped 
to facets?


Why do you want to do that? Let's say I want to write KNOB style. 
I can set for example it's value, color and size, so options would 
be something like:

options: [
	level: [percent!]
	knob-color: [tuple!]

 knob-size: [integer!]	; it's round, so diameter is enough for size
]


Then I can use knob-color, knob-size... in draw block without any 
manual mapping.

You see, you have mess in naming, no wonder you don't know what I 
am talking about!

what mess?

Options you put here, are inline options, whereas what I am talking 
about is the options block from the dialect level, which maps to 
facets!

http://curecode.org/rebol3/ticket.rsp?id=1847&cursor=7

Uh oh, trying another way:

button "OK options [my-field: "test"]


Where is the 'my-field processed? That is the 'options I talk about, 
which I want added to stylize ...

And because style has 'options block, which maps to inlined parameters 
("OK" string in above example), what I am claiming is a name clash/confusion 
here ...

hence the ticket ...

I can rephrase the question - how does user define, creating a style, 
what might be declared in an options block (dialect level, my-field: 
"test"), and how is such options block being evaluated, and values 
being assigned to facets?

Pekr, values that are specifiedin OPTIONS field in layout by user 
are set in the face/facets context.

Let's assume I set button in bounds (between what min-size/max-size 
allows): I tried various scenarios, and I almost never got button 
of requested size.

 - yes, the size is always a result of resizing rules, as applied 
 in a specific style. There are two methods working quite differently, 
 the first one is used by vgroup/hgroup, the second one by vpanel/hpanel. 
 If none is what you like, then there is a possibility, that you would 
 like to have a completely different style, with different resizing 
 rules...

If you really want to have a completely different style, with different 
resizing rules, you should carefully write down your requirements/ideas 
so, that it would be clear how it would work.

- In regards to above point, I really wonder, if buttons should be 
resizable at all. I said - resizable, not settable. I wonder, if 
I would like buttons to be of consistent size. I might try with face/resizes?: 
false, if that would make the trick.

 If you set the RESIZES attribute to OFF, you get a completely different 
 behaviour, than what you expect:


- the resizing algorithm will leave the button untouched, which means, 
that it does neither compute the position, nor the size, and the 
button would just "float" - the next version will contain more than 
20 different examples, Cyphre's visibility example manipulating the 
RESIZES attribute included


- if you just want the resizing algorithm to not change the size 
of an element, while allowing the resizing algorithm to compute the 
position of the element, you should do it differently. Just set the 
INIT-SIZE, MIN-SIZE and MAX-SIZE of the element all to the same pair. 
You will notice, that the size of the element will not change, no 
matter what, only the position may change.

Pekr, regarding your OPTIONS vs. FACETS naming. I don't see any problem 
here. It's normal, especially in Rebol, that  word symbols can be 
used differently in different contexts:
in style context - the OPTIONS means 'inline options'
in layout context - the OPTIONS means 'face options'

Also from the beginner POV...it is easier to understand word OPTIONS 
in the layout dialect than FACETS no?

Ladislav - I might wait for examples, but - what is the main difference 
between - floating vs computing the position of the element? I somehow 
can't imagine it. Will it be shown in the examples?

Cyphre - what you just said says it all. I don't care for different 
context and word meaning, if those contexts are so close one to each 
other, that it might confuss users :-)

yes, you shall find out, in general, "floating" means - the resizing 
algorithm influences neither the size nor the position in any way, 
i.e. the element "floats unnoticed by the resizing algorithm"

I think I understand the difference, but I was not easily able to 
see what is what, unless I studied it more deeply, and unless Ladislav 
told me during our meeting, that layout level 'options does not necessarily 
directly map to face/facets ....

aha, so floating might mean, that the elemetns xy offset stays the 
same, so that e.g. button stay upon the area, or something like that? 
Is that usefull? :-)

Yes.