AltME groups: search

I digged following from Max in the past:
---------------------------------

My pet peeve about R3 view is that we still don't have access to 
the actual AGG elements directly within rebol.

We still have to go through a clumsy interface called draw dialect.

The dialect is fine (great actually) for initialisation, but after 
that, its not adapted to actual manipulation of what is going on 
inside, you have to go trough a rebol -> agg convertion stage at 
each refresh.

It's not the speed, it's the fact that it's complicated cause you 
have to create "virtual" draw components and then assemble them on 
the fly reducing blocks and stuff.
I'd love to be able to do:

a: draw [circle 30x30 15]
a/radius: 30
a/offset: 100x100
show a


If graphic elements where first class datatypes, we could completely 
ignore the gobs, and build real canvases, uber fast.

Another example, more appropriate:

; this draws a box...
draw [s: polygon 10x10  30x10 30x-30 10x-30]

; make it a house outline
insert at s/vertices 4 20x-40

; raise the "roof" 
s/vertices/4/y: -50


The problem is that to edit draw blocks, you have to create a slew 
of things before creating the draw block, then you have to store 
references to all of those things somewhere, everytime you want to 
add a "dynamic" attribute its pretty tedious.

The first-class gel datatype would allow AGG to edit its internals 
directly using binary C code through its accessors.  no need to go 
through rebol funcs and reducing blocks, etc.

The use of  "show a" above could intrinsincally know that it only 
needs to refresh the region that this element affects, just like 
all graphic cards do when evaluating the graphic pipe rendering.

So many things like flash games which become soooo heavy in AGG would 
be real-time and use much less CPU resouces.  in most games only 
a small part of the canvas really changes interactively.

no, that doesn't have anything to do with GOBs. those are problems 
with DRAW. GOBs are about as small and lightweight as they can be. 
How they are used by the system is a different matter.

Max continuead a bit:
----------------------

part of what I want to attempt for my host code work is to implement 
liquid and globs natively in R3.  with access to AGG I could build 
the single most powerfull canvas engine in any language...


 we'd have absolutely nothing to envy to ANY other language, not even 
 Apple's engine... as long as the AGG can render a few more things 
 and add filters to AGG strokes.


globs use AGG and allow events to be sent to individual AGG strokes. 
 so you can "slide" a single line by clicking on it. the cool thing 
is that the input mask and display are separate... and you can implement 
any number of layers per display element that you want.

Getting a window plus event handler up and running only using View 
(no load-gui) is pretty simple. The code, for those interested, is:

	system/view/event-port: open [scheme: 'event]

 system/view/event-port/awake: make function! [[event][print event/type]]
	f: make system/standard/font [size: 36]

 d: make gob! [text: "Title" offset: 50x50 size: 300x200 flags: [resize]]
	append d make gob! [text: [font f "Text"]]
	append system/view/screen-gob d
	show system/view/screen-gob
	wait system/view/event-port

and are face iterators used for text-lists ?

Some things are the same as in R2: You still create layouts with 
a dialect and you still create styles, but style writing is more 
important now, since face hacking like in VID isn't possible anymore.

VID3.4 has no face iterators. Too heavy and unnecessary for GOBs.

I have noticed some instability.  If you halt from a GUI script and 
then try and close it ... r3alpha crashes

The resizing and aligning issues makes VID3.4 difficult to use for 
creating decent aligned faces. I would probably wait until that is 
at least fixed.

#2686 and "get lists.r"

I used to use 

l: layout [ f: field ]

and then write my function access f after the layout was created.

Now we have 

view [ layout block ]
...

My first gui script http://rebol.wik.is/Rebol3/R3_GUI/Sendfax.r


I'd like to have the output from net-log appearing in the area .. 
but I can only get it do that once  and then nothing ...

oh .. and the fax was successfully sent :)

control-C to try and copy text in an error causes the console to 
crash

I wrote this to try and update the area with network trace

			set 'net-log funct [  txt /c /s][
				data: rejoin [ get-face a1 newline txt ]
				if c [ data: join "c: " data ]
				if s [ data: join "s: " data ]
				set-face a1 data
				set-face/field a1 tail get-face a1 'locate 
				wait .1 ; update gui
				txt
			]

