AltME groups: search

but anyways, I understand that at some point we'd have to get a few 
hours so I could explain (and then document the discussion) on the 
basics of those hooks.

and added a pop up to select icon, or text or both right on the toolbox 
 ;-)

in normal view we don't notice as much because its static... but 
when you start adding dynamic resizing and real time scrollpane movement... 
its just sooo slow ... so much that I added a property in the field 
to remove all the prettyness!

Anton, the shape dialect was generated by my REBOL script. So it's 
not easy to optimize it. I wrote a C# program, which get all the 
glyph data of Chinese characters. I put these data in this format 
: x y type x y type ... where type is the type of the point. My REBOL 
script loads the glyph data, and generates a Shape dialect for every 
character.

I look for 'line followed by a pair! and another 'line, then I remove 
the second one.
Actually, here is a better one:

For you to have a taste of how complicated the glyphs of a Chinese 
Character can be, The following example shows the last character 
in my Chinese name. there are 238 CURVE commands and 7 LINE commands.

Anton, the shape dialect was generated by my REBOL script. So it's 
not easy to optimize it. I wrote a C# program, which get all the 
glyph data of Chinese characters. I put these data in this format 
: x y type x y type ... where type is the type of the point. My REBOL 
script loads the glyph data, and generates a Shape dialect for every 
character.

is it possible to use any drawing this way and not only kanji/chinese 
chars?

my latest shape compressor is now 2.5 times faster, by using a list! 
instead of a binary while accumulating values, and then converting 
it to binary!

and since I'm only converting it to binary at the end, a lot of GC 
processing is alleviated.

oh, and 1000 of the above glyphs now takes 4.5 seconds to compress... 
imagine if we had rebcode !

and 1000 glyphs takes 8.95 MB of RAM which is quite optimal IMHO 
   :-)

For example, the left part of the "yung" Chinese character is "jin", 
meaning "gold" or "metal". The left part of any  metal-related character 
is exactually the same as the left part of "yung". There are hundreds 
of such characters. And "metal" is just an example, we also have 
"water", "fire", "soil", "bird", "dog", "hand", "human", "tree" ... 
this list goes on and one.

Presumably that is how it is done.  Divide into radicals, and further 
divide radicals into elemental strokes.

and a direction

Scaling factor and direction? I am afraid I dont understand what 
you mean. Anyway, I don't really have time to do the font-compression, 
and it's not practical for me for now. I am trying to change my bitmap-based 
text-rendering REBOL/View component to a vector-based one. I hope 
the performance will not cause too much pain. Considering the complexity 
of Chinese font, the rendering performance is what I am worring about.

Guys, that's exactly the way I have done 'embedded font' in the quick-hack.r 
demo I reffered some time ago when talking about the fonts. Yes it 
is possible to make any kind of font that way. And yes, DRAW is really 
good as a 'optimal storage' of vectorial data ;)

Jerry, what about splitting each chinese character up in strokes. 
Each stroke should just be a number of points giving the position 
of the middle of the stroke from one end to the other. Like when 
a person draw the character with a pen. You start each stroke at 
one point, then you move your hand, sometimes fast, sometimes slow, 
until that stroke is finished. Then the next stroke and so on. The 
rendering engine can then calculate the thickness of the stroke at 
any time from the distance from point to point.

if pieces of the glyphs are the same, then why not just assemble 
them within several draw shapes? and then just draw more than one 
single shape?  the memory tradeoff would be significant, yet the 
speed would likely be almost identical

and there is no "tricks" involved.  no recomputation of the way things 
are drawn.

in any case, a way to automate this is pretty easy IMHO. just do 
drawing and measure the amount of pixels which overlap wrt previously 
defined recurring shapes.  generate a view app which shows the highest 
matches in order and then a simple yes/no to confirm.

And even better, I have collected the Chung-Jay code for every Chinese 
character. Chung-Jay can tell us what parts are in a character. I 
plan to use both Chung-Jay code and the pixel-matching method to 
speed up the analysis process.

