AltME groups: search

Precedence of ** is higher than /
The right form should be (1)

Ah ok, then you need to convert the word to a series, for example 
a string, and check on last letter:


parse [some word! other* stuff'] [some [set word word! (print last 
form word)]]

R3 but obfuscated.

match: [
	  some [thru #"-"] skip end 	(print [w "end with -?"])
	| some [thru #"*"] end		(print [w "end with *"])
]

parse  [
	word-a 	"ere" 	835 	word-b 	15
	word* 	w86	bullshit*	#doglieru3 	word-c
][
	some [
 		  and change set w word! [(form w)]
		  change [do into match | skip] w
		| skip
	]
]

Here's the R2 version of TO-CSV and TO-ISO-DATE (Excel compatible):

to-iso-date: funct/with [
	"Convert a date to ISO format (Excel-compatible subset)"
	date [date!] /utc "Convert zoned time to UTC time"
] [

 if utc [date: date + date/zone date/zone: none] ; Excel doesn't support 
 the Z suffix
	either date/time [ajoin [

  p0 date/year 4 "-" p0 date/month 2 "-" p0 date/day 2 " "  ; or T

  p0 date/hour 2 ":" p0 date/minute 2 ":" p0 date/second 2  ; or offsets
	]] [ajoin [
		p0 date/year 4 "-" p0 date/month 2 "-" p0 date/day 2
	]]
] [
	p0: func [what len] [ ; Function to left-pad a value with 0
		head insert/dup what: form :what "0" len - length? what
	]
]

to-csv: funct/with [
	"Convert a block of values to a CSV-formatted line in a string."
	[catch]
	data [block!] "Block of values"
] [
	output: make block! 2 * length? data
	unless empty? data [append output format-field first+ data]

 foreach x data [append append output "," format-field get/any 'x]
	to-string output
] [
	format-field: func [x [any-type!]] [case [
		none? get/any 'x [""]

  any-string? get/any 'x [ajoin [{"} replace/all copy x {"} {""} {"}]]
		get/any 'x = #"^"" [{""""}]
		char? get/any 'x [ajoin [{"} x {"}]]
		scalar? get/any 'x [form x]
		date? get/any 'x [to-iso-date x]

  any [any-word? get/any 'x any-path? get/any 'x binary? get/any 'x] 
  [
			ajoin [{"} replace/all to-string :x {"} {""} {"}]
		]
		'else [throw-error 'script 'invalid-arg get/any 'x]
	]]
]


There is likely a faster way to do these. I have R3 variants of these 
too.

Yeah, blocks for cells are so far outside the data model of everything 
else that uses CSV files that TO-CSV was written to assume that you 
forgot to put an explicit translation to a string or binary in there 
(MOLD, FORM, TO-BINARY), or more likely that the block got in there 
by accident. Same goes for functions and a few other types.

dunno if it's faster but to left pad days and months, I add 100 to 
the value and then do a next, followed by a form ie. regarding you 
p0 function

eg. next form 100 + date/month

Be careful, if you don't quote string values then the character set 
of your values can't include cr, lf or your delimiter. It requires 
so many changes that it would be more efficient to add new formatter 
functions to the associated FUNCT/with object, then duplicate the 
code in TO-CSV that calls the formatter. Like this:

to-csv: funct/with [
	"Convert a block of values to a CSV-formatted line in a string."
	data [block!] "Block of values"

 /with "Specify field delimiter (preferably char, or length of 1)"
	delimiter [char! string! binary!] {Default ","}
	; Empty delimiter, " or CR or LF may lead to corrupt data
	/no-quote "Don't quote values (limits the characters supported)"
] [
	output: make block! 2 * length? data
	delimiter: either with [to-string delimiter] [","]
	either no-quote [
		unless empty? data [append output format-field-nq first+ data]

  foreach x data [append append output delimiter format-field-nq :x]
	] [
		unless empty? data [append output format-field first+ data]
		foreach x data [append append output delimiter format-field :x]
	]
	to-string output
] [
	format-field: func [x [any-type!] /local qr] [

  ; Parse rule to put double-quotes around a string, escaping any inside

  qr: [return [insert {"} any [change {"} {""} | skip] insert {"}]]
		case [
			none? :x [""]
			any-string? :x [parse copy x qr]
			:x = #"^(22)" [{""""}]
			char? :x [ajoin [{"} x {"}]]
			money? :x [find/tail form x "$"]
			scalar? :x [form x]
			date? :x [to-iso-date x]

   any [any-word? :x binary? :x any-path? :x] [parse to-string :x qr]
			'else [cause-error 'script 'expect-set reduce [

    [any-string! any-word! any-path! binary! scalar! date!] type? :x
			]]
		]
	]
	format-field-nq: func [x [any-type!]] [
		case [
			none? :x [""]
			any-string? :x [x]
			money? :x [find/tail form x "$"]
			scalar? :x [form x]
			date? :x [to-iso-date x]
			any [any-word? :x binary? :x any-path? :x] [to-string :x]
			'else [cause-error 'script 'expect-set reduce [

    [any-string! any-word! any-path! binary! scalar! date!] type? :x
			]]
		]
	]
]


If you want to add error checking to make sure the data won't be 
corrupted, you'll have to pass in the delimiter to format-field-nq 
and trigger an error if it, cr or lf are found in the field data.

Geomol, to explain it a bit:
LINE - draws single lines (eve if you specify multiple coords)

SPLINE - draws 'connected' lines but the 'head' and 'tail' is splitted 
(until you specify CLOSED keyword)
POLYGON - always draws 'connected' lines in form of closed shape

Hi,
For homework, I was asked about the random number generator in 
my favorite language ... did some experiments but answered 
closed source
 to what "algorithm does it use?" for this part, I got a zero.

So, could someone with access to rebol source or internal doc 

get me information on the algorithms for 'random and 'random/secure

they are probably some flavor of linear congruent generators 
(please don't say RANDU) but multiplictive?  or mixed?  
maybe a PMMLCG? shuffling? QCG? MRG? What constants are used? 
what is the period? how many streams? 


The easiest on you would be just send me the source and let me figure 
it out 

but is that is verboten as much detail as you may send to me (privately)
would be appreciated 

note: the information will only be seen in a distilled form by my 
professor
and not kept by me.

thanks Tom

Without SDK, I can't upgrade, most of my apps are used in encapped 
form.

I'm in the "make it flexible" camp. BrianH, does the new FORM-DECIMAL 
look useful for inclusion in 2.7.8? We may need to add different 
separator notation.

Anyone who is directly participating in the development of R2 is 
in chat - that's where the source is submitted. That doesn't rule 
out indirect participation though, in the form of forwarded fixes, 
feedback, advice, bug tickets, whatever :)

just tried a read, and when the second form of graham's test (using 
to-url on a string) the url parser doesn't dehex... so the username 
will be invalid.

R2 is important for other reasons, but not as much for that reason. 
Most people don't buy R2, even in SDK form.

but you won't be able to notice the difference in things like form.

tombon:  the thing is that rebol has to map its datatypes to the 
basic and static data representations of C and other compiled languages. 
 the R2 tried to do this within rebol, but it ended-up being useless 
for many libs which used types that rebol cannot translate natively... 
like unsigned integers or single precision floats, arrays... etc.


extensions do the rebol datatype conversion in the C side, so that 
it can directly map ANY C code to a form that rebol functions can 
understand directly  and vice versa... so for now we could use blocks 
as an interface for structs, even though R3 doesn't understand anything 
about structs.  :-)  


Its MUCH faster to map in C and makes the lib completely integrated 
into REBOL when used.


So for example, we can use tuples as colors within REBOL, and the 
DLL's functions will be called with a struct  or an array, to map 
the 3 channels.

Re #6156: Pekr, we ARE NOT giving up on dialects!! There are many 
dialects in RE
BOL, and it is one of the main concepts.

What we 
are doing is removing the strong overlap in DELECT and COMMAND. If 
you l
ook at the DELECT method, it is a small subset of full dialects. 
It implements a
 form of function with optional arguments.

So, it's 
better to move that code into COMMANDS, and allow them to work that 
way
. This makes it much easier for people to learn and use. Even 
me!

Also, REBOL/Services will use this same method, because COMMANDS 
are not limited
 to just extensions... ah the secret is out: COMMANDS 
can also be attached to a
context, making them generally useful in 
REBOL code.

I will check the blog comments to make sure it's not 
misunderstood.

jocko,  yes and no.   ;-)  


