AltME groups: search

I ruined the AREA engage function. You have to implement the original 
also. The source can be reached with:
layout [a: area]
e: get in a/feel 'engage
source e

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.

Do we need a "User Interface Style Guide"? It may be part of the 
wikibood. I came to think of it when revising some of my scripts. 
I often program the key "Q" to be used to quit my scripts. But maybe 
it should be <ctrl>-q to quit, like it is with AltME!? Then I thought 
about, if anyone of you has made a style guide regarding user interfaces 
in REBOL? REBOL/View is made for different platforms, each with their 
own style guides. Should we stick to those guides, so our scripts 
have to use different keyboard shortcuts on different platforms? 
No, probably not! A REBOL script should work the same across all 
platforms, I think. Then we need a "User Interface Style Guide", 
so us developers can stick to the standard when developing REBOL 
applications, shouldn't we?

Geomol - such an userguide, would be usefull, because first all usage 
schemas would have to exist on the paper first. It would be clear, 
we first have to think, because it would be even clearer, that new 
VID without things like proper focus system, keyboard support, etc. 
- is a no go ....

I several times posted Gnome usage guide as a reference ...

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).

the first item is sitting a pixel too high.

Sounds like a font rendering bug.

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.

It's a bit weird. I had thought, code to control these things were 
the same on all platforms.

anyone know the algorythm by which I can convert raw event/time values 
(an integer which seems to be in milliseconds) into a time value?

i use the above function to resize images but it leaks on 1.3.2.4.2 
 Am I doing something wrong or is it a bug ?

You might ask rambo group about it being a bug.

actually moving the space between the buttons to -1 might improve 
the visuals a bit

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

anybody made a VID text area that can handle large amounts of text 
without spending minutes to display the face?

That's a good question.

to get it precisely, it would be a matter of calculating the number 
of lines based on line height. A little more difficult if you are 
wrapping text.

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

using scroll offset, window width you can select a line of text immediately.

using parse you can also break up a big text pretty quickly.  but 
you need to have a way to re-assemble the text later on, when you 
export the face's data.

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.

this is direct REBOL useage...  a simple  loop using native rebol 
calls.  no fancy code... so it really is RT implementation which 
is ugly.


they should have made a native which returns a block of  lines directly 
using a face

Oldes.. thats not a very good editor then ;-)

Using Ultra edit I've loaded a 400MB one line file.  :-)

In 2005, I developed an simple English sentence parser in REBOL. 
It was a small experiment. It didn't support much grammar yet. The 
screen shot is here. http://city.udn.com/v1/blog/photo/photo.jsp?uid=JerryTsai&f_PHOTO_ID=471974

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

Maxim, yes. It took me a lot of nerve to show them, because they're 
just semifinished.

but they are both very impressive.  when looking at your font output, 
we don't even realise that all of that is draw shapes!  you've coded 
your own font engine.. its a pretty cool result.  They look like 
high-quality system fonts to me!

maybe the system:// port will receive a windows message.. not sure.

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.

Hi!
How to keep selection after show for text-list?

F.ex. code changes text-list data, for selected row, than after show 
a-text-list, selection of selected row disapears.

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?

Wow! What a revelation. It looks like REDRAW is called first, then 
SHOW, then DETECT is called.

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.

I remember having a hell of time trying to resize the window properly 
without it causing a cascade of resize/show events...

(where talking a few years ago so my memory is rusty)

If you type in a field, then press TAB it prints "validate" - Good.

if you type in a field, then press SHIFT-TAB, it does not. - Bad. 
<----

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.

So I might make a RAMBO bug report on that.
Anyone have any comments before I do ?

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.

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 your solution using REFOCUS is a good one.

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.

There should be a ton of placeholders inside the feel code, to let 
you easily set those placeholders from within layout. I know this 
is possible to do.


view layout [field 100 single-key-action [print face/key]] or something

LIST-VIEW has a lot of different actions that let you set what it 
should do in particular situations easily. Every single VID element 
should have that. In fact there should be an abundance of placeholders 
for actions, every one that we can think of.

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.

