AltME groups: search

I haven't either

For that matter, we probably don't need  the rebcode! placeholder 
type either.

In either case, compiling REBOL requires thinking about REBOL and/or 
compilation differently, and trying to do so would push the envelope 
of compilation as a subject. And thus would make an interesting project 
:)

AFAIK, it supports most of the math, loops (loop, repeat, if...), 
conditions (if, either...).

I commented the struct part and than it works. So either we need 
to give it a name, which will result in a ->struct_name.series sequence. 
Not sure if this makes any difference instead of just putting the 
members into the union.

It's the dispatch. Right now with extensions, when you make a command! 
it makes a function that is dispatched by a function in the extension 
based on a number (which you can think of ay a key), to code that 
handles the command (the value associated with the key). In theory 
this is not that different from an object! grabbing data from one 
of its slots based on the keyword you pass it. Apparently commands 
will be able to dispatch to objects soon, and the functions assigned 
to slots of that object will handle the command code.


The DELECT dialect model was based on rebcode, mostly on its JIT 
binding. DELECT added the out-of-order, possibly optional argument 
handling to the dialect decoding phase, but the dispatch phase was 
mostly left out (I commented on this at the time). The command! type 
has the dispatch model, but uses the function call model for calling 
the commands. The overlap that Carl mentions is in the mapping of 
keys to command handlers.


If you unify the command mapping models between DELECT and command!, 
then that code can be shared. This means that the DELECT function 
could do the out-of-order dialect decoding, then dispatch the operations 
as commands. Values of the command! type would continue to be called 
like regular functions in DO code or by APPLY, and then dispatch 
using the same dispatch code as above. On the other end, commands 
would either dispatch to objects (including modules perhaps) or extensions.


By the sound of it, this might also allow the command! type to serve 
as a method pointer, but we'll have to wait to see about that :)

They don't have to be network or file port types either :)

to get something like /library in R3, you'll either need to write 
some platform specific code or use something like dyncall or libffi

Robert,  even if you know the function arguments, how do you call 
the function itself?


the extension will be compiled, so we can't create generic function 
calls.   The calling convention is part of a function's compilation 
process, on Windows any DLL may have three different argument passing 
methods simultaneously!!


get the problem is that you have to push arguments on the stack and 
retrieve them.  there are NO C functions which manipulate the stack 
directly.  these are always done via assembly, either inline or libraries.

No, as there is no hostkit release for either of those.

Without CMake, those steps would be the same, except for the extra 
installation of CMake and the generation of a local build script. 
But it would also either limit the user to a single toolchain (such 
as MingW, currently) or you would need to replicate some of the functionality 
of CMake in your make-build.r

If you are adding a module to the module list, and there is an existing 
module of that name, then the new module either overrides it, replaces 
it, or doesn't get added (possibly with an error triggered, but so 
far not). The question is which one to do in the particular circumstances. 
The factors are whether it is the same module, for whatever "same" 
means here considering it might be reloaded or still source; whether 
the versions are the same or greater; whether the existing module 
has already been made or is still source, and the same for the module 
to be added.

Whether Spread would be right for REBOL is another matter though 
it would offer a limited  alternative for secure inter-process communications 
with non-REBOL processes without having to resort to either cgi or 
"roll-your-own".

ChristianE - either post on R3 Chat, or post to Robert - he might 
be the most direct channel to Carl, so I think you might get your 
answer faster that way ....

Does work for me on Linux A110, does not work for me on Win32 A110 
either.

since my issues where related to heap memory corruption, I'd guess 
either we are using the commands improperly, the includes are not 
reflective of the actual internals, or the internals are causing 
the heap corruptions themselves.

Will need more investigation. Either RL_SET_VALUE never worked, but 
I guess someone would have noticed. Or the minimal sample is missing 
something (more or less obvious).

All value slots are either in blocks, objects or function contexts 
(using the generic terms). There are no free value slots.

why prevent them from accessing the feature?  if the rasterizer can 
work on either directions, I think all gobs should have the capability 
to control this.  they would simply inherit the "current" direction 
or not based on type, but they should be allowed to render upside 
too, if specifically required.

eg.

condition: either boolean [ button ] [ no-ope ]

view compose/deep [
	button
	(condition)	
	button
]

>> compose/deep [ button (either false [[button]] [()]) button ]
== [button button]

