World: r3wp

I've never seen this either. But all my scripts that use load/library 
are started with -s... (or encapped)

that is strange.. I'll test it again in a few days, the PC is on 
a customer place..

This example, in REBOL/View Developer's Guide was working before, 
but now gradmul effect doesn't give the expected result. I tested 
it on View V2.7.7.3.1 and 2.7.8.3.1

view layout [
    backdrop effect [gradient 1x1 180.0.0 0.0.100]
    vh2 "Layout Definition:" 200x22 yellow
        effect [gradmul 1x0 50.50.50 128.128.128]

    vtext bold italic "Layouts describe graphical user interfaces."
    button "Remember" effect [gradient 0.0.0]
]

hmm.. if I give a second color for VH2 then it works as expected. 
Some lastest changes affected this I think.

view layout [
    backdrop effect [gradient 1x1 180.0.0 0.0.100]
    vh2 "Layout Definition:" 200x22 yellow red
        effect [gradmul 1x0 50.50.50 128.128.128]

    vtext bold italic "Layouts describe graphical user interfaces."
    button "Remember" effect [gradient 0.0.0]
]

because the face is transparent, and modifying it (not creating new 
images) you have to merge the background... this change occured a 
long time ago (draw V2 IIRC).


in your second example, it works only because you set the face color, 
which is then multiplied. 

first example, fixed:

view layout [
    backdrop effect [gradient 1x1 180.0.0 0.0.100]
    vh2 "Layout Definition:" 200x22 yellow
        effect [ MERGE gradmul 1x0 50.50.50 128.128.128]

    vtext bold italic "Layouts describe graphical user interfaces."
    button "Remember" effect [gradient 0.0.0]
]

Ok, thank you. I understand. Earlier versions of 2.7.x it wasn't 
like this as I remember. (or am I getting older?:) )

yeah, its been like that a long time, its just an edge case which 
people don't hit often.   you probably where using faces with colors 
and you didn't realize it.

There is a very annoying bug on View (2.7.8.3.1), can anyone confirm 
that? Please see the code below:

fnt: make face/font [
	name: "Courier New"
	size: 14
	align: 'left
	valign: 'top
	color: white
]


f: make face [color: blue / 2 edge: none size: 300x200 text: "" font: 
fnt]
window: layout/size [] 500x400
insert window/pane :f
loop 500 [insert f/text " "]
append f/text "test"
view window

It doesn't matter how many space character you put in to face/text, 
it always shows the text after spaces, on the second line.

I tried f/line-line: none etc. If I replace spaces with anything 
else then it works as expected. But space chars somehow ignored by 
the face.

I can only find a workaround, I use #{A0} (no-break space, alt + 
0160) character instead of normal space #{20}. Then it works ok.

no-wrap ?

as-is ?

t: join head insert/dup copy "" " " 500 "test"
view layout [text t white blue]