Glass is going to be rebol code only, but its going to be based on 
rebogl, the OpenGL extension I am currently working on (as I write 
this).  Rebogl its going to be an evolutionary process, starting 
with simple high-level pre-defined primitives and colors and then 
will get more and more customisable (deformers, animation, textures, 
programmable shaders, etc).


I am still not sure how the Glass engine will evolve, but there is 
a good chance that it will be based on the scene graph technology 
I am working on for the Scream game engine.  This has the benefit 
that Glass can be used to build the interfaces within the games themselves. 
 But it most definitely won't require you to load a complete  (and 
inherently complex) 3d world manager, just to build a window with 
a form.  if possible, I'd like to have window masks, so that the 
3D forms can actually live like 3d models direclty on the desktop... 
so some of the nice 3d feature isn't wrapped within an OS window 
border.

yes, shared memory with threads (if this is how R3 currently does 
it) always requires some form of locking.


again, the GC would need to cooperate in this process... maybe having 
explicit locking or semaphores, just like the Amiga did it.

Most of REBOL's memory usage is that data. The mezzanine code is 
that data. For that matter, I am being asked to implement delayed 
modules so that non-native code can be shared in its source form 
for as long as possible, delaying loading it into regular REBOL data 
unless absolutely necessary.

It's quite clear, what it should return, when you see it in REBOL 
like form, but it's quite difficult to do such a decision when parsing 
the spec.. that's also the main reason, why I decided to work on 
human readable dialect. (I was trying to generate the extension directly, 
it's possible, but it seems to be hard to maintain.)

never mind... this is just a minor detail. Form me is important I 
can decompress zlib data as I could with R2. That's all.

Not all apps are form-based. Some are document-based.

One of the other original motivations for strong theming support 
was to get the theming sites around the internet involved. Challenge 
them to come up with good themes. Their efforts would market REBOL 
as well. But disabilities, other form factors and other situations 
are a factor as well.

sure:


Robert - DB interface, messaging, state machine, cracking the whip
Cyphre - Resizing, low level AGG, rich text, host kit interface

Me - Dialogs, form validation, database interface, reactors, messaging, 
state machine help system
Bolek - Styles, resizing
Ladislav - Resizing, state machine


The above is basically what needs to be done for the first customer 
app.

Graham:


First prototype ready for review: DB interface, resizing, form validation

Coding: State machine, styles, messaging, reactors, dialogs, low 
level AGG, host kit interface
Pending: Help system

http://rebol.hmkdesign.dk/files/r3/gui/232.png

Slightly more meaningful display of form validation.

so once again: complaints about issues that have no relevance to 
the current state of the R3 GUI. I would rather have wishes for dialog 
handling, form validation, how the help system should work and how 
to build more intelligence into the GUI.

Our primary concern is that RM Asset needs to use R3 very soon for 
a production app for a customer, so the focus is to make all things 
that are normally handcranked in VID and RebGUI, such as form validation, 
handling of database records and a complete UI test framework fully 
automatic. If it takes 2 days instead of 7 to build and test a GUI, 
Robert saves money and can ship earlier.


Over the past year, with the rather big RebGUI app, NLPP, that RM 
Asset has built, we've learned exactly where we need to make things 
better and what works OK and certain delays, because of GUI architecture 
limitations have cost money. It's no longer for convenience or for 
advertizing the GUI as easy, but hard money savings are involved.

I see this 

ts: text-box (form now)

what functions? form validation related you were talking about earlier? 
OK, do you have anything to test, including some basic instructions? 
If so - send it in ...

Probably a bit different topic, albeit related - in one DOS app generator 
I worked with, there was a possibility to e.g.:

- init form values (e.g. when you create new record)

- set 'update trigger - you could have multiple update actions (it 
was quite primitive, but sufficient - operators like +, -, replace), 
so e.g. entering some value into 'amount field, could trigger an 
update into other field on the form, or later during the commit, 
to even a different table.