I wanted to have this implicit NONE skipping for a long time. I'm 
not a fan of  using an either just to return "nothing". IMO an if 
that doesn't return anything at all makes a lot of sense if used 
with COMPOSE.

so either there is a compose/deep somewhere .. or there is a switch 
to the do dialect occuring

** Script error: path space/1 is not valid for none! type

** Where: applier apply use show unless show-now do-event either 
applier wake-up

 loop applier wait do-events if view either create-dialog do switch 
 applier appl

y if foreach if do-face if actor all do-style if do-event do-event 
do-event eith

er applier wake-up loop applier wait do-events if view catch either 
either appli
er do
** Near:

>>

and for A105

>> do %r3-gui.r3
Script: "Untitled" Version: none Date: none
** Script error: expected command! not font

** Where: size-text font-char-size? make make-text-style parse fontize 
catch eit
her either applier do
** Near: size-text gob

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

Henrik - dunno what you mean by crash - but no, R3 console does not 
crash, but I get rebol level crash:

handler added
** Script error: cannot use pick on none! value

** Where: second all resize-text-face remove-text-face switch either 
do-text-key

 if actor all do-style until either do-event do-event either applier 
 wake-up loo
p applier wait do-events if view

** Near: second get-facet face 'viewport-size tgob/size/x: face/facet...

>>

A106, text-test3.r - when I position caret to the last position:


** Script error: caret-to-offset does not allow word! for its position 
argument

** Where: print switch handler while applier wake-up loop applier 
wait do-events
 if view catch either either applier do
** Near: print [
    "otc:" mold otc: offset-to-caret gobt event/offs...

what I did was create a GUI similar to this one:

view [
	panel 1 [check]
	panel 1 [button button button]
]


When you resize this vertically by a few pixels, the bottom panel 
will resize incorrectly. That is known and will be fixed. What I 
managed to do, was to either move or resize the window in a way, 
that would cause resizing to get stuck in a loop (!), so it goes 
up and down in size by a few pixels vertically on its own, and the 
window just sits there shaking up and down in size. If possible, 
we would like some help with reproducing that.

I got the new exe and dll, the re-downlaoded r3-gui.r3, dialog and 
validation too, but get this error when clicking on a button in the 
dialog demo:

** Script error: path win-gob/text is not valid for none! type

** Where: any view either create-dialog request-user do switch applier 
apply if

foreach if do-face if actor all do-style if do-event do-event do-event 
either ap

plier wake-up loop applier wait do-events if view catch either either 
applier do


** Near: any [opts/title win-gob/text "REBOL: untitled"] ds: screen/s...

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 tried the code which worked in Carl's VID: view [p: progress scroller 
attach 'p], but no luck either ...

I'm not able to produce it either.

I've actually not used either, Pekr just asked for other interpretations 
- and that's how I first read Cyphre's code.


Pekr:  Elements divided by number, rounded up (with final column 
simply containing the remainder) is how I would do it...

The thing is: Either the number is like a SKIP refinement or like 
the number for LOOP

I just can't find it. Spent hours looking for it. Carl can't find 
it either.

I do not like multiline tabs either, and they violate some of the 
rules of good GUI design.


Sure Graham, good and bad design are matters of opinion; however, 
they are based on what "most users" can understand and efficiently 
operate.  If a GUI causes a user become "lost" or do the wrong thing, 
then it's not a good design.

I don't like multiline tabs either but they're not the same as nested 
tabs :)

For DIRTY being changed, that has relevance for when validation is 
not used, for enabling submit buttons. But this also means the original 
value should be stored, which may be covered by the undo system. 
I'm not sure that's useful, if the undo system can show the number 
of changes in a field.


For MANIPULATED doing what is described above, it overlaps most of 
what DIRTY would do and it would also overlap most of what validation 
already does, namely detect and approve/deny changes in a field. 
I'm not sure it's useful either.

henrik,  it seem's that style doc have a problem  => ** Script error: 
text does not allow command! for its text argument

** Where: show foreach unless show-now view catch either either -apply- 
do
** Near: show f

Pekr, what is the reason you don't help either by:

* wring tests for Parse
* writing test for Mold

* writing tests for CureCode tickets that don't have tests in the 
core-tests suite yet
* writing some GUI styles

* responding to user polls, letting us know what your preferences 
are

