World: r3wp

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

Look at "Draw commands" in Rebol.com/docs/developer, there is no 
center value for 'rotate (now that the doc is up to date, there was 
one in the old docs). Use 'transform if you need center value.

I had old documentation by the hand, my fault, sorry

now it works ok (my future 'knob style ;)- do http://krutek.info/rebol/knob.r

I did that mistake some days ago ;-)

nevim

nevim

sorry

that autofocus :/

I have posted this once while in the first REBOL world and up to 
now things are the same. The trouble is while I am posting this I 
notice the foreign characters under Linux are yet not supported by 
/View. I am using Debian Ubuntu with brazilian ABNT2 keyboard layout 
and I am not able to input some characters used in Portuguese such 
as ´a ´e ´i ´o `u `a ^o ~a .

I just cannot remember who at that time ( probably a french guy) 
mentioned a workround to trick /View but I think this is a bug that 
must be fixed

anyone using /View under Linux facing the same trouble?

This is a View application .. and I see them

Are they not visible under Linux?

that´´s not what I mean. they are visible but the accents are misplaced. 
for instance in the word coraç~ao (heart in English) I should get 
the tild uppon the letter "a" and not before it. got it?

ahh...

ã

that´s it

So, you can't input it?

i cannot get it here... no way at all using the layout ABNT2

funny because all the rest of Linux apps works ok

no matter if I use Gnome, KDE or whatever

I cannot input thiose chars at all

you wrote "a" with tilde  under Linux?

no, Windows

have u filed a Rambo report ?

we need Unicode. It is already one year ago or more, when Carl told 
me, that RT received more requests for Unicode support and that it 
is relatively high on their to-do list. But who knows what does "high" 
mean here :-)

Carl knows the problem ... well at least I had the chance to talk 
to him once trhu a feed back... and also there was a ticket in the 
past ... i remember... but then