World: r3wp

Please take the not about allowing tabbing order into consideration. 
I do remember I used it in gui only few times though, so not sure 
if it is any usefull to be able to define tabbing order other way 
than in top-left to bottom-right direction?

not=note

I'm not sure if the direction is possible other than by simply doing 
it with layout, where you can flow faces in a particular direction, 
but ordering by specifying a number should be possible.

what about left-to-right guis? But dunno if we should care about 
those rare countries to support? :-) Or does layout allow already 
different than left-to-right setups?

I think it would be fairly easy to do a straight mirror of the GUI 
and just flow text in the opposite direction.

Pekr, experimentation would definitely not be wasted, we know about 
the keyboard-navigation problem, but there still may be lot of bugs 
we don't know about, like those two Graham and Claude found yesterday 
(thanks again!)

Danger, Will Robinson! Better not call Arab countries rare

Kaj, I am OK with that :-) I thought about them rare as in - rare 
REBOL usage :-)

When drawing style is going to be fixed?

Unicode should change that

Jocko - very good achievement with the demo.

Drawing - next release I think.

Is my understanding of box model correct? The GOB size is maximal 
size, and it contains content area, which is being called viewport, 
plus padding, plus edge, plus margin?

According to the following doc, Richtext is improved upon what was 
available with pre A100 releases? http://www.rm-asset.com/code/level1/r3-gui/richt-text/

As there now seems to be available info like glyph-metrics, is it 
possible to get nicer text rendering? Or is the nicer text rendering 
unrelated? Not being skilled in that area - what is kerning info 
etc. good for?

Kerning is the adjustment of the distance between glyphs

Is there anyone for who, the code in this report does not crash:

http://issue.cc/r3/1866

works here. With priori release I get rebol level error, stating 
something about copy ....

btw - this simple design shows one aspect we should adress - too 
many lines too close together. I wonder if there should be panel 
style with no borders.

there are and they're called HTIGHT and VTIGHT

Rebolek - I am not sure. Aren't TIGHT styles using different metrics?

yes they use. Ok, we can make *PANEL borderless and call current 
panel for example *FRAME

I remember style of such a name from some prior gui attempts, and 
it used tight spacing between the elements. What I am looking after 
is precise copy of vpanel, hpanel, with just zero graphics, or at 
least different border

I can see there is a backdrop style, but dunno what kind of functionality 
it uses ....

yes, naming should be:

tight: no spacing, frameless
tightframe(?): no spacing, frame
panel: spacing, frameless
frame: spacing, frame

it's windows backdrop, kind of special style

Pekr, backdrop is the window back drop. it's automatically added 
to any window to force proper redraw of the entire window frame.

hmm, there seems to be so much of colors, etc. I sometimes almost 
feel, that we overload GUI once again. In R2, there was a face. We 
introduced gob, as a means of having smaller object in memory. In 
fact, there is a face linked to each gob, no? And just print recent 
styles structure - it is now bigger than R2's face. And you also 
don't use 'intern for things which could be shared between the instances 
= wasting memory again?

You're confusing GUI with graphical subsystem. In R2, face was used 
in graphical subsystem, R3 uses gob! instead. Face in R3GUI stores 
all GUI-related informations and cannot be compared with R2 face.

R2/View starts at 7.4MB here. And running RebGUI Tour.r (containing 
all styles), goes to 16MB. R3 starts at 2.4MB, running all-styles.r3 
goes to 11.8 MB

Also, the size of the face structure is not at question. It hardly 
eats any memory, a few bytes at worst.

Studying GUI I have following psychological problem - I never know, 
what possible elements it might contain. The problem is evident, 
when you create style using stylize. Even Carl was aware of that, 
and e.g. for actors he created comments, so that user know, what 
argument it takes. Looking at various styles, I always wonder, if 
I can make any facet I want, or is there any MEGA FACE object, containing 
all possible fields? :-)

e.g. look at button facets:

	facets: [
		init-size: 28x28
		bg-color: 80.100.120
		border-color: 0.0.0.128

		pen-color: ; set by on-draw
		area-fill: ; set by on-draw
		material: 'chrome
		focus-color: red
		draw-mode: 'normal
		materials: none
		face-width: none
	]

There is no limit to what facets you can create, but facets are inherent 
to the style as tools for storing intermediate information for draw 
blocks, states, etc.

so many colors above. I wonder if draw blocks, containing drawing 
info, should not contain static varialbe definitions? E.g. focus-color 
relates only to the draw mode, when button is in focus.

So you want to create additional contexts, such as SIZE? Then you 
would have size/init instead of facets/init-size. Is that what you 
mean?

I am not sure, just brainstorming loudly. I can as well push my brain 
to accept the fact, that face/facets is a junk block, containing 
whatever you want ....

we should at least segment the code by empty lines

And now you introduced another group of settings:

			;turn auto-sizing on		
			init-hint: 'auto
			min-hint: 'auto
			max-hint: 'auto

btw - I am not sure "hint" is a good name? I know term hinting, being 
related to fonts. But - above is the way - group values together, 
add comment, use empty line as a separator from other group of settings 
...

By creating new contexts, we would have to have an advantage to using 
them. In a way, I don't mind it, as it could be used to apply particular 
groups of facets, in a standardized way, so you know that a particular 
context will have these items. But FACETS does technically not prevent 
this. From a technical perspective, I'm not sure I can find an advantage, 
since there is no difference from R3's perspective on speed or efficiency 
in accessing size, color or hinting information.

However, I can see the following groupings or contexts:

- color
- hint
- size

hint and size would be standardized map!s, as they are used by the 
system.

you would have to access them by path, not sure how it would look 
like in the source-code, as in draw block? e.g. pen color/pen-color?

you would say: color/pen. not much difference in typing.

yes

if you look into box model, items are grouped too (well, because 
they contain identical field names). Anyway - you have another food 
for thought, I am just not sure if it would help the understanding 
or clarity of the code, it depends ....

btw - when I met Ladislav, I asked him, why there is a face/gob, 
and face/facets/gob, and he was not sure it is like that IIRC. Later 
on I checked it, and it is really like that. But I don't remember, 
if he gave me an answer - are those identical gobs? Why I am seeing 
them in two places, when I mold the face?

Yes, they are two identical gobs a the reason why it's also in facets 
is binding for draw block.

a=and

so in memory it exists just once?