World: r3wp

umm..

Anyway, let's not argue about this here; we could discuss this all 
night. :) I would much prefer people to talk about the iterated buttons. 
:)

i prefer not to have version-conflicts. changed something in cache, 
worked on another computer, had same (old file) there and nearly 
uploaded that. no problem when cache is cleard first.

They have to get them first painless! But you are right. :)

I understand, really I do. :)

I'm working so hard to solve all these things...!

What I need, to continue with shell-list, is some extra hooks in 
the View system. I need to be able to hook each call to feel/redraw. 
This means a hook in SHOW and probably other places too.

I might also need access to view system's internal "timer-list" - 
this is the list of faces with rates which need time events sent. 
I at least need to know when this list changes, which as far as I 
know only happens when SHOW is called.

tSoo, what are we talking now, except of "Hey, it works"? :)

WIll that be part of rebols opensourcing?

Due to this project, I would *LOVE* to see what SHOW is doing.

Yes, the demo is not very impressive looking, I admit. There are 
no flashing lights or fancy graphics.

(though I can easily add some interesting variations for each iteration.)

It doesn' t look any different from a window with some normal buttons 
or toggles in it.

But, in a way, that's the point. You, the user of shell-list, should 
not have to care at all what you throw into the iterated-layout. 
It should just work as it would inside a normal layout. That's the 
beauty. The buttons look and interact like normal buttons.

Oops, did not mean "impressive".

argh. Meant my comment was not about "not impressive".

no offence

More, what do we do with it now? About using it, building demos, 
maybe 10000 buttons in a row or such things. Where doyou want to 
go with us?

I guess it would be a good base for a spreadsheet?

where faces are to expensive when it gets big.

Good question. The idea of shell-list is to make things simpler. 
It should be *easy* to make lists of things.
Why do I publish it now, when it's still in such an early stage ?

I guess I am hoping for a bit of attention. I will need some changes 
to the View system or it will not be able to work perfectly. Right 
now seems not a good time with rebcode just released, but this seems 
so fundamental to user interfaces to me I think it's more important. 
Everything always seems to lead back to the list.

Maybe right time. rebcode goes speed, iterated lists goes memory.

Maybe it could also help with this half-implemented set-face/get-face 
of panels? saving and reloading the displayed contents?

I'm not sure about that.

Although, maybe it could. The facets I have discovered (and will 
continue to discover) which are used in shell-list ("default-iterates" 
block), could be used for set-face/get-face of panels.

Maybe we could have some face-dialect?
 get-set: [/auto text data /explicit color [set-code][get-code]

for use where ?

to declare the related facets in style.

if some facet is calculated, it could declare that in the /explicet-part. 
but maybe to complex.

You mean when using set-face/get-face ?

yes. and i guess your list-filling does something similar, to save/restore 
facets?

I thought about this pretty hard for shell-list.

save/restore-iterates ("iterates" is my word for "iterated facets") 
remain simple at this stage - they use only GET and SET at present.

You are right, that is faster.

shell-list allows functions to be placed in the map dialect block, 
which is kind of like your /explicit refinement above. The automatic 
iterates are found in the default-iterates block.

Volker: funny about get-set you know. Some time ago I objected, that 
'get-face, 'set-face should be made more general and accept additional 
parameter, so that you would simply use parameter name to set it, 
so e.g. set-face 'color value .... etc.

and some ppl objected that going such way would complicate the thing 
and that we would ended like VB, Delphi or other tools with tonnes 
of parameters to set. I still think that current version of set-face, 
get-face is not thought out properly!

I think thare are two slightly different goals. One is to deal with 
the main data in a face. That should be a single value. The other 
is to make a snapshot of a layout, save it, qui script, and reload 
it later. I like that behavior. And i am not sure a single value 
is sufficient for that. But it would be an internal thing about saving, 
as api i prefer something with more defaults, ala VID.

I would prefer SET-FACE, GET-FACE to be named SET-VALUE, GET-VALUE. 
Cause in fact, it's what id does :

But set-value and get-value are too generic names to be restricted 
to face accessors.

correct me if I'm wrong, but I seem to remember that VIEW can set 
a minimum size a window can have using /options 'RESIZE ?

'minsize ?

it seems to respond to 'min-size but won't accept a pair! value...

view/options layout [ size 200x200 title "test" ] [resize min-size 
100x100]

interesting... thanks. Is this in the docs anywhere?

dont know. remember it from some chat. :)

why of course :-) I can't even see it in '? view'

one would think it's a pretty important feature

put in RAMBO?

Thought that too.

I'm putting it in... can't see it there