World: r3wp

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 ...

Allen - I talk about precise plan for 1.4 - so really - genear info 
of "Yes, 1.4 will come after 1.3" somehow does not help here :-) 
I talk about details, simply kind of resurrection of older 1.3 project 
days, where we held talks about VID, each style etc. And it can get 
pretty tricky. You remember? We had problems to agree upon new button 
:-) The worst thing is - we have to keep backwards compatibility 
in mind :-(, so projects like RebGUI have some advantage here, starting 
from scratch. I e.g. wanted area having automatic scrolliers, but 
Carl did not agree because of compatibility ....

So - I can understand not every wish will get on-board even for 1.4, 
but we should start talking about - what next - focusing, missing 
styles, general VID design etc.

... what is more - more kernel changes will come - AGG, effect block 
vs draw effects, possibly compositing based upon AGG (new in AGG), 
fonts etc.

Volker - thanks for 'dirty explanation. It seems to be handy. But 
- does 'dirty work for other elements too, as e.g. check-box? In 
old x-base days, we used to use scatter and gather methods. So, if 
'dirty flag solves just fields, it shows incompetence of designer 
imo ;-), such thing should be done via accessor functions - set-face, 
get-face, which eventually can even format output, e.g. in the case 
of radio button to translate into some other value. Robert with Cyphre 
e.g. defined "form dialect" for Robert's private IOS effort. Did 
not see it in action, but probably it tried to solve things in more 
general way.

So - stating that - I would really appreciate such things to be documented 
or at least discussed. If we start to add such things into VID, it 
should be agreed upon by more wider audience. I e.g. have rather 
good experience with x-base databases, others surely too, but if 
the solution works for 80% of cases only, it will once again lead 
programmers to simply ommit what is available and introduce own, 
more complex scenarios ....

Few additional notes, to not understand me wrong. I always try to 
see the bigger picture of things, not just from the pov of current 
View user. IMO VID should develop towards general "solution containers" 
= highering common ground for further developments. So - the solution 
is not to introduce one quick hack for particular style, but generalising 
things and letting ppl to develop their own solution, but using that 
common denominator. Good example is Rebol, its network protocol, 
and Uniserve - Uniserve is good example of taking things further, 
so each user does not need to start from scratch. In VID it is e.g. 
introduction of accessor functions. I suggest to try to find other 
"solution containers" :-)


The other thing ppl should think openly about, is to sacrifice backwards 
compatibility! I do remember ppl here screaming even about single 
change, which would eventually broke their code. Man, it sound like 
some of us woul never been with bigger projects? Our SAP workflow 
engine is some 50K lines, and when I asked my co-worker to add another 
functionality, he said - I will hack-it in, but I will REWRITE whole 
engine to be more flexible. So - that's me and ppl I work with - 
let's be sane - as I stated on ML - View starts from 1.3 ;-) But 
even further - let's not be selfish to the thousands of ppl, which 
may come to Rebol in future. I don't want to explain to anyone, that 
thing x or y is there because there was some compatibility issue 
with Rebol 0000.1 alpha and som eppl got tens of scripts already 
- that is imo selfishness in bigger picture, sorry to say that. Use 
old kernels for old apps. Our code will break anyway here or there. 
I prefer PURITY of solution instead of compromisses. So that is my 
message to future developments :-)

Slow down, Pekr.

Pekr: It is a good time to start looking at the next VID, and see 
what else from the VID project can be used. You are in the best position 
to identify which of those pieces are finished or worth pursuing.

Pekr: "But - does 'dirty work for other elements too, as e.g. check-box? 
"
No, why should it? with check-box you can save immediate
 check its-on? [its-on?: value]

with field 'dirty? makes sense, because you enter multiple chars 
before need to update db.