When drawing, I would like to translate the X to 0 and Y to ( Y + 
28 ). What the Matrix should be? Thanks.

I mean using the Matrix command in Draw, like MATRIX [a b c d e f]. 
The Matrix command would premultiply the current transformation matrix 
with the given block. What should I assign this block to translate 
the X to 0 and Y to ( Y + 28 )?

Forget about my previous question, I am not going to use matrix in 
this case.


For rendering cahracter images, I thought that relative-positioning 
could be a good idea. After drawing a character image, then shift 
(translate) to the next position, and the next character would be 
in the right position. So I made my draw block some thing like [ 
image char1-img translate rp1 image char2-img translate rp2 ]


It worked, but the rendering performance was slow, way too slow. 
So I go back to my good old absolute positioning. [ image char1-img 
ap1 image char2-img ap2 ]. No more "translate", no more matrix.

If someone make such a guide, it should be cleared with Carl, I guess. 
He probably has some ideas, and the wanted user interface should 
be within the frame of how REBOL work (and will work in the future).

Yes, and it's not just to the side, it's also a couple of pixels 
too far up.

geomol, here's another one.

view layout [area 400x400]


paste a large amount of text in it. place the cursor to the far right 
on the top line and press cursor down. the cursor also moves to the 
left.

as long as they're not changing their color and radius, it's hypnotizing 
level is OK i think ;)

for the VID 2 (or better let's call it VID 3.0?), we should count 
with things like space for hilite and visual focus representation 
....

I suggest making a section in the viewtop for educational tools and 
put it in there.

hoped  that  was5 month, and i missedone^^

split in lines and use just that part that fits the screen

henrik, yes, the engine to calculate line breaks can be manually 
harnessed and its *VERY* slow.

you're best bet is to use a monospace font and do a very fast char 
count instead.

obviously, you shouldn't using area, and well, the complexity is 
that you have to implement all the cursor managment manually..  :-(

glayout has an integrated function which can give you a line-block 
of wrapped text.  I had done tests for large files and this engine 
really is inadequate.

Maxim: I'm lucky that I don't need to edit such a large files:-) 
And Jerry, it's really interesting.

Not much. It just parses the English sentence inputed by the user, 
makes a REBOL block, and draws the REBOL block as a syntax tree. 
That's all. I am thinking about using it to "help" people translate 
documents or something. I might combine it with an REBOL Chinese 
Editor that I developing. Check it out here http://city.udn.com/v1/blog/photo/photo.jsp?uid=JerryTsai&f_PHOTO_ID=472052

Is it possible to catch program close event - when windows shut down 
and do something (save data)? The same appies when somebody closes 
all program windows or terminate process from task manager.

It help for window face, but what if there is no windows(faces) open 
at closing time. F.ex. application at that moment is witout opened 
windows
and there is only taskbar icon.

Thanks, Anton and Cyphre. I am still improving it. : )

Oh. I didn't know there's NET 3.0. I just need 2.0 for work and that's 
enough for me ;) Anyway, REBOL's result is much more interesting 
with .NET 3.0 than with .NET 2.0 :o))

We have a software product. The version one used .NET, which made 
our software 10 MB in size. The version two uses C/C++ and some third 
party GUI components, it's 6 MB. but that's still too large for us. 
Few days ago, my boss asked me  whether I could redesign the GUI 
part of our software using REBOL. and I said ... maybe, if I could 
make my REBOL code call GetGlyphOutline successfully. Our product 
needs Chinese character support.

Jerry: I just hope R3 will have better localization support. Lot 
of my work is localization to east-asian languages and REBOL is already 
helping me with localization to European languages. I hope for Unicode 
support and other enhancements to R3.

Many religions and cultures believe that if we pray hard enough, 
and if there are many of us, our dream could come true. "please support 
local codepage, please support local codepage ... "

O'k found myself - selection is in face/picked and they should be 
equal of elements in face/data:
F.ex:
face/data: [ "peas" "apples" ]
face/picked: [ "apples"]
the above statement shows selection in face after "show face" 
face/picked: [ "apple" ] 