I would assume that would simply be an extension of the rich text 
dialect and exposing more options from the AGG font renderer:

[hint 1 "abc" hint 0.8 "def" hint 2 "ghi"]

Henrik, yes HINT x y keyword can be added to the dialect. But IMO 
this can be useful only in case you have own vector glyphs and own 
simple font engine. For example the TrueType hinter is kind of language 
for itself so it can be pretty complex.

Pavel, yes, you are right. We switched the terms in the discussion 
above. I've been  mainly refering to this informaiton: http://en.wikipedia.org/wiki/TrueType#Hinting_language


AGG have kind of font manager module. The font manager basically 
takes vectorial glyph data (which are provided by Win API or FreeType 
lib, quartz etc.) then the glyphs are converted to scanlines and 
stored in font cache...

So this way we are depending on the vector glyph data provided by 
platform specific font frameworks.

The problem lies in the fact the hinting language(see link above) 
is patented by Apple so it is not possible to get the correct font 
glyph data without breaking the patents (or paying Apple).

That's the reason why fonts on Linux or FreeType based platforms 
can't look so nicely hinted as on Windows/OSX.

cyohre i noticed the glyph engine years ago in AGG C++ version and 
i asked at that time why that wasn't existing in view adaptation

and got never an answer (well that's not the first)

cyphre unfortunatly  win32API is abandonned on vista and  seven (widows 
6 and 7) so the font rendering is not good look at the picture here 
that shows the differences

though I haven't played around with the latest versions...  and its 
been a very long time, so it could be that I tested it just before 
my vista install crapped out.

1) it's possible for AGG to deal text rendering evolved at a low 
level (perf are great  on R2 and that's convincing)

2) Since draw wasn't made to handle such an extensive use of the 
draw/text instruction  in R3 we have to make the AGG mode adapted 
to block of text handelling the first idea and the main  boring thing 
to have to deal in AGG text rendering is the positioning of every 
block of text. We need a way to retrieve the position of a texte 
on screen.  

3) to be better and faster AGG should be less verbose. I know that 
it's possible to save lot of space in the draw block

Shadwolf,

re glyph engine in R2: The glyph manager is used inside DRAW dialect. 
But the internals were never exposed at the REBOL laguage level. 
Should I really explain why? I hope not.


R3 text improvements: As I wrote week ago here to you on AltMe there 
are no limits for you to make it happen. You can already build your 
own font engine+dialect in C/C++ or whatever and use it as EXTENSION 
for prototyping your contributions. If I was able to protoype using 
R2 dll interface you have now even more possibilities. So where is 
the problem?

Regarding the XP vs VIsta and 7 issue:

I'm repeating it again. If you are able to see the bug, then please 
give us something more that screenshot or long confusing posts...trace 
log file with the differences in returned values or whatever,  simple 
clear example proving that the error is really in carret handling 
native functions....That would really speed up possible bugfix or 
at least clarify the issue. Is it so hard to understand this?


Hope my words doesn't look rude. I want to help you as much as I 
can...we seems to have just some disconnect here.

As we still have the chance to make some changes to R3 GUI, I would 
like to get the opinion of the community for this idea: R3 is designed 
for development-in-the-large, this means modularity is key.


IMO a GUI system where widgets just send messages and where I can 
register handlers for a widget-name/mesage combination would help 
a lot.


Such a system could call several handlers in a chain, it could be 
re-configured at run-time, etc. Further I think a concept like a 
(virtual-) finite-state-machine can help a lot here.

Maybe it's even possible to mix the current and simple "add action 
to widget" pattern with such a event based system.

I have used such an approach in one of our apps.For example I have 
three tables, that depending on the app state, show different columns 
and data. So, when app state switches this will trigger the change 
of the tables.


And other example is changing the language just where you are. No 
need to re-enter the current GUI etc. There will be just a change-lang 
XY event send.

