World: r3wp

... after all, IIRC Carl once said that current 'list was done in 
something like 5 minutes or so beofre View alpha release :-), and 
IOS 1.3 project contained new, improved version - so I also wonder 
why that version did not make it for 1.3

Or, you could just read the documentation regarding the use of 'list

fields? Why? Where? I am able to use fields mostly without such hacks 
...

I start to think that some ppl fail to admit something could be just 
done better, even if style creator admits it :-)

Is your complaint then one of a lack of documentation?

We had such discussion before, do you remember? Many ppl arguing 
with Terry, that basically rebol draw is capable to compete with 
Flash and nowadays we are all applauding AGG inclusion :-) I just 
try to point out to things I don't like and I try to believe that 
my pressure may lead to think out some things more deeply for 1.4 
release ...

So that we don't have this discussion again, why don't you draw up 
a critique of what you feel is bad design regarding 1.3, and then 
we can work from there?

It's hard for all of us to start from the same point unless all of 
us remember past discussions.  So, let's have a summary document.

Yes, maybe documentation. But I can still see a trouble with 'list 
and if 'field is similar, than our bad. VID is abstraction. It was 
meant to ignore errors in code if possible. It was meant to configure 
style using facets ... we started to expose more facets 'edge ,'font-size, 
etc., and if not sufficient, the last part is using 'with and directly 
accessing object values. But 'list goes even further, as 'supply 
block deal with variables like 'count ...

Graham - why? My RAMBO report regarding non working button in some 
case was dismissed - so - no bug ... I just fear that we will have 
to document well all such "exceptions"/"by-designs", call it whatever 
...

Why? To communicate of course.  To persuade at best.

RT has a small habit of changing their minds.

Graham - and besides that - we don't know the plan, do we? It is 
difficult to work/cooperate, as RT choosed the way when design is 
done by few ppl. It is good on one hand, as work is being finally 
done and we have got 1.3 out fast enough, but no docs follow, no 
plans follow. I e.g. asked someone from RT's extended team describe 
proper behavior of Installer, to actually test what is desired and 
what is not. But I can imagine docs are always lower priority, it 
is simply natural. But - I would really like to know, what goes for 
VID 1.4 or 1.3.x, whatever - only styles additions? What will happen 
to focus system, how will accessors be utilised, the same for doc 
subobject, what happens to VID in general?  - btn uses bitmap, but 
we've got powerfull AGG inside. Also - how will effects be merged 
with draw? We want to keep compatibility on one hand, but surely 
we don't want to have powerfull gradients withing draw, and old-ones 
within effect block ... So - don't ask me - I would expect some developers 
oriented document, short description of what and how is gonna be 
solved. Don't forget that it seems text mark-up is gonna be introduced 
- so - many changes, in hundreds of possible ways - so I will not 
propose conrete solution, if I know nothing about more general plan 
...

You don't have to know what is planned... only need to document inconsistencies, 
or bad design as you see them.

If Cyphre is working for RT, and his list is not included in 1.3, 
presumably he knows the reasons ...

his list is not list, it is full featured grid and it needs additional 
work ...

I don't want to sound harsh, but I start to see RebGUI as more consistent 
by design. It surely does not allow some things, but ...

but well, if I am alone seeing some things as kidn of problematic, 
it is not worth to document imo. I am not good in VID nor View, so 
my impression is, that if many other ppl see no problems with things 
how they are, then I must be wrong ...

Or, other people just give up before they get to be good in Vid, 
or view ?

Pekr, Docs are being worked on. VID update is also in the plan, SDK, 
other platforms etc There is a lot of work being done. Some of this 
is sequential some is in parallel.

http://www.compkarori.com/vanilla/display/list+examples


Here is documented the face, count and index variables.  There are 
similar functions throughout VID.

Allen, are you in the know somehow?

Yes. But a lot of this was stated when the journey towards 1.3 started, 
http://www.rebol.net/article/0161.html