the above statement do not show any selected row after "show face"

I've noticed that the 'resize event automatically causes a SHOW, 
as far as I can see. This seems to me is a little silly, since there 
is no chance to resize your GUI before this SHOW and you need to 
show the GUI twice, slowing down the display process by a factor 
of 2. Is there a way to resize the GUI before 'resize does the SHOW 
or disable the SHOW on 'resize event?

Thanks for asking that question, Henrik !  I've been blithely using 
DETECT all this time and not noticing that it was doing a SHOW first. 
I'll try using REDRAW instead of DETECT from now on and see how it 
performs.

anton, but when you resize the window with mouse and by changing 
the size of the window face, I think the order might actually change.

This behaviour is specified in the EDIT-TEXT function in CTX-TEXT, 
in the TAB-CHAR handler.

I seem to recall someone actually asking for this behaviour. I think 
they wanted a way to "reverse out" of a field without validating 
it.

This seems wrong to me. I would have thought Shift-TAB would be just 
like TAB, except going in the opposite direction. I want to always 
validate when leaving the field.

It would be better if undo was implemented for the field. When all 
the changes are undone, then the face/dirty? field should be reset 
and the face/action can avoid validating unnecessarily.

The ESCAPE key could be used to undo all changes (and so avoid validating) 
before the user TABs or SHIFT-TABs out of there.

ie. I don't want to leave a field with unvalidated data in it.

I have a decimal-field, which is just a field whose action just cleans 
the face/text and ensures that it can be converted to a decimal.

If the user can just SHIFT-TAB after making changes to the field 
then the validation in the action block is skipped and the field 
is left showing invalid data.

this is a difficult issue. personally, i prefer tab and shift-tab 
to not do any validation, while enter does. it's not always a good 
idea to not let users go away from a field just because it is invalid.

however, since this depends on the application etc., i think the 
best solution is to call the action on enter, and just call face/refocus 
on tab / shift-tab. then you can make refocus do the same as the 
action, or not.

Gabriele - will there be anything improved in regards to keyboard 
and R3? Key-up event, ctrl tab, multiple keys pressed?

Gabriele, I see your point: The user might want to enter some data 
in a field, but part way through think of something else and leave 
the field to attend to it, then return to the original field to complete 
the data entry. Finally the enter key will do the face action which 
can validate the field.

I think personally that FEEL is very non-accessible to users and 
non-extensible. You can't easily add a simple thing to a feel, like 
when you create a style from a specific face. If you want single-key 
actions from a text field, you have to dive into the feel code, study 
it, know how feel and events work and then add your code. This is 
probably more an issue with the feel code itself, rather than the 
concept of FEEL.

Ah, then we are on the same wave. But I was not able to defend my 
opinion to e.g. Anton in the past :-) So surely rebollers will differ. 
For your own kind of style, e.g. animation, you might prefer current 
aproach. But I visited recently my friend, who started to learn Delphi 
some 2 months ago, and he already did nice app in it. The most missed 
feature of SDK is - no screen painter, lack of crucial styles, lack 
of proper style behavior (just try list-down here in AltME, you can't 
close it by clicking outside, esc, etc.?), and most ppl are really 
used to - on-double-click, on-left-click, on-over, whatever ...

What I just don't know - what if you would like to serve e.g. holding 
down shift key and holding down left mouse button? e.g. for dragging 
something? I mean - you need both functionalities of on-something 
- how do you mix code then in those code-blocks?

Pekr, then they would work as flags. You should be able to access 
from within the code block, which qualifier keys are pressed. Binding 
the code automatically to the feel object would let you access the 
variables and events in the feel object.

Current feel objects can be inspected and extended dynamically.

I think the feeling is to have more higher level types of events 
derived from the raw event stream and provided to you in a more separate 
kind of fashion.

I e.g. don't like 'over. Maybe they are there from arcane View period? 
;-) Once you press mouse button and do 'over, it no more goes into 
'over iirc, but engage. Then I wonder, if having native 'over was 
not meant only as a helper because of speed? But I regard it inconsistent