- getting/setting values of the form/panel is surely going to come 
IIRC

Henrik - the proposal does not need to alter the style, right? That 
is indeed good. But - I still have to think about the form design 
- do I have to count for the space for the validator? I talk about 
some alignment stuff ...

if your form is very large you will appreciate the need for consistency 
as you only have to check for red Xes to see where the problem is, 
and the validation system also automatically focuses the first problem.

btw - back to my DOS app generator (Clipper + Zachary) :-) There 
was one other interesting feature. Let's say you have an invoice. 
And you have field to enter a company. That field is validated against 
customers table. There was a validation option named 'must-exist, 
may-not-exist. That way user could either enter new value, or only 
choose from existing values. But - the customer table was not probably 
a good example. 


And then - each grid/table had options too, called AED (Add, Edit, 
Delete), plus option, if you allow ADD option caused by validation. 
Example - you enter customer name - it is not found in customer table. 
If you allow 'Add option for grid, when user entered new customer 
name, and not found, it automatically popped-up a form, to enter 
new customer. If 'Add option was not allowed, then the person had 
to call someone, who had rights to enter the data directly into Customer 
table ... well, probably confusing description :-)

It looks like the feature for keeping several draw blocks in the 
same style was removed or changed by accident. this means that the 
validation icons won't work, so I have to find a different way to 
test validation. I want to separate the dialog code from validation 
and then make a proper validation test window, so you can look at 
the code and see how it works.