Perhaps it is time to consider a VID community documentation project 
?

Allen - there is particularly nothing interesting or usefull in above 
link ...

... in regards towards 1.4 ....

Possbily timing for the doc collab project is when REBOL/Coop arrives 
http://www.rebol.net/article/0146.html.

The rebolfrance rebol dictionary is a good example of community documentation

Really Pekr? To me it says what order things are going to happen 
and what is planned around & after 1.3 release.

except OSX appears to the left of 1.3 in the diagram :)

not in diagram but is in text. ie changes required for OSX

That roadmap really needs updating. Public works under construction 
can really get you lost.

But at least now, we as a community focus again on what needs to 
fixed in VID rather than native issues (and all the other bugs that 
got taken care of) This is a good thing.. If we are complaining about 
VID again, I think that is a sign that 1.3 has helped move us forward. 
And there is nothing in VID that can't be changed or replaced by 
something else as REBGui shows us.

Now that's the sign of a mature software project :)

You're finished with the new thing when people go back to complaining 
about the old things again ;)

I hope we are not complaining about VID believing that Rebgui has 
stalled !

I don't think anybody has been as organised or determined as Ashley.

it will be great if RT is ok to start a VID upgrade to show world 
how rebol is great and simple to use and progam.

work of Ashley and Shadwolf and (Cyphre) are great on RebGui.

It has always been possible to do it either, using the Face and writing 
from scratch, or else use style extension method in VID. Lack of 
docs probably meant few knew how.

it will be good for rebol and RT to have a link page on REBOL.COM 
to project like RebGui.

sugguest that in feedback

RT give us the eart but we need arms and legs to run to success ;-)

In the early days I wrote a few simple styles extensions as examples, 
and then doc brought his Win95 styles and then Ettiene came out with 
his style set. It really seemed like everyone understood how extensible 
it was.

Then it seemed we had too many choices, and we needed an official 
release that wrapped up some of these great new styles. This is where 
it fell apart I think, when this didn't happen and that momentum 
was lost.

Pekr: about dirty-flag: thats a cool trick for quick formulars. you 
put things in a layout with 
   field my-string [ my-string: face/text ]

and now you never have to worry aout saving face-content: when user 
changes field and leaves it (clicks outside), the action is called 
and 'my-string updated (or the database or whatever you do in the 
action). 

That storing happens only if /dirty? is set, else there is no change, 
so no store.

The problem with your code is, usually both happens, first field 
is stored, then the button. So field should be stored, then your 
quit-button called. You managed to write code which somehow forgets 
to call the quit-button. Somehow you confuse rebol by changing layout 
in field-action and focusing. That it gets confused is the problem/bug 
IMHO.

about list, thats a complicated issue IMHO, because list is heavily 
optimized to show very big lists with good performance and low memory 
use. Thats done by a trick (iterated faces). And that trick is hard 
to wrap in a generic way. 

The other option is to do it trickless, means put all in a big layout, 
one face for each row. thats like conference/messenger/altme do it. 
not that performant (all this programs restrict the number of messages, 
only the last n). but to do it, you only have to append vid-code 
like
 text (name) 100 text  (msg) 300 text (date) 100

for each line and layout that. most flexible way, you can even edit 
each field. but don't come back and tell me its hungry/slow! then 
you have to use that index count list - stuff, maybe somewhat better 
wrapped.

btw, how about putting some of the old view1.3 -project on rebol.org? 
specially Carls improved lists?

having the liberty of on your ideas is the true LUXE

Volker: but Cyphre, with his my-list, can display millions of records, 
as it uses caching, yet it does not suffer from 'supply problem I 
outlined. And btw - interesting point towards 'list. I wonder what 
was the reason Carl did not put his improved list into 1.3? It was 
created in older 1.3 project days, along with chech-line, radion-line, 
which are inside, newer list is not. It seemed to me as tested, improved, 
 compatible, so worth inclusion at least ...