* reading the documentation and/or new proposals pointing out at 
the problems you are having with them
* doing other useful work to help R3?


That is not complaint nor is it any kind of attack. It is just that 
I thought you needed R3? And, from my point of view there is no obstacle 
you could not do any of the above? However, you have still a lot 
of stuff you can pick and help to make R3 better. Do you still not 
feel like wanting to do something? Simply put, there is enough oportunities 
for you to pick from, and the quantity is getting bigger over time. 
Or, is it still too early, and any effort from you can be expected 
only when none will be needed?

Pekr, and all I'm saying is that the irreguarly shaped styles drawing 
can be solved with access to the face click mask, that either is 
or hopefully will be implemented by Cyphre. Therefore I find it pointless 
to work on a per-style solution.

This is what I get for mouse-over upon the preview tab - it displays 
the preview and crashes with:

** Script error: tooltip: needs a value

** Where: either if function! all do-style either if either do-event 
do-event ei

ther -apply- wake-up loop -apply- wait do-events catch either either 
-apply- do
** Near: either arg [
    buttons: compound-face? face
    tab-box: c...

Am I missing something really basic......Here's my first attempt 
in many months to play with the R3 GUI.
New console session, R3-a110.exe:
    >> load-gui
    Fetching GUI...
    GUI Version: 0.2.1
    (Developer test GUI theme)
    ** Script error: size-text has no value

    ** Where: font-char-size? make make-text-style parse fontize do do 
    either load-gui
    ** Near: font-char-size? self

You can either build one from the Hostkit yourself, or use e.g. the 
pre-built one provided by Henrik:
http://94.145.78.91/files/r3/gui/r3.exe
http://94.145.78.91/files/r3/gui/r3lib.dll

i just try it and it gives me that >> do %style-browser.r3

Script: "R3 GUI Style Browser" Version: $Id: style-browser.r3 1220 
2010-11-26 13
:18:02Z cyphre $ Date: none
** Script error: guie has no value
** Where: catch either either -apply- do
** Near: catch/quit either var [[do/next data var]] [data]

Due to the fact, that the B) variant was not known in this wording 
to either Cyphre or Bolek, I kindly ask both to participate in the 
poll as well. Thanks.

wow, a progress ... will read it shortly .... guys, I have one question, 
which will most probably get dismissed, but I'll at least try to 
ask:


- when prototyping stuff in console, and e.g. when your gui crashes 
from some reason, I am very used to just "unview". But - in R3 I 
have to do either "unview none" or "unview 'all" (not caring about 
the name of the window)


So my question is - couldn't the aproach be rethought, and old R2 
functionality brought back? Especially "unview 'all" in comparison 
to (imo) more rebolish R2 "unview/all" is non intuitive for me ...

that happens when no event handler is found, which a bare GOB would 
not have:

; Obtain face or handler object, do event handling:
		either all [
			obj: event/window/data
			obj: select obj 'handler
		][
			;print ["Do-event" event/type "for:" obj/name]
			event: obj/do-event event
		][
			print "A mystery GUI event?"
			halt
		]

Pekr native is a pain that's all ... it took already 5 years to do 
rebol VM version 3 on windows 32 and it's not over and according 
to the source code of r3-host-kit there is no GUI part in linux or 
macOS X.. we don't know either if more than the 3 main os will be 
supported and in what extense. Doing a change on 1 VM  means finding 
a way to do it on all other VM that's why if i remember well along 
the years R2 was supported on lesser and lesser OS and that's why 
too the rebol VM source code grow to a point that it was impossible 
for Carl to maintain it .That was the main justification for the 
retrofiting of Rebol VM  in the rebol 3  project... mean while all 
the  industry changed can you seriously say that  java vm is the 
same now that it was 5 years ago same goes for mono.

btw Pekr, from an API designer's standpoint, these types of questions 
are all very good  IMHO.  they force us to reflect on decisions and, 
often, trying to do so will either confirm them or with discussion 
might give new ideas.   I'm not part of this gui team, but I'd really 
like if someone asked pointy questions like this on my stuff.

It should be either put back, or make-face should change argument 
order too ...

I changed it to:

	unless pan [

  pan: make-panel make-face 'vpanel (pick test-blocks index) 'group 
		poke test-panels index pan
	]

But something is "not bound" ... I get following error:

** Script error: when has no value

** Where: make make make-face unless view-sub-panel do switch -apply- 
apply if f