t: join head insert/dup copy "" " " 500 "test"
view layout [text t white blue 'as-is]

Just to make Graham's suggestion explicit.

The word doesn't have to be literal:

view layout [text t white blue as-is]

No it doesn't change the result.
To test it give a width for the text:

t: join head insert/dup copy "" " " 500 "test"
view layout [text 100x400 t white blue as-is]

test
 is still on the second line.

I tried as-is, line-list: none, I need to use wrap?: yes. Otherwise 
I have to my own wrap function which I don't have time to do.

Here is the difference:
t1: join head insert/dup copy "" #{20} 500 "test"
t2: join head insert/dup copy "" #{A0} 500 "test"

view layout [text 100x400 t1 white blue as-is return text 100x400 
t2 white red as-is]

I would call that a feature, not a bug.  The (normal) breaking space 
allows word wrapping to split between words, rather than in the middle 
of words...

How can you call that a feature? The text field is 100 pixels width, 
I put 500 space chars and then a word after that, and the word appears 
on the second line of the text field. Where is that 500 chars? Even 
if you insert new spaces (let say 1000 more) the word position doesn't 
change.

If you think it as a html document (all whilte-spaces treated as 
one space char) then why it stands on the second line?

And the problem is you cannot read a file and put it into a face/text 
IF the document have lots of spaces at the beginning, even if you 
use as-is.

trim/head

This should show you what's going on:

view/new layout [T: text 100x400 {Text} white blue as-is]
loop 50 [insert T/text { } show T wait 0.2]

Endo, this behavior is common to many, if not most, word wrapping 
algorithm. It makes no sense to wrap the spaces themselves to the 
second line; OTOH, it can be argued that it makes no sense to have 
more than one space in a sequence as well, so it's hard to say what 
is the best behavior.

Graham: I know this, but what if you should have those spaces?

Izkata: Yes this could an example as well. My second example shows 
the problem exactly.

Gabriele: I think the best behavior is to keep text as it is. (at 
least we should have this option, using as-is etc.)

If a text document is formatted with spaces (think that using a propotional 
font, take the old Amiga Autodocs files as example) you can never 
put those texts into a face/text. Face/text is not a document like 
html, even if it would be more than one space chars should be treated 
as one space char. 


So I'm still thinking that it is a word-wrap bug in the View engine.

Keeping text as is means not breaking lines. If you break them, you're 
not keeping it as is, and have to make a decision where to break 
it.

Should you break it at any point? Only before a space? Only after 
a space?


Imagine you have "aXXword" where I replaced spaces by an X. How would 
you break it?

a
XXword

aX
Xword

aXX
word


You're saying that REBOL should do like in the second example. That 
would be unacceptable in most cases though; REBOL does like in the 
third example, which is what makes the most sense in the most cases. 
You have a more specific case, where it's probably best to just use 
NBSP or to come up with your own line breaking algorithm.

Take the Izakata's example: you are inserting spaces to the beginning 
of a face/text. It "works" to some point and then it stops changing 
the face/text. (well it changes the text itself but doesn't show 
it on the face)

I mean that, it should somehow break the line even if the line has 
spaces (wrap before/after/somewhere). Take any text editor, they 
somehow does word-wrapping.

Think that you have two paragraph text and there are, say 100 spaces 
between them, you don't have a chance to put that text directly into 
a face/text. Replacing all spaces to NBSP is not a complete solution 
because NBSP is not a whitespace char so they are not wrapped until 
end-of-line. 

In the current situation: "if your face is 50px width and word wrap 
is on, then you cannot put 100 spaces between any two words in the 
face/text (face cannot display those text correctly)"
This looks still a major bug to me..

The situation you describe is in no way different than the above 
examples. Just increase the number of Xs - you only end up with *more* 
possibilities of where to break. Where would you break? From the 
way you describe it, you seem to want to break like in example (2). 
Show me anything that does *word* wrapping and produces the result 
as in (2).

Ok, I tried different text editors to see the word wrap behaviours, 
they all have different behaviours. Now I see your point.

I thought that it is a bug (and still feel like that) because "it 
doesn't matter how many spaces you insert to the beginning, "test" 
doesn't move after some point" (How it should move? you asked, I 
don't know, but it SHOULD move somehow if I constantly add more spaces)

All the other tools (notepad, notepad++, editplus etc.) behaves different 
than each other. They wrap the line, if you add more spaces after 
some point they move (push) the text down or right or somewhere. 
But they move it anyway. They don't stop somewhere.
Anyway, thank you for your time & responses.

The best solution would be to have options you can set so you get 
the behavior you want. Alternatively, access to the lower levels 
so tthat you can do the typesetting yourself. Too much abstraction 
is as harmful as too little.

view layout [f: text-list data ["aaa" "bbb" "aaa" "ccc"] [probe f/picked]]

When I click on "aaa" both lines are selected. Do I missing something 
or is it a bug in text-list?
When use CTRL click, no chance to get both "aaa" in f/picked

It's probably a bug.

text-list uses the text itself as the key, so each string has to 
be different. if you can't use a better alternative for some reason, 
you could change the strings to something like "1) aaa" "2) bbb" 
"3) aaa" ... etc.

I see. Thank you.

As I see there is no chance to make face/data and face/texts for 
text-list, choice styles. When I change like face/data: copy ["a" 
"b" "c"] then face/texts is also syncronized. and vice-versa.

The only way is to use the index? of selected item on a block which 
holds item-data. Is that right?

As I see there is no chance to make face/data and face/texts for 
text-list, choice styles

--> As I see there is no chance to make face/data and face/texts 
>different< for text-list, choice styles.

Endo, I solved this in the VID Extension Kit.

Henrik: Thank you! I'll play VIDExt more! Is it stable enough to 
use in a production do you think?

I use it in a production environment, but it is continually improving, 
though I'm taking a break from it right now.

Ok. Thanks a lot.

I wrote a function to get a copy of a wrapped text in a face object. 
Please have a look at it. If you have a better idea please let me 
know:
http://rebolforum.com/index.cgi?f=printtopic&topicnumber=46


it uses offset-to-carret to find the line positions and inserts a 
newline to that position in the text.

Endo, that looks interesting. Do you think it could be used to fix 
the box with "Wednesday" in it:

http://rebol.hmkdesign.dk/files/vid-postscript2.png

Henrik, I wrote another version of the function which is a bit better. 
It could help about the bug you told.

The only problem is it it makes a copy of the given text. So it is 
not the same text anymore.
http://rebolforum.com/index.cgi?f=printtopic&topicnumber=46

I don't think copying the text is much of a problem.

I see, so you can try this function.

thanks

Can anyone confirm this is a bug in View (VID), so I will post it 
to RAMBO:

gui: layout [f: h1 100 "test"]
f/text: does [probe "testing"]
view gui


;click on the text, drag --> crash rebol.exe. Tested on XP Pro SP3. 
View 2.7.8.3.1.1

;function get called when the text clicked, crash happens when dragging.

yes, it crashes. I'm not sure if you can pass functions to face/text.

passing function to face/text is not a good idea, it's called (read) 
several times when an event occured. But crash problem may be fixed.

posted to RAMBO as a low importance bug.