Furthermore, there is a database extension, I want to test more: 
Parts of validation (the scoping part) was inspired by this one and 
I think it would be good to get this out in the open, as it can be 
extended either to a file database or any SQL database by the community. 
The point of it is to make it very simple to connect the logic of 
a form to a database record and it works a bit differently from setting 
up a regular form.

I find it easier to use many gobs for many styles... especially when 
mixing different gob types to form a single face.

sort of, yes. write a form and add a few keywords and you can add, 
edit and delete records in a db.

A basic example of how it looks right now:

f: view [
	form-panel: panel 2 [
		group 1 [
			title "Record fields"
			bar
			group 2 [
				label "Name"		name: field		; stored as name
				label "Address"	address: field	; stored as address
				label "Age"		age: field		; stored as age

    label "Skipped"	skip-field: field options [skip: true]	; not in the 
    list
				label "Ignored"	field			; not in the list
			]
		]
	] options [record: 'rec]
	group 6 [
		button "New" obtain 'form-panel add-record
		button "Save" emit 'form-panel update-record
		button "Delete" do [delete-record]
		pad
		button "<" obtain 'form-panel next-record
		button ">" obtain 'form-panel previous-record
	]
]


The 'rec is a record object, which is filled with data from the server, 
using the backend function, and when submitting, is used to gather 
data from the form and into the server.

RIF is RIF, let's wait for RIF, and not use pseudo dbs! Apart form 
that, doesn't Robert have SQLite for R3?

What if I don't care for your validation, your DB reactors? What 
if I am used to work with form and db my own way? Will I get one 
bloated gui? Carl was very picky for each single function to add, 
and now we are adding whole layers upon the GUI, which is still far 
from being finished.

btw - would it be (let's say later in the process) possible to introduce 
some other form of release? I mean - I would like to look into sources, 
but it is flattened recently.

I don't want to push you to Tortoise, etc., but there surely be some 
distribution form of the GUI? I mean stuff separated in files, etc. 
It helps studying some stuff

You have some rules that you need to follow in any framework, otherwise 
they won't work for you. In the case for, for example db reactors, 
you need to know about the specific options, the rule that fields 
must be named for them to be used and how. But really, there are 
only few rules and once you've worked with attaching database records 
to a form, in a manual  way versus this way, you probably don't want 
to go back.


The other thing is an illusion of control with absolute flexibility 
without a framework. It simply lengthens development time and introduces 
bugs (something that we keep overlooking, eh?), and generally keeps 
the customer unhappy.

You are trying to tell me, that DB record linkage to form is dependant 
upon certain naming of the fields?

Direct link of form fields to db rec is imo the worst illusion I 
have seen :-)

Area style report:


1) hilite some few chars, then you click elsewhere in the text, or 
just move the caret using arrows - the text stays hilited, whereas 
default OS behaviour is, that the hilite is discarded. The question 
is, if we are targeting for REBOL specific behaviour, e.g. allowing 
to move caret, and have multi-hilte areas? I think not.


2) hilite autoscroll works chaotically. Sometimes it scrolls the 
area, sometime it does not. Dragging the mouse outside the window 
does not work at all.


3) scroll by mouse-wheel. When I reach the "bottom" of the area, 
I loose my focus, and scrolling back up does not work


4) moving up/down by arrow. It seems that in OS native widget (Notepad), 
the caret position is counted by the follow-the-leftmost-tex-length 
rule. So if I e.g. go via an empty line, caret should stay at the 
beginning of line for all other rows.

5) cut and paste into Notepad discards newlines


6) cut and paste from Notepad inserts text in hilited form - random 
behaviour here, ot it needs more observation ...


7) hilited text should be deleled by hitting delete, backspace, or 
by typing any character

8) when hiliting the text by mouse, scroller gets reset to 100%

Is that enough bug-reporting for the starter? :-)

btw - why field style metrics are so wrong? Sometimes I can see proportionally 
too big fields - e.g. Facebook main page. And new R3 GUI uses too 
thin field. Look at old R3 View demo, section 'Form, how nice it 
looks :-) I just hope it is just question of some tweaking :-)

Yes, so the only thing I miss now is, that scroller could be placed 
on the form, not doing anything :-) Or how would you do style browser, 
for IDE purposes for e.g.?

good then. One other thing - I am seeming table related styles there, 
which surely are not displayable on their own, yet those are legitimate 
styles - table-row, table-cell, table-header ... that is why I think 
we really need get-styles or similar function, which depending upon 
the tag, would get you list of only ready-to-use on the form styles 
... but that can come later ...

Henrik - generally - do we have per-field validation, or per-form 
validation? I e.g. don't like systems, which lock me inside a field, 
untill I correct it. I hope it is the latter :-)