the advantage is that its a generic engine... and can be used to 
link up any aspect of an app. not just its "actions"

for example, right now, in my pain application, if you replace the 
bg-image of the canvas, it refreshes the whole software on its own. 
 the size of the canvas, the crop bars, image properties and input 
management offsets, etc, etc.

I think we just need to finish R3 GUI as Carl started it (VID 3.4). 
We might think about some by Max proposed enhancements to Draw, making 
GUI kernel more powefull, and let's see, where it leads us, before 
we start to think about another overhaul. Msg passing concept is 
surely interesting, but it imo creates another layer to implement, 
understand, to work with, so I am just not sure, unless I see the 
currently implemented solution does not allow us to easily work/extend 
the GUI.

there is VID and there is View.  we must not sacrifice the later 
for the former.

view is already much more powerfull now, but I feel that the current 
design is like going half way. 


instead of having a totally open level 1 (gfx engine) on which level 
2 (view) and level 3 (VID) is built, we have level 1.5 and level 
3

and I mean within REBOL, not within C.

Most of VID's serious issues come down to event handling (solvable 
now) and incompleteness (also solvable, just a bunch of hard work) 
and missing features, like keyboard navigation (already solved that). 
The VID extension kit makes VID much more scalable, simply by finishing 
the work that Carl set out to do. It's easier to write large apps 
because styles are more uniform, and you have more powerful features 
and adherence to face accessors, rather than relying on face hacking.


Building those features into V3.4 by default, and you have a killer 
UI system without sacrificing usability.

themes are a 2 function addition, and localisation would be a single 
function to add.

It's important to lift the UI out of the domain of appearance and 
into the domain of meaning. When your UI intelligently finds the 
default window close button or the first field in a form automatically, 
and automatically assigns correct keyboard navigation shortcuts, 
because of the underlying architecture's emphasis on meaning, there's 
no need to write any code to handle that at all. It's just there. 
You build your styles to adhere to the meaning that was setup by 
the GUI system. In the VID extension kit, this is done through flags 
and powerful face handling features. You don't need to add any code 
for that in the dialect.

Max - so what do you propose for the kernel, to not be 1.5 and 3, 
but 1, 2, 3? :-)

it could be 1, 1.5, and 3 also if people like how gobs are currently 
structured. :-)

We already have message passing, and these messages are events.

So, maybe we need to have the ability to define custom events and 
have custom event handlers.

I've spent a bit of time going over R3/View and believe it now has 
all the "building blocks" required to build a modern/fast gob! based 
GUI. The amazing thing is that these building blocks are the 10 natives 
that View adds [to Core]. They are:

	gob!
	caret-to-offset
	cursor
	draw
	effect
	map-event
	map-gob-offset
	offset-to-caret
	show
	size-text


With these 10 natives (gob! is actually a type!) we should be able 
to construct simple but powerfull gob!-based GUIs with a smaller 
mezz footprint than R2. My preliminary conversion of RebGUI to R3 
seems to take about 50% the code to do the same thing [compared to 
R2] ... very promising at first glance.


To get a feeling for how tight the code can be the next post is the 
entire [skeleton] source of a working gob!-based GUI.

