World: r3wp

... and which is on hold because I wanted to use shell-list for it.....

simplest way: have a clear-my-site. then all downloads are fresh.

I could do stuff like that, but I am a perfectionist, reluctant to 
admit there might be a simple way that's good enough for now. But 
I'm coming round... :)

Just sharing my latest experience :)

My original thought process was that I don't want to automate the 
deleting of files in the cache, on my computer or someone else's. 
I think if the user wants to delete their files, they should do it 
themselves. I don't want to get involved in any data loss.

So I thought it preferable to do an intelligent update. But for that 
I need an intelligent interface... -> shell-list.

Shell-list is designed to be highly flexible and configurable, for 
maximum code re-use. I didn't like the thought of writing a new custom 
list for every program.

I use cache more like, uhm, cache now. like a browser. before leaving 
data is cleared.

advantage, besides simple: I have only the used files in cache. and 
since i can upload too by a filerequester, having only used files 
there helps.

Note to everyone: shell-list is nowhere near finished, but the hook 
system I use to iterate those styles is so significant to me I have 
to make a demo of it.

except for large files, i have to do some "dont-delete" for them.

Mmm... in practice it may work ok, your system. But it begins to 
make unclear to the user what is in his computer.

everything since last deletetion? or the "keep big files"?

I would like, when I get some of Volker's files, that they stay where 
they are, not disappear sometimes.

then dont clear the cache. and they are on the website for redownload.

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!