World: r3wp

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

dirty? is set when the text is changed. try this:

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

then click inside and outside and edit etc. the action is triggered 
when you change it and click outside.

so before another face does its action, you can update your db here. 
then the button etc can use data from the db, instead of worrying 
about the contents of the faces.

OK, understood now, thanks a lot .... but I can decide to save later 
on, e.g. when I leave screen, right?

accessors - i did not mean different methods as in "methods fr different 
faces". its different concepts. in old vid it works this way:

you put data in the face as in [filed "Hello" check on] etc. kind 
of set-accessor.

when data changes, you handle it in the action and pt it back in 
the db.

the action gets a parameter 'value, so instead of of field/text, 
check/data, text-list/picked/1 you can just use value. kind of get-accessor
  field record/name [ record/name: value ]
  field record/address [ record/address: value ]
  check record/iwantit [ record/iwantit: value ]
  button "send" [ send [me-:-here] mold record ]

and when "send" is clicked, all that values are already in 'record

and for a bit performance the field-action is not called on every 
key, but in the last moment. also more usefull if you want to convert 
it first to a number or such.

then people started to be more performant and "living", changing 
the face-fields instead of relayouting. resulted in all that dealing 
with /text /data /internals. and then Carl unifiied that with accessors, 
so that we deal with set-face, get-face, and for storing we have 
set-face/get-face for panels.

saving later - yes, the face keeps its value. you can as well get 
the value out of the face. only the action may be called sometimes 
in between and suddenly do something. in my example its just a store 
and each action overwrites the old value. if you change layout there 
or such it may led to surprises.

maybe we should have a way to disable that dirty-trigger on a per-face-basis?

.

vid2: Has somebody ever tried oberon/blackbox-builder? Thats the 
kind of layouting i like. They use text with "active-x-controls" 
inside (only better and simpler ;) . blackbox can do really windows-style 
guis that way. then while developing you can mark part of that gui 
and just copypaste it somewhere else. gives a lot easier control 
than typical gui-builders IMHO.

that controls can also access the sorrounding text. so they can influence 
the formatting of the following text, or fold it. Based on that they 
have even tree-views.

I noticed a change in image! type offsets in view 1.3 compared to 
e.g. the rwdraw57e.exe version. In rwdraw57e offset 1x0 was in the 
corner, now it's offset 0x0. Example:

>> bitmap: make image! 100x100
>> change/dup at bitmap 1x0 red 8x8
>> view layout [image bitmap]


That piece of code would put a red square in the corner of the bitmap 
in the rwdraw57e version of View. In View 1.3, the second line should 
be:

>> change/dup at bitmap 0x0 red 8x8


and I think, it's a good change. You could argue, that the offset 
should be 1x1 in the corner, like series are indexed from 1, and 
not zero. What do you think?

I'm  wondering whey then the first hex value in the image that is 
created has the #FF0000 in it for both images?

First method using 1x0...
== make image! [100x100 #{
FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000....

second method using 0x0...
== make image! [100x100 #{
FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000....

wouldn't the first method have a #000000 as the first hex value of 
the image?

What you see is the hex from the change and forward. To see the bitmap 
from the beginning, just type bitmap at the prompt.

I thought this two lines should look different, shouldn't they?

>> view layout [box 100x100 black effect[draw[rotate 45 0x0 fill-pen 
red box 20x20 ]]]

>> view layout [box 100x100 black effect[draw[rotate 45 50x50 fill-pen 
red box 20x20 ]]]

as I understand it the second example should rotate the square in 
center