World: r3wp

Oldes, exactly. To be able to use bitmapped fonts we need to be able 
'draw into the cache' so this is also doable.

And I don't think this would add too much of Rebol size so I believe 
this will be added to the R3.

Hm, we'll see. I just hope some much more needed things will be adressed 
in R3 too.

Yes, there is still much more important stuff in queue at the moment.

cyphre, do you expect that the new and faster SHOW would be postponed 
to R3? is it tested?

(I don't know what's involved, so I just call it "new and faster 
SHOW" :-))

R3 will have completely new and faster blitting. I don't think Carl 
would like to waste time with improving the R2 engine but I can ask 
him ;)

one argument would be that we could get it tested, but that depends 
if you can slap it into R2 in 5 minutes :-)

if it takes weeks, then that's better spent working on R3

I don't think the problem is with testing in this case. (Either it 
works or not ;)) But I'm afraid it would need some deep changes in 
R2.

then it's a bad idea

Oldes: re. Unicode, other than display you also need input, which 
is what Jerry is requesting

yes, that's true:(

Regarding sinoglyph, the source was available here:   http://www.xuehanyu.org/sinoglyph.r

I know the author was working on an english translation also

It looks like it is done, or mostly so, anyways.

Gabriele, 

Actually, Oldes is right. Showing two-byte characters is good enough. 
IME is not necessary for REBOL/View, because every Chinese/Japanese/Korea 
OS has proper IMEs installed. IME sends the codes encoded in the 
OS codepage to the focused window. For Example, If the codepage used 
by Windows XP is Big5 and I type in the Character which means one 
( #{A440} in Big5, #{4E00} in Unicode, see http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=4E00
), my REBOL/View program will get two key events sequentially, which 
are #{A4} and #{40}. REBOL/View shows it as two characters instead 
of one. I hope that REBOL/View can let the OS do the text-drawing, 
like the REBOL/core console does. REBOL/core console doesn't have 
the Chinese-Character-Showing issue, because it basically send the 
#{A4} and #{40} to the console, and let the OS do the text-drawing. 
the OS knows that #{A4} and #{40} should be combine to one Big5 Character, 
so it just show it as one character. Of course, if I type in two 
ASCII characters, the OS is smart enough not to combine them into 
one "non-existing" Big5 Character. CJK encodings are supersets of 
ASCII, just like UTF-8 is a superset of ASCII.


It's nothing to do with Unicode, so it is not too difficult to fix, 
I guess. Please fix this in 2.7.5 or 2.7.6 please ... 

It's on my wish list for Santa Claus this year.

Jerry, displaying is not as easy as it seems, because REBOL uses 
its own text routines. I don't think we have enough resources to 
put the effort on R2, but you can try sending a message to Carl about 
this. (Every request increases the priority a bit.)

squeaky wheel?

Gabriele, Thanks for the explanation. Since it's not as easy as it 
seems, I am not going to disturb Carl for this request. I want REBOL 
3.0 even more. I don't want to waste RT's resources.


By the way, my Zhuyin (Bopomofo) Input Method Editor is in progress. 
(http://en.wikipedia.org/wiki/Zhuyin_table) There are some bugs and 
the interface is not good-looking, but being in progress is good 
enough for me, for now. At least I know where I am going now.

Either someone has a lot of questions, or I need to install a language 
pack!

wo kan bu dong.

sinoglyph.r is cool.

Pretty neat stuff ...

There is a unicode gorup here if you guys want to review the convo 
already had there.

And Carl spoke up there too.

Displaying of 'exotic'(from european POV) unicode is not easy task. 
Couple of months ago I have been enhancing one software engine with 
custom bitmap text rendering for Arabic text support. It was a nightmare 
;) But in the end I somehow mixed it with Windows support so it worked 
at least acceptable (even MS have some issues in their implementation).

even
 MS  ;-)   does MS do anything completely right?

Yes! Marketing ;-)

lol !

http://conal.net/phooey/


Phooey is a functional UI library for Haskell. GUIs are usually programmed 
in an "unnatural" style, in that implementation dependencies are 
inverted, relative to logical dependencies. This reversal results 
directly from the imperative orientation of most GUI libraries. While 
outputs depend on inputs from a user and semantic point of view, 
the imperative approach imposes an implementation dependence of inputs 
on outputs. Phooey ("Phunctional ooser ynterfaces") retains the functional 
style, in which outputs are expressed in terms of inputs. In addition, 
Phooey supports dynamic input bounds, flexible layout, and mutually-referential 
widgets.

An nice example of dialecting in Haskell without falling into imperative 
style. Similar to Flapjax and his forfater FrTime.

You're supposed to be resting!

Mmm.. he's probably eating a steak with a thick sprinkling of salt 
on it.

Ok, here's a couple of VID styles I found useful - HGROUP and H-ITEM 
:

view center-face layout [

 style hgroup panel with [insert init [insert second :action [across]]]

 style h-item panel with [insert init [insert second :action [space 
 0 across]]]
	hgroup [box 50x50 navy box 50x50 coal]
	h-item [box 30x30 tan box 40x30 wheat]
]

HGROUP is just a panel whose default layout direction is ACROSS instead 
of BELOW.

H-ITEM is just the same, but without spacing between the subfaces 
(so they are stuck together as one "item").

Nice Anton!

REBOL[]

scroll-pane: make face [
    color: red

    set-bounds: func [ offset [pair!] size [pair!] ] [ ; why not be called?
        print "$"
    ]
]


Window: make face [
    offset: 30x30
    pane: reduce [ scroll-pane ]
    feel: make feel [
        detect: func [face event ] [
            switch event/type [
                resize [
                    print "%"

                    Window/pane/1/set-bounds: 0x0 Window/size/x / 2
                    show Window
                ]
            ]
            event
        ]
    ]

]

view/options Window [ resize ]

; After resizing the window, only the "%" can be printed. Why set-bounds 
in the scroll-pane is not called?

Error is here:
Window/pane/1/set-bounds: 0x0 Window/size/x / 2
should be:
Window/pane/1/set-bounds 0x0 Window/size/x / 2

Thank you Anton. I am so embarrassed. I should not make such an error. 
Not like this.

That's alright :) We all do it.

Yup. Made that kind of mistake plenty of times.

Here's a document (using LAYOUT spec) which tries to explain a proportional 
resizing algorithm.
do http://anton.wildit.net.au/rebol/doc/resizing-algorithm-doc.r

And here's a demo implementation: A HPANEL style implements the algorithm 
(additionally with wrap) and you can play with it by dragging with 
the mouse:

do http://anton.wildit.net.au/rebol/doc/proportional-resizing-example.r

what exactly does the demo do?

Did you try click and drag with the mouse near the bottom of the 
window ?

yeah .. the window resized but nothing inside the window changed.

Click in the window.

It resizes the HPANEL, which then distributes the space inside itself 
to its subfaces.

Oh .. got it!