The scope is whatever you want to validate, whether it be a field 
or a whole form.

What I hate most about validations, is sometimes their strictness. 
I would break anyone's hands, who pushes me to write a phone number 
to some "standard". The phone number is used by humans anyway, and 
even then, it can be still parsed even by automat. My number is +420-777-172 
171 .... I choose my own format for the readability purposes, and 
I hate, when the form blocks me :-)

If I want to allow both empty and only-chars, then I have to explicitly 
express that. But only-chars itself has to fail on an empty field, 
no? Maybe I am just wrongly guessing something from the validation 
test example form field descritions ... I will wait for docs ...

to each of those tools there is a auto generated form that you will 
feel to set up your function arguments

Current list of tags (subject to change):

; set at stylize time
style-tags: [
	internal		; the style is intended for internal use
	panel			; the style is panel of other faces
	compound		; the style is a compound of part styles
	field			; the style is a field with editable text
	state			; the style is a user interactive state changing item
	action			; the style is a user interactive action item
	info			; the style is an indicator
	tab			; the style is part of tab navigtion

 auto-tab		; the style automatically tabs away on a specific event
	select			; the style contains user selectable text

 keep			; the style retains highlighting and caret after unfocusing
]

; set at layout and any other time
face-tags: [
	default			; the face is the window default
	focus			; the face is in focus
	disabled		; the face is disabled
	frozen			; the face is frozen
	dirty			; the face is dirty
]

; set at window creation time
window-tags: [

 form			; windows containing a validatable form or other field or 
 state faces

 inform			; windows containing only text or images and no validatable 
 faces

 popup			; windows containing a menu or selection, which when interacted 
 with, results in immediate return of a value
]

Guys - what is the reason of kind of slow R3 GUI progress? At least 
from external observer point of view? That is not complaint nor is 
it any kind of attack. It is just that I thought that you need R3 
GUI for a commercial project? And from external pov we could see:

- new resizing system
- some new higher-level systems (validation, tabbing/focusing)
- some news about low level tweaks
- Cyphre posting REP about new possible rich-text system
- some endless work on styles


However - from external point of view, and unless it all plugs together, 
Carl's original VID felt more concrete, more complete. Is there any 
estimate when stuff will plug together to form usable system? Simply 
put - maybe if system would be docced, ppl could start working on 
additional styles? Or is it still too early, and non-yet-finished 
subystems could break any such code?

My whole point was, that Carl took some rewrite route back then, 
and in 2-3 months timeframe produced kind of basic, but working GUI, 
which could be demoed by 'demo function of R3, while with R3 GUI, 
we are not there yet. I don't need to be pointed out to such facts, 
that 2 years old GUI apparently does not work with latest R3 builds 
:-)


Also - "you can wait ... or be active on your own ..." is not an 
argument for me. Noone apart from maybe 1-2 guys here want to work 
on yet-another GUI project. The whole thing is about me (and maybe 
others) not seeing a "big picture" - things plugging-in together 
into useable form timeframe. I know that giving any terms is very 
tricky, but my point was not to get exact nor even estimated date 
- just some rough ideas about what's still left to be done ....

What's left (not necessarily in order):

- test framework for GUI
- dialogs
- form validation, which meshes with dialogs
- help system, which meshes with form validation
- database record management, which meshes with form validation
- actor documentation parsing

- better View function that supports initial states for forms and 
dialogs
- some issues with resizing
- work on text editor core
- general style work
- skin comes last


Of course over time we get new ideas or stumble into design issues 
that need to be solved, before we can move on. That's necessary to 
make sure that some future feature is going to be simple to do.


All this is of course separate from hostkit, font rendering, and 
DRAW enhancements.

Henrik - as for higher level stuff - form validation, db record management 
- let's say I don't need it for some simple stuff. How is that implemented? 
I mean - I don't mind supporting code sitting there, but e.g. I don't 
want validation supporting "visuals" being visible on the screen 
for some simple "embedded" stuff? Could such concepts stay invisible?

BTW all the old demos form Carls version can be done in the current 
version so if want to be helpful you can just 'port' all the demos 
and update the docs along the way.

The same goes for default Windows dialogs, and it is imo good behaviour. 
Simply put -enter stays as a default action for the form's default 
hilighted button, unless another button is tabbed. It unifies enter 
| space-bar behaviour for button types. If we stay with current behaviour, 
users might be confused, as enter will fire action on different button 
than the tabbed one. Of course it depends, and I would like to know, 
what is the functionality on non-Windows platform?

But to break it down, assuming you want R3-only apps, we would need
- A native C compiler for the platform