Then it leads to special sections od docs, as Note: use 'engage for 
drag and drop. For me, the 'over, as is, is unnecessary complication 
- you have to explain it, and it could be done in 'engage too.

I'm not sure either. Replacing the current FEEL system would be a 
tremendous amount of work. I was originally thinking more in line 
of extending it to those placeholders. I'm no expert on dialects 
and combining it with FEEL, but if it's possible to do, then OK. 
:-)

Hang on a minute.. The big revelation I had above about using REDRAW 
instead of DETECT was probably premature. Of course I must have experimented 
with both ways a long time ago and I would have settled on using 
DETECT for a reason. You have to be careful in REDRAW to avoid recursive 
SHOWs etc. It's worth more experimentation, anyway.

pekr, the way the feel is built is very optimised.  there are reasons 
why engage separates the over.  I just would like access to the func 
which splits up the calls to feel. which is what I did in regraph. 
 since all events are virtual I was able to separate them differently, 
and support drag and drop directly in the graphic element's feel.

redraw realy slows down performance and can be a very dangerous memory 
clogger to.  when I replaced (long ago) all redraws in VID with better 
code in the actual engage and other feels, many views started feeling 
snappy when they had been hogs before.

I experimented a stream system for glass and it works very well. 
 it changes the way we approach events and can allow plugins to manipulate 
the way events are handled (and adding handlers for those changes) 
without the faces even knowing.

I even realised that we could add drag and drop OVER a fully working 
apps, sending the events to an external handler.. this allows things 
like interactive face manipulations while the app is running...  
:-)  cool for visual app dev... and its completely non-intrusive 
to the code of the running app.  the app just never receives certain 
events when a series of events occurs... and no need to play in the 
face's individual handlers either  (which is the biggest feature 
IMHO:-)

and it comes with a reference (and fully functional) multi-purpose 
node called a plug which allows you to mix and match many types of 
dataflow nodes using the same node.

I have a problem with field and key in the same layout:

view layout [
	field
	key #"t" [alert "key: t"]
]


If I click in the field and try to enter a "t", the alert pop up. 
I'm doing this under OSX. Is it the same on other versions of View?

I'm wondering, why I haven't noticed this before, or maybe I have 
and forgot about it.

has anyone done some complement docs to describe things like the 
offet and grad-scale ?

yes, I think gradients are quite hard and non-intuitive to do in 
DRAW

A just-in feedback message to REBOL.org:
<<

