World: r3wp

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.

such thing should be done via accessor functions - set-face, get-face

 - i think Carl changed philosophie here. The old vid is good for 
 simple forms. Why use an accessor when you simply can inline the 
 data into the layout? But it works not so well when you want to change 
 displayed data. Text-list for example where not even prepared to 
 have data updated. thats where accessors come in. instead of re-layout 
 reuse the old faces and change their values.

About happily breaking code, IMHO thats for major versions, 3.0. 
and then not only some somewhat improved styles, thats not enough 
to break compatibility. Then Carl should have the chance to invent 
some things new.

Petr: The button is not pressed. The mouse click is catched BEFORE 
the button is pressed. Then, you unview that face so the click NEVER 
gets to the button.

The problem is with docs, not with the code.

Whether this is a good design point of VID or not is a different 
issue. Personally, I used to disable this event func in my earlier 
apps; on later apps, i just change the field style to reset the dirty 
flag before calling the field's action.

Petr: the argument about View vs. Flash was about AGG View, not the 
old View.

Gabriele - I am not sure, with Terry, it was imo old View vs Flash, 
then came-in devcon and first introduction of AGG, which was happily 
applauded, but it does not really matter ...

(ah, forgot to reset color, sorry ) ... Anton - you can ask me to 
slow down, but in such case I usually "give up", instead of "slow 
down". Some design issues are really important at certain points, 
and if I e.g. ask for some "what's next for new VID from developer's 
pov", I can't be referenced to doc, which says basically nothing 
about it ....

Volker: using different methods to set style values is basically 
a wrong aproach imo, e.g. methods for automatic iteration and data 
collection are more difficult to do, as you have to inspect what 
style are you investigating, and what is the method to get the data.

btw - would it be good to have Desktop group here? I wonder if someone 
has some suggestions worth discussion first, instead of putting them 
directly into RAMBO as a wish? Cyphre just informed me, that he updated 
his old demos to be compatible with 1.3. Some of them worth inclusion 
in main Demo section imo ... Bouncing Demo, Cursors, Image Effect, 
Laser, Rotoobject  etc.

Petr: i remeber that discussion very well, i was the one to say that 
View was going to be better soon, and i said that because i was testing 
AGG View already.

we can't say what's next for VID so easily, because there are lots 
of variables involved.

but, if you want my opionion,

and i wish to stress this is just IMHO

we need something like VID2, created from scratch (or almost), and 
strong enough to serve as a building base for applications.

it's not that VID is not good, it's that its purpose was not to be 
the ultimate gui framework, but more of an example of what you can 
do; indeed, now we have RebGUI too. but, the problem with that way 
of thinking, is that in practice developers need a solid base to 
start. so it's much better for everyone to provide it.

i think that there are lots of subtle design issues that would be 
too hard to solve if we wanted to keep compatibility and just extend 
VID.

rather, i'd keep VID as is for compatibility and provide a brand 
new VID2.

in case anyone didn't notice, this is just my PERSONAL opinion.

Gabriele, thanks for clarification. You are not the only developer, 
who thinks so.IIRC during older 1.3 initiative, Romano expressed 
just the same. It is probably a little bit difficult to introduce 
some conceptual changes for current VID incarnation. But that should 
be stated oficially. There are several of you - gurus, who could 
outline in few paragraphs, what way should VID2 (or VID+) go. One 
of my friends suggested me looking into (was it?) Gnome UI guidelines, 
as an example of how complete definition of widgets, behavior, etc. 
of such framework should look like ...

And what is more, - there are other planned changes to View kernel 
- fonts in AGG  (under considertion IIRC), text mark-up, 'min-face, 
which will maybe in itself influence even current VID and the way 
we use it, if such concepts are implemented ...

There are several of you - gurus, who could outline in few paragraphs, 
what way should VID2 (or VID+) go

Actually, I think it would be easier to design and implement it than 
try to outline it in a few paragraphs. :-)

problem 1) is: i don't know what VID2 is. we need to decide the goals, 
design it and so on.

problem 2) is: this whole issue needs discussion. we need to discuss 
it with the community and the team; then Carl has the final answer. 
so, if community prefers some changes to VID rather than VID2... 
no point in wasting time with VID2. and so on.

so... since talking is cheap, if you want i could talk about a lot 
of things. but, if you want to know what's going to happen, i can't 
tell you, since i don't know. maybe even Carl doesn't know: a lot 
of things were annunced but never materialized; it's much better 
to avoid annuncing something unless you know that you're going to 
deliver it :) (again, IMHO)

Volker: re practical usage of dirty flag - you said, that when dirty 
flag is used, field value is always saved? I tried following example, 
and it is saved too. What am I doing wrong? Following code, even 
if dirty is set to 'no, still saves the value, even if I click outside 
the field ...


name: "petr" view layout [f: field name [name: f/text] field "test" 
do [f/dirty?: no]]