- A rewritten host for the Android application model to support native-only 
GUI apps (are those possible?)
- An AGG port to the hardware/os
- Some tweaks to the event model to support touch and multi-touch
- Some tweaks to the R3 GUI that deal with the new form factor
- A new set of styles that are designed for touch

So my and Ladislav's decission so far:

-use SHOW? hidden | visible | ignored and optional GOB-OFFSET in 
OPTIONS block during layout initialization only (after the face is 
build the valueas are unaccessible in this form)

-use SHOW-FACE face hidden | visible | ignored function in all other 
cases when layout is already initialized.

Ladislav - did not read all your posts here, but as you are here, 
and for me to proceed - how do I "easily" create panel, if I have 
layout stored in a block? Carl's demo uses:

view-sub-panel: funct [
	index
	main-pan
	desc
][
	set 'current-panel index
	set-face desc form pick test-notes index
	pan: pick test-panels index
	unless pan [
		pan: make-panel 'group pick test-blocks index [columns: 1]
		poke test-panels index pan
	]
	switch-panel main-pan pan 'fly-right
]

his

 make-panel used three values. OK, options block is not needed, nor 
 supported right now. Function attributes are now reversed (dunno 
 why, the argument order is not compatible with make-face for e.g.). 
 That is still easily fixable. But now "rma's" make-panel accepts 
 face, not dialect block. I tried to use make-face on a dialect block, 
 but no luck ....

it breaks in the following demo function:

view-sub-panel: funct [
	index
	main-pan
	desc
][
	set 'current-panel index
	set-face desc form pick test-notes index
	pan: pick test-panels index
	unless pan [
		pan: make-face 'hpanel [columns: 1]
		insert-panel-content pan pick test-blocks index
		poke test-panels index pan
	]
	switch-panel main-pan pan 'fly-right
]

Got to go - but - is there anything like vpanl alignment? I got first 
form of demo kind of working (buttons), but the content is aligned 
to the bottom. Also - pressing buttons does not work so far either:


** GUI ERROR: Cannot parse the GUI dialect at: panel 240.100.80 title 
Alert grou
p doc Button pressed! scroller

Yes, it was a test, to isolate the example form layout from the demo 
....

Or I have something wrong in the demo code, not yet fully adapted:

view-sub-panel: funct [
	index
	main-pan
	desc
][
	set 'current-panel index
	set-face desc form pick test-notes index
	pan: pick test-panels index
	unless pan [

  pan: make-face 'vpanel [columns: 1 content: pick test-blocks index]
;		insert-panel-content pan pick test-blocks index
		poke test-panels index pan
	]

	set-panel-content main-pan pan
;	switch-panel main-pan pan 'fly-right
]

view [
	title "R3 GUI Tests"
	text (reform ["R3 V" system/version "of" system/build])
	bar
	hgroup [

		; List of test sections:
		text-list test-sections do [view-sub-panel value main-pan desc]

		; Panel for showing test results:
		vgroup  [
			desc: text-area "Please read the instructions below."
			options [
				max-size: 2000x40
				text-style: 'bold
			]

			main-pan: vpanel [
				text "test" ;doc instructions
			] options [columns: 1 init-size: 280x380]

			hgroup [
				button "Source" do [
					either current-panel [
						view-code trim/head mold/only pick test-blocks 
current-panel
					][
						request "Note:" "Pick a test first."
					]
				]
				button "Halt" leaf close halt
				button "Quit" maroon quit
				check "Debug"  do [guie/debug: if value [[all]]]
				check "Remind" guie/remind do [guie/remind: value]
			]
		]
	]
;	when [enter] do [
;		if quick-start [
;			if spot: find test-sections quick-start [

;				view-sub-panel index? spot main-pan desc  ; for faster testing
;			]
;		]
;		;[request "Alert" instructions]
;	]
]
;[reactors: [[moved [save %win-xy.r face/gob/offset]]]]

The current design is supposed to allow non-GUI-designer programmers 
to specify layouts. Even if you are both the layout programmer and 
the style designer, the work is supposed to be separated. For that 
matter, a proper layout dialect for the types of apps that the R3 
GUI is made for (not games) should be portable to other device form 
factors, accessible, etc. So if you need to be a theme designer, 
do it in the theme section of the app, not the layout. And if you 
need to be picky about the styles, do it in the style section of 
the app, not the layout.

I am OK with min-size and max-size being a little harder limits, 
if the reason they are in the style is because of hard visual limits 
(size of contents and such). The limits on the size of button seem 
a little arbitrary at the moment though. Then again, I keep reading 
articles about applicatons and web sites not working on different 
form factors because of hardcoded limits in their layouts, when their 
styles should be adaptable to match the form factor. This is why 
we are trying to cut down on this stuff in the layout dialect.