How to find the documentation for the use of VID and RebGUI} description: 
{Hi;

I find the RebGUI is good, but how can I find the help document for 
the use of this package?

the wewpages in the website donot tell people how to use his software.

How to find the detalied documentation for VID? like how to build 
botton, box, drop-list,combo list?

It seems Rebol is weak in teaching people about how to use the GUI.

Normally people like to learn software quickly, so a good help documentation 
is always welcome.
Thanks,
>>

Can someone give me a useful list of URLs to pass on to the enquirer? 
Thanks.

Maxim, Henrik: I agree current DRAW gradients aren't the best solution 
and I'm aware about this issue from the time Shadwolf's requests. 
But this improvement will happen probably once the new 2.7.x release 
merge get to more stable state. As you might know Carl don't want 
to add new features until 2.7.x is at the same level like 1.3.2.

cyphre, I realised that drawing two shapes and using alphas to blend 
between them is the best additive method so far... its obviously 
a little bit slower, but at least it looks good.

How to find the documentation for the use of VID and RebGUI

 How about Desktop|Demos|EasyVID? Sounds like he wants a step-by-step 
 introductory tutorial. I'll think about how I can address this need 
 for RebGUI (my site makes the assumption that people are somewhat 
 familiar with VID already). Thanks for the heads-up.

Thanks Cyphre and Ashley......I should of course have asked in the 
!RebGui group

Maxim: I agree. There should be more info about the arguments. And 
yes, the need for 3 colors is just because the current gradient interpolation 
uses curve (this was some default AGG code we have used for DRAW 
but  now I think it would be better to rewrite it from scratch. The 
new code will use linear interpolator among other changes.)

re your wish: I'll try to add 2 color arg possibility. At the moment 
as a workaround you can easily compute the 'middle' value and use 
3 args insetad.

thanks for the heads up... If you are going to rewrite it... please 
allow more selections in this kind of thing... curved interpolation 
IS much better, for things like shadows, for example... but the need 
to select filter types (from all available... not just one or two), 
interpolation curve types, start-end snap on beziers, things like 
this are all essential, if we want to allow the next REBOL to be 
able to properly compete.  


defaults are good and often this is all that is needed, but for any 
graphic app, this quickly becomes essential (as you will agree, on 
your own usage), and is a weekness of current toolset.

the other big weekness is our inability to extract any kind of data 
from the AGG computed visuals.  cv info (for a text curve, for example... 
to match a graphic to its corner) , curvature data (length, coord 
+ angle at offset,  etc), box size, centroid (for quick searching 
of  computed visuals), all of this is vastly faster (we are talking 
like 10000 times or more here) when done in binary and available.

yes, the new gradients will be even more configurable. Regarding 
the access to the AGG  internal representation. I have talked about 
 this with Carl and we agreed in R3 it would be allowed to do functional 
programming of DRAW blocks. But all this needs more thinking...

A style a day keeps the doctor away:

New idea for a style: A "FLATTEN-PANEL" is a PANEL which "explodes" 
its
pane directly into the parent face's pane. eg:

A normal PANEL and resultant face hierarchy:

	layout [
		panel [
			label
			field
			check
		]
	]

	window
		panel
			label
			field
			check
	
A FLATTEN-PANEL and resultant face hierarchy:

	layout [
		flatten-panel [
			label
			field
			check
		]
	]
	
	window
		label
		field
		check

Implementation and test:

	view window: layout [
		style flatten-panel PANEL with [
			append init [
				foreach face pane compose [

     face/offset: face/offset + (do bind [where] first find second :layout 
     [new-face:])
				]

    append get in get first find second :layout [new-face:] 'pane pane
				clear pane
			]
		]
		
		at 500x200
		flatten-panel [
			label "hello"
			field
			check
		]
	]

with presets and a bg mode which asks you what you are doing...

ins, del, home, end, pgup and pgdown have the same problem

When is the next release, by the way ? I ask because we keep stumbling 
on this same bug, and I think it's an easy one to fix, judging by 
how fast those other string bugs were fixed.

I would like to know that too. A program I'm making has a timer mechanism 
where the program must be active all the time and I want to display 
an alert if the window gets out of focus.

If only one, it's easy - just trap inactive event.

If more than one, and since you are running a timer, you can track 
the state of all windows and react when a timer event comes along 
after an inactive event which was not followed by an active event.

I discovered a problem when closing the first window which has RATE 
set. Now time events no longer flow and so the state isn't detected. 
But it is solved by catching the close event and setting RATE in 
a second window.

I handle this by patching the wake-event func and checking if the 
screen-face/pane has any faces within (which is the pane which holds 
the windows).  when ever this happens, it means all windows are closed. 
 and so I quit with none which disables the do-events.

hum. isn't it possible to have decimal rates?  I just tried using 
0.5 and am getting no 'time events. is this normal?

Gregg, I'm working on that way now. For minimal impact, I only start 
time events if they aren't running already, and then I restore the 
window/rate after I catch the first time event.

This version uses the "deadman switch" timer idea and is working 
ok.

do http://anton.wildit.net.au/rebol/gui/demo-all-windows-inactive-handler.r

The reason I need this is for a pop-menu system (implemented with 
windows). When a completely different application window becomes 
active, I want to close all menues and submenues.

And it seems to be working for this application.. :) Now the long 
test...

oh no it's buggy. it works sometimes and sometimes not. Damn, time 
events are tricky.