World: r3wp

http://www.rebol.com/r3/docs/gui/styles.html

If you keep everything inside the style, it's hard to create a skinning 
system.

No, it is not, why it should be?

because that means you have to create entirely new styles with every 
new skin.

1) Anyone yet has to prove to me, that having centralised skin/material 
storage will be practically usefull. What tool on Earth will you 
use to visually edit them? Imo none - we will have to come up with 
own REBOL based tool, which might understand all those draw defnitions 
imo


2) Having materials stored in the style (being part of stylize) means 
you can internally do whatever you want with it. In fact - what material 
system does in on-init style phase is, that it physically stores 
the material object into face/material. You could work even the opposite 
way - knowing the list of styles, you can collect all materials, 
if you need them to have in one place - what for, I don't know, maybe 
for some visual tool, where you will be able to tweak them ... one 
day ... maybe ... as surely Photoshop is not usable ...


The fact is, that having materials stored centrally is correct design-wise. 
But having to deal with styles, and based upon practical merits, 
having definitions scattered around lowers usability of the system, 
and easiness of understanding of system internals ...

ad 1) if the styles are draw blocks, no tool will understand them 
no matter if there's centralized storage or not.

Rebolek - yes, and that is why I prefer things having in one file 
per style ....

Do you prefer using images in buttons? Patching current buttons to 
use images instead of draw blocks isn't that hard.

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.