oreach if do-face switch do do-bind-actor actor all foreach do-style 
set-face sw

itch do do-bind-actor actor all foreach do-style case do-event do-event 
do-event

 either -apply- wake-up loop -apply- wait do-events if view catch 
 either either
-apply- do

** Near: make styl/facets opts options: make object! any [opts []] 
ta...

Then, that is the reason why Carl would never accept your algorithms 
(my original version did not have it either)

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

Well, I stop my tries to port a demo now. My take is, that following 
primitive code should work easily, when repeated for the second time, 
but it does not:

lay: [button "OK"]

child: make-face 'hpanel [break-after: 1]
set-panel-content/no-show child lay
view child


My take is, that either make-face is not creating a structure needed 
later, or 'parse-panel is buggy, or I don't know what :-)

** Internal error: stack overflow

** Where: reduce switch parse to-text reduce parse to-draw all update-subgobs 
fo

reach update-subgobs show-native show-native show-native show-native 
show-native

 show-native show-native show-native show-native show-native show-native 
 show-na

tive show-native show-native show-native show-native show-native 
show-native sho

w-native show-native show-native show-native show-native show-native 
show-native

 show-native show-native show-native show-native show-native show-native 
 show-na

tive show-native show-native show-native show-native show-native 
show-native sho
w-native show-native show-native show-native s...

** Script error: button has no value
** Where: make make make-face catch either either -apply- do

** Near: make styl/facets opts options: make object! any [opts []] 
ta...

you need to use either the one you wrote:

child: make-face 'window compose/deep [content: [(lay)]]

,or the one I wrote

** Script error: cannot access faces in path panel/faces

** Where: exclude-faces -apply- apply if foreach if do-face if do 
do-bind-actor

actor all foreach do-style until if do-event do-event do-event either 
-apply- wa

ke-up loop -apply- wait do-events if view catch either either -apply- 
do
** Near: exclude-faces face name

It contains the following code:

	content: either block? content [
		apply :parse-panel [
			content all [in panel/facets 'names panel/facets/names]
		]


So, when I submit a block to set(insert)-panel-content, it tries 
to parse the dialect. But, there is no panel/facets/names.

 'of reactor does not work ...

 - I never tried/know about this one so either it is some obsolete 
 stuff or not updated to the new changes

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

exactly. But the tricky part is as follows - I like having 'options 
in the dialect level, and I am kind of used to have to call style 
attributes a 'facets ..... I would have to think for a while, if 
we can accept following convetions:


- options - used to set style properties, either in the style itself, 
or in the layout dialect

- facets - special purpose properties, which can be used inline in 
the layout level


I think that it would work for me, and that we would have it aligned 
nicely that way. I am just not sure Carl or other guys are ready 
to give-up on facets name being a general attribute/property of the 
style :-)

So as Bolek said..either make own 'fat-button' style or change the 
size related facets inline in your layout definiton.

I think it is still better to specify it either using stylize or 
button options [...]

From my POV either you accept there was some intention of the style-maker 
to define limits or you have to make own derived style.

I do not expect that every user that will write [button "text" 100x100] 
has studied source or documentation to understand how resizing works 
and what max-size mean, they probably just want to have their button's 
size to be 100x100.

So either the code should set all size to 100x100 or it should throw 
error and not allow setting size like this at all.

Robert - and? :-) I started with an argument, that when I was porting 
the demo, button 50x50 is allowed, but does not deliver what user 
expects, so we either remove it, or adapt to allow it, which might 
not be so easy to stay consistent.

Brian, correct. Pekr, either you as user will understand and agree 
the rules or you need to lear a bit more and become 'style tweaker'.

Regarding the relations between Init-size, Min-size and Max-size:


1) it is possible (using resizing) to specify any size at any time

2) the size specified is used for resizing, but, the Min-size and 
Max-size values (specified either by the style designer, or, eventually 
overridden by the user) are always respected, not triggering any 
error, if the user tried to resize "out of bounds"; instead, the 
limits are just used to keep the size "in bounds"
3) only the ones not knowing the resizing rules may be surprised

User can either use the limits, or define different, if he wishes 
so