ctx-rebgui3: make object! [

	cursors: make object! [
		app-start: 32650
		hand: 32649
		help: 32651
		hourglass: 32650
		arrow: 32512
		cross: 32515
		i-shape: 32513
		no: 32648
		size-all: 32646
		size-nesw: 32643
		size-ns: 32645
		size-nwse: 32642
		size-we: 32644
		up-arrow: 32516
		wait: 32514
	]

	colors: make object! [
		page: white
		edit: white
		text: black
		true: leaf
		false: red
		link: blue
		theme: [165.217.246 0.105.207 0.55.155]
		outline: [207.207.207 160.160.160 112.112.112]
	]

	metrics: make object! [
		cell: 4
		gap: cell * 2
		line: cell * 5
		margin: cell * 4
		margin-size: as-pair margin margin
		radius: 2
	]

	;	Private functions

	set 'make-gob make function! [[

  spec [block!] ; offset, size and one or more attribute/value pairs
		/data object
		/local size text gob axis
	][
		size: spec/2
		if any [negative? size/x negative? size/y] [
			text: select spec 'text
			all [block? text text: first find text string!]

   size: 8x4 + size-text make gob! compose [size: 9999x9999 text: (text)]
			all [negative? spec/2/x spec/2/x: size/x]
			all [negative? spec/2/y spec/2/y: size/y]
		]
		gob: copy []
		;	attributes are (text, color, effect, image and draw)
		foreach [attribute value] spec [
			switch attribute [
				box [
					attribute: 'draw
					value: compose [
						pen (get value/1)
						line-width 1
						fill-pen (get value/2)
						box 0x0 (spec/2 - 1x1) (metrics/radius)
					]
				]
				pill [
					attribute: 'draw
					axis: either spec/2/x >= spec/2/y [2] [1]
					value: compose/deep [
						pen (colors/outline/3)
						line-width 1

      grad-pen linear (spec/2/:axis * .1) (spec/2/:axis * .9) (all [axis 
      = 2 90]) [(colors/outline/1) (white) (colors/outline/1)]
						box 0x0 (spec/2 - 1x1) (metrics/radius)
					]
				]
			]
			append gob reduce [attribute value]
		]
		spec: gob

  gob: make gob! compose [offset: spec/1 size: spec/2 (to set-word! 
  spec/3) spec/4 data: (make object! any [object copy []])]
		foreach [attribute value] skip spec 2 [

   append gob make gob! compose [offset: 0x0 size: spec/2 (to set-word! 
   attribute) value]
		]
		gob
	]]

	;	Public functions

	set 'display make function! [[
		title spec

  /local gob xy max-x max-y left-to-right? after-count after-limit 
  here arg append-widget widget last-widget word
		action
		handler
		size
		text
		color
	][
		xy: metrics/margin-size
		max-x: xy/x
		max-y: xy/y
		left-to-right?: true
		after-count: 1
		after-limit: 9999
		
		gob: make gob! compose [text: (title) data: (make object! [])]

		append-widget: make function! [[][
			unless widget [exit]
			unless handler [

    handler: compose/deep [on-down: make function! [[event][(action)]]]
			]
			append gob switch widget [
				bar [

     make-gob compose [(xy) (as-pair max-x - metrics/margin 1) color (colors/outline/3)]
				]
				button [
					all [none? size size: 15x5]

     make-gob/data compose/deep [(xy) (size * metrics/cell) pill none 
     text [center (text)]] handler
				]
				text [
					all [none? size size: 15x5]

     make-gob/data compose/only [(xy) (size * metrics/cell) color (white) 
     text (text)] handler
				]
			]
			last-widget: last gob/pane
			;	1st reverse item?
			unless left-to-right? [

    last-widget/offset/x: last-widget/offset/x - last-widget/size/x
			]
			xy: last-widget/offset
			;	max vertical size
			max-y: max max-y xy/y + last-widget/size/y
			;	horizontal pos adjustments
			all [
				left-to-right?
				xy/x: xy/x + last-widget/size/x
				max-x: max max-x xy/x
			]
			;	after limit reached?
			either after-count < after-limit [
				;	spacing

    xy/x: xy/x + either left-to-right? [metrics/gap] [negate metrics/gap]
				++ after-count
			] [
				xy: as-pair metrics/margin max-y + metrics/gap
				after-count: 1
			]
			all [:word set :word last-widget]
			word: widget: action: handler: size: text: color: none
		]]


  parse reduce/only spec [after bar button handler return reverse rich 
  text] [
			any [
				opt [here: set arg paren! (here/1: do arg) :here] [
					'return (
						append-widget
						xy: as-pair metrics/margin max-y + metrics/gap
						left-to-right?: true
						after-limit: 9999
					)
					| 'reverse (
						append-widget
						xy: as-pair max-x max-y + metrics/gap
						left-to-right?: false
						after-limit: 9999
					)
					| 'after set arg integer! (
						;	return unless this is first widget
						if widget [
							append-widget
							xy: as-pair metrics/margin max-y + metrics/gap
						]
						after-count: 1
						after-limit: arg
					)
					| 'handler set arg block! (handler: arg)
					| 'rich set arg block! (text: arg)
					| [set arg integer! | set arg pair!] (size: arg)
					| set arg string! (text: arg)
					| [set arg tuple! | set arg none!] (color: arg)
					| set arg block! (action: arg)
					| set arg set-word! (append-widget word: :arg)
					| set arg word! (append-widget widget: arg)
				]
			]
		]

		append-widget
		gob/size: metrics/margin-size + as-pair max-x max-y
		gob/offset: system/view/metrics/work-size - gob/size / 2
		append system/view/screen-gob gob
		show system/view/screen-gob
	]]

	set 'undisplay make function! [[gob][
		remove find system/view/screen-gob gob
		show system/view/screen-gob
	]]

	;	Start global GUI event handler

	active-gob: none
	system/view/event-port: open [scheme: 'event]

 system/view/event-port/awake: make function! [[event /local evt gob][
		evt: map-event event
		gob: evt/gob
		while [not object? gob/data] [gob: gob/parent]
		if all [event/type = 'move gob <> active-gob] [
			attempt [active-gob/data/on-away event]
			active-gob: gob
			attempt [active-gob/data/on-over event]
		]
		evt: to word! ajoin ['on- event/type]
		attempt [gob/data/:evt event]
	]]
]

Even better, I'll upload it as a script to my website. Oh, and the 
above app example is missing an important line at the end:

	wait system/view/event-port

Yes and no. Yes it's going to be as minimalistic and bloat free as 
before ... no as I'm aiming for something that allows seperation 
of form and function. RebGUI has a number of limitations that under 
R2 were problematic to resolve but under R3 are doable.

Reposting from R3 chat (which seems a bit quiet lately).


I've been looking at the rich text gob! functionality and it seems 
the following dialect commands are supported:

	anti-alias logic!
	bold [off]
	italic [off]
	underline [off]
	size integer!
	left|center|right
	drop integer!
	font object!
	para object!
	caret object!
	scroll pair!
	string!


Are there any I've missed? Any doco on this yet? I havn't figured 
out how to use drop or caret yet. Anyone have any working examples 
for these?


A design question: is there any reason for retaining font and para 
support given that we could move the few remaining unsupported words 
out of those objects and into the dialect itself? (e.g. have the 
dialect directly support font names and valign words).


Also, it would be nice if we had control over the default font name, 
size and alignments [at the very least]. Perhaps a system/view/text 
object?

The CARET object is tricky (it handles the cursor position and the 
selected area (for hilighting), see gui.r for more infos.

Ashley, all current keywords of the richtext dialect can be found 
in system/dialects/text. There is not much docs about it yet but 
I'll tyr to gather some examples and post here.

I'm open to discuss the design improvements as so far not much people 
used the dialect so I'm sure we can enhance it for some useful things.

Does anyone know if there is R3 rich text group already on this world? 
Or should we create new one?

Create a subheading of Community/Libraries (621) and upload it there.

Any other dialect word (e.g. scroll, size, bold, color) prevents 
caret from working (i.e. if you use caret you are forced to use font 
and para objects).

Also, it seems the caret object could be simplified down to:

	caret: make object [
		caret: start: end: none
	]


Are the blocks (caret/1 start/1 end/1) supposed to have any other 
values in them? (e.g. color tuple, 2nd string!, etc)

system/dialects/text is handy. Seems the shortcut b, i, u and nl 
words are not yet implemented/working. 'drop is cute, and I note 
that 'drop without an argument defaults to drop 1.

Any way of using anti-alias with caret? Seems:

	[text: [anti-alias on s caret c]]


kills the caret and font/para objects don't have an anti-alias word.

Ashley, I can't see most of your problems when using r3-a96.exe
Please try:
do http://cyphre.mysteria.cz/tests/caret-test.r

You should see it works correcty.


The only problem I was able to repro is that the shortcuts b,i,u 
and nl aren't working...probably some 'regression' in newer builds 
as I remember it worked before.

regarding the caret obect:

the CARET, HIGHLIGHT-START and HIGHLIGHT-END fields must be defined 
as block! of the following format:
[block! string!]


the first block! value must be the gob/text block! at the index position 
of the text element


the second string! value must be string of the text element at specified 
position


You cannot just copy the first block as in your example above. You 
have to set the block to the position where the text element really 
is in the dialect block(this way the text engine can use the index). 
This part is a bit tricky but it was decided after long discussion 
with Carl. I proposed to use simple integer! for the index, but Carl 
wanted it to be this way which is easier as you can manipulate the 
block index easily without the need to use INDEX? to get the integer.

Thanks, your example (and explanation) makes it all clear now (I 
only tested/debugged with a single string before).

the resize engine is still the main issue for troubles and so the 
best result looks something like this:

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

Weighting happens by "pushing" other elements aside, like soap bubbles 
pushing against eachother. The bigger the element is, the more it 
pushes. But space is also divided between the number of elements 
available in a given group, so a group of 5 buttons takes a little 
more space than a group of 3 buttons.


That gives the problem you see with strange spacing before and after 
the vertical scroller, because it's size is not big enough to provide 
push. and the other elements are too small to provide enough push. 
Combining the size of the face and the push factor is why resizing 
is broken.

But there are more bugs in it than that. If you push too much, the 
elements overflow and will be clipped by the right and bottom edges. 
Furthermore, the calculation of space to the right edge and bottom 
edge is also broken. It's almost impossible to predict in your head 
how the layout will look.


I'd like to replace the resize engine with something more concrete, 
perhaps with springs instead and fixed pixel sizes (oh, maybe similarly 
to what the VID Extension Kit does) or depending on whether Carl 
get's started again with his specs list (which I unfortunately can't 
locate). I hope we'll get to start this month.

Where? It's on r3-alpha, as well as Carl's old CVS repository. Feel 
free to copy it from r3-alpha if you want, and Carl is ok.

I was just curious to see how Gab's systemm worked .. and I tried 
%test.r but 

>> do %test.r
Script: "Test vid" Version: none Date: none
Script: "REBOL View System Functions" Version: none Date: none
Script: "rewrite-tree function" Version: none Date: none

Script: "Simple dialect to create/resize gobs" Version: none Date: 
none

Script: "REBOL VID 3: Definition of FACE prototype object" Version: 
none Date: n
one
Script: "REBOL VID 3: Functions" Version: none Date: none
Script: "REBOL VID 3: Events Handling" Version: none Date: none
Script: "REBOL VID 3: Styles" Version: none Date: none
** Script error: cannot MAKE/TO map! from: none!

** Where: make either make handler parse parse-set-dialect make-styles 
catch eit
her either applier do catch either either applier do
** Near: make map! style-spec/options

Also, I've read thru the docs ( but not the sources ) and it's not 
documented on how to create a GUI event

So first you have to define the resource if it doesn't already exist, 
and then ask for it by name.

yes, Carl is critical about that. I can understand that ... and then 
we have words like 'with, etc. :-)

there is a distinction between standard parts, which are inherited 
throughout many faces and private parts for each face instance.

And I never liked it then

Feel and engage are gone in R3. They are replaced by actors.

when I read through the sources (which you can get, properly formatted 
and documented through R3 chat), I can see there probably needs to 
be a better distinction between 'facet and 'faced.

a face is an object, and what does an object consist of?

'facet might be harder to change. I assume Carl chose this name, 
because it's closely related to FACE and we have GET-FACE and GET-FACET 
functions, which I find to be very clear.

and too easier to mix up ?

Well, to be honest, while Graham is imo right, that especially to 
novices, better wording could mean faster learning curve, I also 
have to say, that it is not the most important topic. Finishing VID 
is :-) I would like to see incorporated Carl's planned changes, and 
other subsystems being built-in (still not mechanisms for tabbing, 
accelerator keys display (can be done via layer), full keyboard navigaton 
etc.)