There was very long discussion, towards if we should allow to change 
the size of the button to allow any size being set" - did you really 
mean it? One can easily make sure, that the init-size of the button 
is set as specified." - Yes, I meant it, because IIRC there were 
opinions, trying to suggest here, that it should not be allowed at 
all :-)


All stuff you write - I know. It is just that I might not necessarily 
agree with the outcome. I am trying to think form user's point of 
view. I wonder to what points you would agree, and to what not:


- Let's assume I set button in bounds (between what min-size/max-size 
allows): I tried various scenarios, and I almost never got button 
of requested size. The reason is in how resizing system works. In 
fact, when inspecting various sizes - init-size, min-size, max-size, 
those don't contain actual button size. Actual size is in face/gob/size. 
Button gets different size due to resizing system cell alignment 
imo. From the resizing system point of view, it is correct behaviour, 
but from the user's perspective, it is questionable, if the result 
is OK?


- In regards to above point, I really wonder, if buttons should be 
resizable at all. I said - resizable, not settable. I wonder, if 
I would like buttons to be of consistent size. I might try with face/resizes?: 
false, if that would make the trick.


- Then, in regards to above - I might think of init-size setting 
the requested button size


- Maybe (and I am not sure about that one), we could allow some debug 
info - "out of bounds", if my init-size value does not fit in between 
the min-size, max-size, as style author defined it. I have heard 
that guys are working on some field accessor functions - those might 
be able to print some debug info to console, at least when in interactive 
mode.


Othere than that - this one is a minor issue for me, I e.g. care 
more about architecture, and so far I can see materials having real 
low benefit, for how complicated it turns out ...

I have a question towards the aproach to design a form. Following 
code does not work for me (result-wise):

view [hpanel 2 [label "Name:" field button "ok"]]


Simply put - button is on a new row, but it probably causes field 
to align to the right? Or more precisely - button extends the column 
cell, and so the field is pushed to the right in an undesirable (albeit 
expected) manner. Should I put buttons supporing the form out from 
the panel containing fields?

But my above example is some food for thoughts. When I think of forms, 
I know that form might be enclosed in some pane (being it group or 
panel or frame I don't care - just visually separated from the background). 
Then it usually contains pairs of labels and fields. Btw - in R2 
it was easy to right-align label - is that possible with R3 GUI? 
And I think that some buttons belong to the form - e.g. Edit, Submit, 
Cancel, and some might belong to the Window.

I have to look into some forms in some other apps, how they do solve 
visually buttons belonging to form ...

how they do solve visually buttons belonging to form

 - when this works correctly, you will be able to do any visual combination.

or will there be a different solution of inheriting cell-sizes across 
multiple panels? this is for forms where label width is necessary 
to be identical for multiple form parts, such as 4 column forms or 
forms separated vertically by full-width spanning parts.

#[[Pekr:

Does not work for me:


 view [hpanel 2 [label "name: " field hpanel 3 [button button button]]]


The nice thing is, that I do know, what it does not work, and I do 
know that the behaviour is correct, it is just - undesirable ... 
:-)

Pekr:]]


Could you please write it down in a form understandable to mere humans?

I have problem accepting result of examples:

15, 23, 24, 25, 26, and I stop here, probably many others ...


The problem I see is,that I don''t want elements to jump during resizing 
the way it does. Please try form example 15. IMO if we don't support 
scaling, the text and its spacing should not change at all. I would 
expect panel being enlarged, but all it does is the panel moves down, 
and GUI creates space between the header text and the consecutive 
text.


Also - look at example 26 - why the last line of boxes is shifted 
down the window from all the rest of the boxes?

I think the edge/frame/border usage is a little confusing. EDGE was 
a standard feature for every face in VID and it was fixed how it 
worked. In R3, an edge would be implemented on the DRAW level and 
could basically mean anything, including what it means in relation 
to the box model. This is why I'm still advocating a special FRAME 
style, which in *one* place, settles the meaning and the appearance.


Furthermore, a FRAME could be required for any type of face, be it 
a form with many fields, a compound of faces or groups of compounds 
of faces, which need to be surrounded by a pixel accurate frame, 
like in the example below, which I had trouble defining properly, 
when I experimented with skinning:

http://94.145.78.91/files/r3/gui/162.png


I had problems with it, because it had to be part of COMPOUND, and 
yet, certain COMPOUNDs would not have a frame and certain other panel 
types would also require the frame, but not be a compound. It is 
just much simpler to have it in a separate style.