Yes, I see that point as well. Most of time I resize something it 
is to either gain more real estate (Obviously shrinking the window) 
or to see what is being hidden, as with a large spreadsheet or to 
show me more as one might do with an email client.  In the latter 
case, the objects resize larger but not the fonts, etc. This ALTME 
window is a good example. If I want to see more messages I can increase 
the size but I don't expect everything to just get bigger.

How can I properly attach scroller to progress bar? Following code 
shows scroller at 100% value. Scroller accepts some initial size 
parameter, but not sure how to utilise it either ....

view [prog: progress sbar: scroller attach 'prog]

Robert - I can't see any subsystems ready, other than proper resizing 
(which is really nice), and focusing system. How can you say 2-3 
styles are enough to judge the design? I would not call non-working 
styles being an eye-candy :-) This is all about architecture -  when 
porting demo, I meet the case when I am able to easily change e.g. 
color of the scroller with Carl's GUI, which does not seems to be 
a case with RMA's GUI, or I just don't know how to do it. As I did 
not want to bether you here with such simple stupid thing, I tried 
to study material-system myself. But - I can tell one thing - if 
those things are not simple on the surface, it is either - missing 
docs, or very wrong architecture.


You should really remember, why Carl decided to rework the GUI - 
to be the pleasure to use, kind like of Amiga AMOS Basic, yet still 
allowing more complicated designs. If that aspect will not be pursued, 
ppl will not like the GUI. And what is the system good for, if not 
liked to be used by ppl?


OK, at this point, with 2-3 styles in focus, I might postpone port 
of the demo, no? As the demo is surely done with more than 2-3 styles 
:-) I will soon finish it to the state, when clicking the left side 
list items will not crash the demo. Non working stuff will be commented 
out. Then others might try to get more complicated set-ups running 
...

If this is not the effect of the implementation, then it's either 
used wrong, or the implementation is wrong.

Pekr, you said "layout level 'options does not necessarily directly 
map to face/facets"...that's why I don't want to rename OPTIONS to 
FACETS in the layout block. Also so far you are the only one who 
has problem understanding the 'options in layout vs. 'options in 
style definition and in fact you haven't proposed any concrete solution 
(evenin your CC ticket).

I'm not saying I'm against reasonable change here but since there 
is no good viable solution(and noone except you cares) we should 
 either wait until it pops out from someones head or just let it 
be as it is now.

What Ladislav proposes is interesting, because it leads my thoughts 
even further, and then my concepts probably break anyway :-) Imagine:

style [
options: ; renamed facets
inline-options:
]


Because then writing "button "OK" options [field: value]" could lead 
users to think, that they are directly setting facets (options, if 
renamed), which is not the case either, as there is an abstraction 
in between the options and its mapping to facets. Besides that I 
think, that Carl would surely not like to give-up on facets name 
(although for me as non-englishman) the word has not meaning, although 
I know it exists in vocabulary ...

it does not work either ...

if you use a request function to display a message, this is the cause 
of the problem: the request function from RMA is bugged (and also 
the alert). You should either correct in the RMA r3-gui.r3 file, 
or, better, overload it. change the words group  by hgroup , and 
change the line doc (message) by text-area (message)

Guys, I don't know how often I have to repeat it:


1. we get basic concepts implemented. All these basics are seperated 
as much as possible. That's why it will be totally incompatible to 
Carl's GUI. And, we don't try to be compatible. Our goal is to have 
an enterprise enabled GUI framework.


2. To do step 1, we just pick 1-2 styles, and enhance and change 
them exactly to just work with the concepts from 1. And, please see 
the plural in "concepts". We are doing step 1 & 2 by concept.


3. If this stabelized, we take the next style and adopt it. This 
might lead to some changes in 1. which than have to be carried forward 
again.

4. Then either next style or next concept.

Script: "Include" Version: $Id$ Date: 27-Oct-2010/9:57:54+2:00

** Script error: skip does not allow none! for its series argument

** Where: unless actor all foreach do-style if if actor all foreach 
do-style act

or all foreach do-style actor all foreach do-style either if either 
do-event do-