I don't agree. I've built quite a few styles in R3 now, and I've 
not once mixed up FACE and FACET, particularly because the path FACE/FACETS 
exists. I find it to be a pretty natural word to use.

Aspect

1.. appearance to the eye; visual effect the physical aspect of the 
landscape

2. a distinct feature or element in a problem, situation, etc.; facet 
to consider every aspect of a problem

3. the way in which a problem, idea, etc., may be considered to consider 
a problem from every aspect
4. a facial expression; manner of appearing a severe aspect

5. a position facing a particular direction; outlook the southern 
aspect of a house

6. a view in a certain direction a good aspect of the village from 
the tower

7. a surface that faces in a given direction the ventral aspect of 
a fish

8. (Spirituality, New Age, Astrology & Self-help / Astrology) Astrology 
any of several specific angular distances between two planets or 
a planet and the Ascendant or Midheaven measured, from the earth, 
in degrees along the ecliptic

9. (Linguistics / Grammar) Grammar a category of verbs or verbal 
inflections that expresses such features as the continuity, repetition, 
or completedness of the action described Compare perfective [2] progressive 
[8] [10]
10. (Life Sciences & Allied Applications / Botany) Botany

a.  the compass direction to which a plant habitat is exposed, or 
the degree of exposure
b.  the effect of the seasons on the appearance of plants
11. Archaic glance or gaze

