World: r3wp

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!

I am interested to know if people think it's a good system or not, 
with the four limits.

anton, what is the advantage of having hard-min, min, max and hard-max?

Gabriele, the four limits create, in between them, 3 zones where 
the available space is distributed proportionally. Having three zones 
allows the faces to behave differently depending on whether space 
is at a premium, whether there's an "normal" amount of space, or 
whether there's lots of available space.

(Has anyone ever seen a proportional sizing system with different 
zones like that ?)

The example faces in the demo are a bit abstract from reality, so 
I'll come up with some real-life examples...

hmm, I think if you are resizing proportionally the space between 
elements can be also distributed proportionally so no need to care 
about it? But maybe I just didn't get it so looking forward to some 
examples ;)

Yes, looking at it again I realise it's too abstract like this :)

Just fixing up the demo so it's easier to change the subfaces.

(Can't upload for some reason... must go to sleep, until tomorrow...)

A more concrete demo will help, but it's a cool demo none-the-less. 
:-)

anton, Glayout already does this and much more...

and again, its VID based.

GLayout really is only a stylesheet.

with extra hooks included in window managers and stuff.  you hpane 
is the same concept as my hgroup...

if you'd put a little time you could very easily put your vid styles 
within GLayout and benefit from all of this done and debugged for 
the last 2 years... I am using it commercially.