Maybe we can make a dialect which maps the simple representation 
you've suggested above into an actual working FEEL.

1. You have direct event handling with on-XYZ [do-program-code]

2. Then you have dynamic flags for, say, qualifier keys inside that 
program code, from the event system

3. Then you have face flags. Some things like size limiting a field 
should be simple. It can _probably_ be mapped to 1.

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

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.

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.

basically, each event is passed down a stream which applies the event, 
changes it or even creates new events out of it.

you can have a special node in the stream which replaces certain 
strokes with others... executing macros, or inserting a whole stream 
of text, even if the app doesn't really support it.

so you could insert the clipboard right in the inputs instead of 
having to support it explicitely in the various face styles... as 
a high-level example.

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:-)

I built the stream using a purpose built liquid node.  liquid is 
a generic core reference for dataflow programming.

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 propose a very simple enhancement to BTN to the official VID to 
allow the inclusion of images directly via layout. It adds 7 lines 
of code to the BTN init: http://hmkdesign.dk/rebol/img-btn/img-btn.r

Please study the source for commenting/enhancements. Thanks.

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?

Is there a work-around?

It's the same in Linux, too - just came across it a couple of weeks 
ago

*a couple of days ago

Geomol, here is a fix:

We should have checked RAMBO database - Romano posted this one three 
years ago
Do not detect hot-keys when a focal-face with caret is active
http://www.rebol.net/cgi-bin/rambo.r?id=3372&

ok... the examples after give a few clues...

hum... is it just me or should the minimum colors needed for the 
gradients be 2 ... is there really a reason why we need to put 3 
colors?  its seems like it messes up most of the fills...

hum... a yellow green blue gradient  give me a ring of BLACK right 
in the middle... not what I call very precise... maybe cyphre could 
explain the maths behind the gradients so we can understand  what 
we are doing?

somehow, it seems like its missing a color blend mode selection, 
multiply, add, screen, etc. right now its a ramp which fades to 0 
on each side, such that when two successive colors do not have any 
bit in common it creates an alpha channel premultiplication grey 
zone...

since you've played with it a while.

no, it took a lot of fiddling to get things right. I only played 
a bit with Gradient Lab, but it's not very flexible.

I think Gradient Lab should be made into a useful tool, rather than 
just show off gradients.

I'll build a few usefull nodes in liquidator... its almost ready 
for a first public show-case  :-)  I never thought it would be this 
quick.

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.

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.

once we understand how the values work I guess its ok... there should 
just be a little bit more info on the fact that things like grad-start 
are in pixel distances...  it might seem obvious... but with my background 
in CG I was expecting shape size relative scale.  Its ok, as long 
as the info is made explict  :-)

a wish?  allow two color gradients ... I now understand  the middle 
color is used as a curve to bend the way the gradient occurs, but 
in many case a linear curve is all that's needed. especially since 
we can edit the start/end of the gradient.

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.

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.

Maxim, regarding this: "somehow, it seems like its missing a color 
blend mode selection, multiply, add, screen, etc. right now its a 
ramp which fades to 0 on each side, such that when two successive 
colors do not have any bit in common it creates an alpha channel 
premultiplication grey zone..."

blending is not a part of gradient definition, look at Flash or SVG. 
Gradients work the same as in Rebol inthis case.

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...

is that 2.7? that is a bug, will be fixed in next release.

there's a bug with 2.7 where event/key, when it should be a word, 
is wrong

Does anyone know a way how to detect when all rebol windows are inactive 
(ie. because a non-rebol window became active) ?

I can trap inactive events sent to a rebol window, but I want to 
know whether that was because another rebol window was activated 
or a non-rebol application window was activated.

If it is a rebol window, that window gets an active event --- but 
this is *after* the previous inactive event.

another window in the same rebol process or a differen rebol process?

I need something like a "none-active" event that lets me know when 
all rebol windows are inactive.

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.

Probably that's my solution too - run a timer.

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.