it's much easier to confuse FACET and FACED.

Gobs ... and goblets? ;)

I don't understand the issue, so maybe you are right. What make-bogs 
did, was something different, no? It was about keeping multi-gobs 
togethere, setting their coordinate dependencies and z-order. But 
you hopefully know, what you are talking about, as I am not ....

Why do we need faces/facets at all? Seems:

	Window -> faces -> Gobs

could be:

	Window -> Gobs -> Gobs


If you need more attributes than the standard gob! provides then 
just make the data attribute an object! and put them in there.

Sorry, no. That is for VID3. It has concepts like FEEL and LOOK, 
which VID3.4 doesn't have.

Ashley, "just trying to understand why we still need the concept 
of faces under R3." - The role of faces in R3 are just what they 
were in R2, a collection of features and functions inside an object, 
but instead of the underlying View system being closed, they are 
now linked to a fixed set of GOBs, that we eventually can extend 
with all sorts of features. So:

R2:

Layout -> Face tree -> View

R3:

Layout -> Face tree -> GOBs -> View


Faces are what are generated by the layout. So the "face factory" 
is still needed and styles are the "molds" or prototypes. Within 
the face factory, the GOB factory exists. I would assume this separation 
makes HW acceleration or replacing GOBs with a different structure, 
much easier later. GOBs are redrawn using DRAW-FACE and that is handled 
inside the styles.


