World: r3wp

I have to agree with Maarten

we should have gone for the BBS option that everyone but Carl agreed 
with.

It's nice that people completely forget the backend, the reason Carl 
built Devbase in the first place, and why he wouldn't look at other 
options. :-)

LOL. See, now Devbase is  giving me amnesia as well! Let's just say 
it's not my "thing".

We can go for any BBS anytime, it just officially will not be guaranteed 
by RT.

I was against new system, but I am satisfied with Carl's explanation 
of his POV. He needed streamlined channels for chat, bugs, CVS, filesharing. 
New system, in comparison to AltME, gives us:

- threaded discussions
- ranking
- tagging
- threaded discussions
- message/topic moving
- versioning system
- document management. Docs posted anywhere to any message.
- console version


So far, the big minus is - no GUI client. But - that might be over 
in few months ... So - if we think of RebDev as nothing more than 
RT's supporting infrastructure, I am OK with it. It is just that 
for fast dev related chat, e.g. nowadays GUI related, it can't reach 
Altme comfort and speed in not more than 20%. Threading is very confusing 
now ...

According to Carl there's no correct way to do what I'm trying to 
do yet.  That just might explain why it was so difficult to find 
the correct way to do it...

to bad liquid crashes R3.

are any of you having troubles with dynamically creating code and 
binding it as objects and stuff like that?  (In R3)

specific examples?

I'm updating DocBase GUI docs.


1. Changing the links at the bottom of each of the pages to point 
to a single template so that they are automically updated across 
all pages by changing one document.
2. Adding [[Category:GUI]] to each of them.

3. If I have time I'll start working on a VID2 to 3 document that 
describes what changed.  Things like face/parent-face is now parent-face? 
face.

I just wanted to mention that when I run the gui demo and click the 
"text view" test it causes an error on my vista machine.

Yup, Paul, that's a known bug.

Someone, BrianH I think, posted a link to this group (I think) to 
a document on DocBase that talks about the performance differences 
with some of the loop functions in R3.  I can't seem to find it though. 
 This is why MediaWiki bothers me.  It search sucks.

I would like to see such a document as well. I know that the loop 
functions in R3 are faster since they are all native, but I don't 
know how much faster. Clearly if I was the one who posted it I forgot 
where it was too :(

Paul, yes, this is due to one text area trying to load the source 
code for the original version of the demo, which doesn't exist anymore. 
However it throws a different bug than it should, so it's lucky that 
it came up.

Ammon, BrianH, it's search sucks: Which is why such a document should 
be a cookbook recipe. Easier to find.

anyone has tested size-text on a gob ?

is there a problem?

i get  a wrong size/x

example?

wait a minute...

I've not noticed anything yet, but there could be problems with certain 
fonts, multiple lines or shadows.

in fact there is a rich text bug that causes a size to be calculated 
incorrectly by a couple of pixels in a very specific condition.

i get the bug with the standard font too.

try this:
gob: make gob! [offset: 50x50 text: ["test"]]
gob/size: size-text gob
view gob

here "test" is truncated

y is incorrect too, missing some pixels (tested with text: ["gggjj"]

yes, I think that's a bug.

another one bug, if the size of the gob is previously set to 0x0, 
size-text is entering in an eternal loop.
gob: make gob! [size: 0x0 text: ["test"]]
size-text gob

i wonder how th

i wonder how the VID can work currently

size-text is used by some styles

Actually, not.

In VID, Size-text is only used to change the y coordinate of a gob, 
which means the bug has never been traced.

yes, I've not noticed the problem before. Now that I look at it, 
it seems to be constantly about 2 chars too narrow and a tad too 
short in height.

actually less than 2 chars.

That  sounds like a very high priority bug to me.

I agree

probably something Cyphre needs to fix.

Could you post the 2 bugs ?

Yes, however I think they need to be more exact. It looks like it 
could be related to the old rich text bug I saw a long time ago.

because of that i can't progress in my rich-text editor ;-)

exact = test with different font sizes and string lengths to see 
if the error is constant.

the error is constant, i tried several font and several para

http://curecode.org/rebol3/ticket.rsp?id=345&cursor=3

The original report.

OTOH it may not be related.

ok, thanks. I'll write up the report.

thanks

btw. are there any margins to adjust? could it be that?

i don't think so, the margin and origin are too low to explain the 
gap