World: r3wp

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

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