Styles use resources like fonts, colors, materials and standard draw 
blocks. This eventually helps skinning and abstracts these things 
away from the styles themselves.


The obscure FEEL object is replaced with a set of on-* actors that 
are run at specific times in specific sequences during runtime. They 
are more fine grained, so you can determine what you want to do, 
for example during various stages of face initialization.


The relationship between the layout dialect and faces is a bit different 
than under R2: you can't access the whole face in R3, only facets. 
For example the GOB itself, is not a facet and neither are internal 
states. So in order to change a deeper element of a style, you need 
to create a new style. This seems cumbersome, but is badly needed 
for large layouts, where we are semantically separating appearance 
from purpose. VID allowed this to be an organic mess. We may figure 
out a way to make creating derivative styles a bit easier.

I see Graham is already submitting GUI reports to Curecode. I think 
we need a separate project for that. There could be hundreds of issues 
and they shouldn't be mixed with Core bugs.

Need to finish a project first and then we're beginning. Hopefully 
next week. With a place to report bugs, you can start a little earlier.

If you need more attributes than the standard gob! provides then 
just make the data attribute an object! and put them in there.
 Right, and that object is called a "face".

I was just reading about upcoming new Facebook facelift ... and following 
the discussion I found out, that one person suggests very cool Facebook 
client done in Silverlight. I needed to download SL beta 4. Then 
I tried that mighty app. Guy, I can tell you - we can do it in View 
anyday. Its not any faster, any better, and I would really like to 
see the ugly code behind the app. My long time suggestion to popularise 
View is to wrap known services - gmail, FB, etc. E.g. especially 
on my Winmobile, ther's a FB client done by MS, and you can't even 
read more than 1 reaction to your post. I imediatelly can imagine 
Winmobile client in R3 :-)