event either -apply- wake-up loop -apply- wait do-events if view 
catch either ei
ther -apply- do
** Near: unless any [
    not arg/1
    0 >= (pos: arg/1 - parent/sta...

** Script error: path filters/:index: is not valid for none! type

** Where: function! switch -apply- apply if foreach if do-face do-popup-parent 
function! switch -apply- apply if foreach if do-face -apply- apply 
use if actor all foreach do-style switch actor all foreach do-style 
either set-face switch actor all foreach do-style case do-event do-event 
do-event either -apply- wake-up loop -apply- wait do-events if view 
catch either either either -apply-
** Near: arg :face :value :actor-arg

its actualy not that complicated... in the sense that you must only 
know the coords of the boxes (something like sub gobs) and then when 
the text reaches the lower right corner of a box, a decision is made... 
either the box can stretch a little or you jump to a new box to render 
into.


implementing columns thus becomes a specific case of a generalized 
solution.  just provide two sub gobs and texts flows from one to 
the other.


note that the text boxes are independent from paragraph... these 
boxes are the actual "page" area which the rtf uses to calculate 
bounds and word-wrapping and offsets and such.

Cyphre - I am not sure if we should accept CSS document model here, 
as users/designers are used to it? I tried to search for some typography 
vocabulary, but there is not much in it:

http://www.proximasoftware.com/fontexpert/terms/


Then I also looked into MS Word (well, not the best DTP option, I 
know :-), but I am somehow satisfied, how paragraph styling is done 
in it, and I find it pretty much flexible. So few of my notes:

PAGE:
--------
- text-gob - let's say it equals to page


- margin should allow to set 4 sides, as is with CSS and even DTP 
systems. DTP system talk about margin as about the space to the edge 
of the paper. I don't know, how such terms are used in conjunction 
to R3 GUI, but we should somehow find-out, how to not be confusing. 
But - having just a single marign is not imo sufficient.


- origin should replace scroll, and it should mean offset. But looking 
into VID2, origin just did what you propose - but I don't like it, 
as it required us to introduce offset to VID2.

PARA:


- indent - e.g. MS Word defines: indent-left, indent-right (kind 
of creates margins/padding, if you relate to CSS terms), then they 
have indent-special - first-line | "pre-indent" (-first-line,not 
much usefull). It also has check-box for "mirror setting", which 
changes indent-left to inner, and indent-right to outer (dunno what 
it is good for)


- spacing - top-space | bottom-space - but here, it is not inner 
space in paragraph, it is more of an indentation between paragraphs. 
In other words - I can imagine calling it even padding (as we are 
used from VID2, we used space there for the auto-spacing). It allows 
you to set, that it will not add space in between two paragraphs 
of the same style. It also allows you to set spacing for rows - either 
by float, or by multiples, 1,5 rows, double, the-least-possible (pixels), 
exactly (pixels)


- paging - some stuff to set in regards to paragraph and paging, 
as linking of paragraphs, linking of lines

- runaround settings (dunno if correct english term)

Indent - is your proposal sufficient? You allow using either issue,e.g. 
3x6 (3px left, 6px right), or integer, e.g. 6px (first line indented 
by 6px) - what if I want to set both. And most probably I want it 
...

in theory you can use to-image! on a gob!   but I'm not sure its 
been fixed in latest hostkits and not sure that really answers your 
question either ;-)

henrik:R3/Lobby>> help
sh: xdg-open: command not found
sh: x-www-browser: command not found
** Access error: external process failed: "Undefined error: 0"

** Where: browse parse try either either forever command-loop make 
context do catch either either -apply- do try chat
** Near: browse help-url

Seems these are broken in A110 for OSX.

I'm trying to run the hello world example at http://www.rebol.com/r3/docs/gui/guide.html

Here is what happens when I try load-gui:
>> load-gui
i
Fetching GUI...
GUI Version: 0.2.1

(Developer test GUI theme)

** Script error: expected command! not font

 ** Where: size-text font-char-size? make make-text-style parse fontize 
 do do either load-gui

** Near: size-text gob

Is this a host-kit issue or ?

Thanks guys..so far it looks good:

-there are no crashes (yet) so it looks the method is highly compatible 
as I expected

-if you have at least decent (doesn't mean new or fast) card the 
difference can be somewhere between 70-100% performance increase 
in the test

-noone(yet) reported case when opengl-speed < sw-speed except Henrik 
running some VM which has most probably bad OpenGL support.


Regrading Pekr's case. He is using Intel on-board gfx which has either 
not good performance/opengl driver or he has forced in the driver 
config VSYNC limiter set to ON so the FPS cannot get higher than 
60Hz LCD frequency.

Third, Pekr, you are _still_ using the wrong URL for your remote. 
Either make a fresh clone with

  git clone git://github.com/carls/R3A110.git


or fix your remote manually (Probably via `git remote set-url origin 
git://github.com/carls/R3A110.git`.)

Mostly a matter of either setting up a system to do the compile, 
or setting up a cross-compilation toolchain.

If you are adding a module to the module list, and there is an existing 
module of that name, then the new module either overrides it, replaces 
it, or doesn't get added (possibly with an error triggered, but so 
far not). The question is which one to do in the particular circumstances. 
The factors are whether it is the same module, for whatever "same" 
means here considering it might be reloaded or still source; whether 
the versions are the same or greater; whether the existing module 
has already been made or is still source, and the same for the module 
to be added.

It wasn't a request for assistance. If you want to help, it will 
be welcomed. If not, we are doing well now. Either way you are free 
to use what we create, or not. Enjoy!

For the sake of completeness, here are the highlights of the alpha 
108 changes:

- Script headers can have an options block, a simple block of flag 
words. User extensible.

- The standard script header now has a lot fewer words in it. More 
stuff is optional or in the options block.

- Script compression, either binary and base 64 binary! encoded. 
Automatic, transparent.

- Script checksums, both to verify the script and for IMPORT to compare 
with. Applies to decompressed source.

- An optional script length header field (like http's Content-Length). 
This allows binary script embedding.

- Internal support for getting the end of an embedded script, so 
a multi-loader is possible.

- The 'content and 'isolate header fields are changed to option words. 
The content is still saved to a 'content header field.

- The 'content field, if set, is set to the start position of the 
script proper, even if there is stuff before it.

- The whole system/contexts/system concept is gone, as part of the 
system restructuring. Now we have SYS.

- The system/contexts/exports concept is gone too, replaced by a 
not-module-specific runtime library called LIB.

- The old type: 'extension is now the 'extension header option word. 
The only module type is 'module. And it's optional for most code.

- Mixins are now called "private modules", and are flagged by the 
'private option word. And they can have names.

- Private modules can be added to the system modules list (because 
of the names). This lets them be reused without being reloaded.

- Unnamed modules are now prohibited (until alpha 109, where they 
become private modules that reload every time).

- Delayed modules, which can be partially loaded and then not fully 
made until they are imported. Use the 'delay option word.

- A HIDDEN module source keyword, which applies PROTECT/hide to a 
word or words. Acts like the EXPORT keyword.

- Better errors are triggered when the bad things happen. Including 
new error codes.

- DO and MAKE--MODULE intrinsics are now in sys, as DO* and MAKE-MODULE*. 
No more system/intrinsics.

- DO-NEEDS is no longer exported (it's in sys). IMPORT block is a 
public alias for DO-NEEDS anyways.

- MODULE now makes modules that act more like those in script files. 
And has /mixin support too.

- A whole bunch of changes and fixes to native functions to support 
the above stuff.

You can work with remote repositories either by directly referring 
to URLs, or by locally associating symbolic names with the URLs (git 
calls those local aliases "remotes").

Well, forward-looking platforms either run prior code, or are totally 
new, so require some degree of time investment to get started on 
them.

Now someone should really write some short docs. This is so complex 
and surely was not created for normal mortal, who just wants to download 
few source files and build a distro? So I downloaded Tortoise Git, 
naively thinking this is all I need. No, so I installed Git preview 
version (not full msysGit). Now - what should I do? I created a directory 
called host-kit, right pressed mouse, and chose "create repository 
here" or something like that. Now once again I press right mosue 
button, and try either git-clone, or Git sync, but it does nothing 
... I think my problem might be (apart from being too dumb and not 
willing to spend tonnes of my free time with such complex stuff):

- I am required to have some kind of account at target site

- I don't have it somehow linked with SSH stuff (did not choose to 
use my putty installation during the installation phase)


How do I get the actual copy of R3 Host Kit? There might be plenty 
users as me, willing just to download recent sources, and build, 
not to commit anything ...

TortoiseGit's Sync dialog is basically one dialog with both pull 
and push in it. Pretty easy if you need to do either or both.

Either using the platform numbers or the more descriptive names.

2. I'd drop all makefiles you did not personally test/use, for now. 
I just assume that means only make-gcc will remain. Then either leave 
that in make-gcc/ or move it to the toplevel again.


But I would not fuss about the makefiles much, same thing here: we 
can restructure that later on.