After looking in dictionary on my computer, I'll say contents (plural) 
is more correct english.

The plural form:

the things that are held or included in something : he unscrewed 
the top of the flask and drank the contents | he picked up the correspondence 
and scanned the contents.
The singular:

the amount of a particular constituent occurring in a substance : 
milk with a low-fat content.

In a simplified form:

- the DO-STYLE function will be renamed to DO-ACTOR

- both Henrik and Robert wanted to be able to influence the behaviour 
of actors from the Layout dialect,
- which was not possible yet,
- and was not compatible with the idea of reactors

- therefore, it looks like the best idea to introduce one new Layout 
dialect keyword (ATTACH),
- and allow to influence actors from the Layout dialect,
- making reactors unnecessary

The #1 is IMO very simmilar to #4..it differs just by the form of 
the syntax:

#1 example:

view [
	hpanel [
		box red on-click [print "red box clicked"]
		box blue on-click none
	] on-click [print "panel clicked"]
]

#4 example:

view [
	hpanel [
		box red on-click [print "red box clicked"]
		box blue options: [propagate-actors: [on-click]]
	] on-click [print "panel clicked"]
]

I can still get hard crasches of R3, in various phases:

do %r3-gui.r3
do %examples/run-layouts.r3


Two times I got a crash, when just closing the windows, and when 
at layout #15, clicking in the form. Once I got it with layout #20, 
and once at layout #27, clicking the big red button ...

There is definitely 'something' in the R3 Core that crashes the interpreter. 
At the moment it is very hard to track it without the access to the 
sources or having the debug release of the R3 library. (ie. I was 
able to trace the crash using the debug release of hostkit exe but 
the trace ended in the 'hidden' dll part so the hostkit code seems 
to be most probably out of the game here)

 IMO it has nothing to with the graphics part(unless there are 2 separate 
 bugs ;)) as I was able to crash R3 when writing non graphical script 
 as well. The crash is very hard to reproduce as it occurs only with 
 specific form of the executed script. If you change some line or 
 even order of words etc. the script works just fine.

It looks to me  either some GC or other memory allocation leak issue 
and have suspicion it have something to do with the map! datatype 
(but this is just my feeling).

some servers are anti-indexing and its in these cases where the brute 
parse is most effective.  I've even had to cater an oracle web server 
which didn't have ANY css, type, or id fields in all pages which 
are driven by form.  all urls can only be read once, and every page 
read is a redirect.   


only parse allowed me to cope in such a drastic anti-robot  environment. 
 it still took a day to build the robot.  and in the end, it even 
had an auto-user-creationg step at each 200 pages which created a 
google gmail account for the next batch.  :-)

in those cases, parse is king.

there is a mold-tree function in %mezz/trees.r if you want to mold 
the tree. Or, you could simply use form-html to pretty print the 
tree for you.

Eg. for your first example:

t: load-html p
print mold-tree t


[root [] [html [] [head [] [title [] [text [value "t"]]]] [body [] 
[h2 [] [text [value "HEADING"]]] [p [] [text [value "first para"]]] 
[p [] [text [value "second para"]]]]]]

print form-html/with t [pretty?: yes]

<html>
    <head>
        <title>t</title>
        </head>
    <body>
        <h2>HEADING</h2>
        <p>first para</p>
        <p>second para</p>
        </body>
    </html>

(the pretty? option to form-html is something i only use for debugging, 
so it's not as pretty as it should be i guess)

Also note that:


>> print form-html/with load-html "<p>A paragraph!" [pretty?: yes]
<html>
    <head>
        <title></title>
        </head>
    <body>
        <p>A paragraph!</p>
        </body>
    </html>

does it have some form of AA?

I know... but it can be generated in a redable form, cannot be?

...and is released in its working form. That first part is covered 
already.

-- New types as pluggable modules (literal form accessible)

once we have ssh on r3 (in whatever form) I think we should be able 
to build the entire git toolset with REBOL at a fraction of msys 
stuff.  I already did a complete source control system (though with 
a completely different model) called distro-bot and its hardly 1GB!

(And yes, even plain msysgit comes with minimal, optional explorer 
integration in the form of "launch a git shell here" and "launch 
git gui here", if I remember correctly.)

So, to be clear, and according to the other notes posted above, when 
I make my changes, they will form a new repository??

I am trying to determine whether it would be acceptable to replace 
== with =? in decimal code where exact comparison is needed. Otherwise 
we would need to switch to prefix form if this proposal goes through, 
which math people don't necessarily like, or come up with operators 
for the equiv line.

The internal representation of the Document is the hard point.
Incremental parsing means caching some infos during parsing.

What to cache, what not to cache, and in which form, that is the 
question.