Here's the screenshot - http://xidys.com/pekr/facebook-silverlight.jpg

It's a perfectly valid english word, used correctly. And it's clearly 
related to "face", whereas "part" or "attribute" is not. "Part" of 
what?

My complaint is that there are three words with similar spellings 
and different meanings

The metaphor is widely used. And there is a lot of English that isn't 
generally used, because most people aren't specific enough in their 
language. Only linguists, literary types and tech people are specific 
enough in their language usage to need a large vocabulary. For instance, 
I had to study historical linguistics to get a specific enough vocablary.

Change face to jewel and I'd be happy with facet

Attribute of what? It's a documentation thing. Facet is clearly (and 
always) related to face.

I find absolutely nothing confusing about facets. They are used in 
one single place in the system and they are used in hundreds of places 
inside styles as paths.

faced

 appears more to be a play on words and it should probably be replaced 
 with something else.

And technically, "attribute" is incorrect. "Attribute" means something 
that comes from the subject (is attributed to it). "Part" is right.

The currently used words for styles:

name:    ; WORD!   - style's name (identifies the style)

facets:  ; OBJECT! - the modifyable attributes of the style (properties)

draw:    ; BLOCK!  - draw block with facet words (from face and style)

actors:  ; MAP!    - face actor functions (e.g. on-click, on-resize)
options: ; OBJECT! - prototype of face/options object
parent:  ; WORD!   - parent style (if specified)

state:   ; BLOCK!  - prototype of (extensions to) face/state object
content: ; BLOCK!  - panel layout for composite styles

faced:  ; OBJECT! - prototype of face/facets (face instance facets)
about: "Not documented."

These are the words for a face instance:

style:   ; WORD!   - name of the style for this face

facets:  ; OBJECT! - properties unique to this face (from style/faced)
state:   ; OBJECT! - state variables (not properties)
gob:     ; GOB!    - graphical object(s) for this face
options: ; OBJECT! - optional facet changes as specified

; NOTE: optionally extended in face creation with:
;name    ; WORD!   - reference name
;reactors; BLOCK!  - block of user actions

; PANEL faces also add:
;grid    ; OBJECT! - layout parameters and limits
;faces   ; BLOCK!  - faces of the panel:
;triggers; BLOCK!  - triggers used by panels

Your "template" and "model" are the most accurate, if not specific. 
The word "ideal" would require too much explanation.

And facets are the visible properties, not just any locals.

faced objects are -> faced object is
And it might not be an object, I don't remember.

view/no-wait [ text-list []]
crashe if you try and use the mouse to close the window down

Yes ... 
and some are 

set-face and others are set ...

You're too generous. The GUI is pre-alpha, and wouldn't be considered 
alpha without the layout model changes Carl has said he has planned 
(but then had to take a break to work on lower-level stuff for a 
year).

perhaps at initialization ... grab all the set words in names and 
store them in a block in the top window

One shouldn't need to access faces directly. In time, I think GET-FACE 
and SET-FACE will do this, but you might need to pass the window 
face first:

get-face window my-form


Carl already has used a /field refinement, but I'm not sure what 
it does.

Someone should write a software book called 'The Joy of Naming'. 


We're used to 'facets, and I don't have anything against it, but 
it's telling that description for it uses both 'attributes and 'properties. 
I don't expect it will change at this point. We all just need to 
help new users learn what it means. 


'Template doesn't sound bad. It's funny, in OOP you have the concept 
of inheritance from a parent, but I don't know of a common term used 
for the view from the other direction. 'Attributes is probably the 
most common, but you don't hear it discussed as the base classing 
passing them on.