World: r3wp

So, the current state of the RETURN keyword poll is A:B = 0:4

A show face user poll:


We decided to introduce a face attribute allowing to implement the 
following show states of a child face of a panel (or, eventually, 
other container):


1) the face is visible and it resizes/repositions together with its 
parent panel

2) the face is invisible, but it resizes/repositions together with 
its parent panel, reserving the appropriate amount of empty space 
for itself

3) the face is invisible, it does not resize/reposition itself together 
with its parent panel, the positions of other faces in the panel 
aren't influenced by the presence of the face

4) the face is visible, it does not resize/reposition itself together 
with its parent panel, the positions of other faces in the panel 
aren't influenced by the presence of the face

Possible implementations:

===A


Define a new SHOW? facet (you may indicate your preference to use 
a different attribute name, if you like), which could be set to one 
of the following four REBOL words, corresponding to the above defined 
face show states:

A.1) VISIBLE
B.2) HIDDEN
C.3) IGNORED
D.4) FIXED


(you may indicate your preference to use different words, if you 
like)

---Advantages


*The user can to determine the show state of the face by examining 
just one attribute, the SHOW? attribute.

*When using an appropriate function, the user will be able to change 
the show state of a face by evaluating a

    SHOW-FACE state

expression.

---Disadvantages


*Data are not normalized, seen from a data-related point of view 
- if a user sets the FACE/GOB/SIZE value inappropriately (e.g. if 
FACE/GOB/SIZE is 0x0, while the SHOW? attribute is set to FIXED, 
or, if the FACE/GOB/SIZE is non 0x0, while the SHOW? attribute is 
set to HIDDEN), the state he obtains will not be consistent.

*Speed - since it is necessary to test which of the four variants 
has been chosen, we need to use four tests in resizing code, i.e. 
the code becomes slower.

*More complicated code - it is necessary to take care the state is 
consistent, which may require more complicated code, maintaining 
state consistency.

*Documentation - the users need to be aware, that not all changes 
produce consistent state.

===B


Since the invisibility of faces is already implemented by setting 
the FACE/GOB/SIZE value to 0x0, we need to implement only an attribute 
telling, whether the face resizes/repositions with its parent. A 
RESIZES? attribute (you may indicate your preference to use a different 
name of this attribute) is used for the purpose in this variant, 
possible values will be TRUE and FALSE.

---Advantages


*Normalized data - all four possible state combinations are meaningful, 
and consistent.

*Speed - when needing to test whether the face needs resizing, only 
the RESIZES? attribute needs to be checked.
*Code simplicity

*Documentation - the user does not need to memorize the possible 
inconsistencies

---Disadvantages


*The user does not have the SHOW-FACE function, but, if required, 
it can be implemented easily, it can even use the keywords mentioned 
in the A variant, just translate the state to respect the B implementation.

*The user will not find the keywords in the face data, but it does 
not look like a disadvantage one should be afraid of.


So, please, indicate your preferences for the show state implementation. 
As far as I am concerned, I am strongly in favour of B, so the initial 
score of the show face poll is:

A:B = 0:1

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.

And, as another poll question: do you find all four alternatives 
useful, or would you prefer to use just some of them?

I'm mostly interested how the possible initialization willw work. 
If I understand your B variant it could look like this:

button "test" options [resizes?: true]	;same as VISIBLE
button 0x0 "test" options [resizes?: true]	;same as HIDDEN
button 0x0 "test" options [resizes?: false]	;same as IGNORED

button 20x20 "test" options [resizes?: false gob-offset: 5x5]	;same 
as FIXED

is that what you meant?

hmm, regarding your question: the VISIBLE is OK. The initialization 
of HIDDEN is probably not, since 0x0 sets up the INIT-SIZE, which 
is needed for resizing, i.e. it should be nonzero even for HIDDEN, 
I guess

I'm not saying is should be same as above. I'm just trying to find 
out the layout dialect based initialization for all the 'modes' so 
it is easy to use for people. I understand the SHOW-FACE function 
is not a problem to use in both variants once the layout is already 
'running'. I worry about the init part though...

Initialization is hard: for a FIXED face we still don't have a way 
how to specify the offset, do we?

I put the GOB-OFFSET here but yes, this is not set in stone as well.

GOB-OFFSET - do I understend correctly, that it is a new facet, which 
is "permanent for all faces", while being needed only for initialization?

err: understand

well, we don't need to do it that way...it could be just used as 
'gob/offset setter' duirng the layout parsing...no need to ster the 
value afterwards.

ster=store

aha, but that requires some parsing changes?

or, is that alternative already available?

yes, easy to do

a similar approach might be useful for HIDDEN faces as well, I guess

I prefer a normalizexd model, as long as it makes sense and is easy 
to work with. So, tentative support for B unless we can come up with 
something easier.

yes, we could use gob-size in OPTIONS block as 'gob/size setter' 
too.

I did not mean GOB-SIZE - that already exists as INIT-SIZE, what 
I had in mind was the HIDDEN keyword

Do you really hide something by setting its size to 0x0?

Lad: yes, we could add something like that I guess.

Brian, yes, what would you want to see on the screen if something 
has zero size?

(of course this is meant at lower level)

hiding of faces should be done by the SHOW-FACE function

hiding=visibility

I didn't mean that. Of course you hide something when it is set to 
0x0 size. I was asking if that was how you set something to be hidden: 
setting it to 0x0 size. That might have interesting effects on the 
layout of its contents when it is unhidden, while a hidden property 
would not.

Fortunately enough, it does not have side effects of that kind (we 
have to take care of one specific situation, though)

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.

(the rest of the functionality is hidden in internal layer of the 
code)

Sounds good.

Does RM-asset version of A110 support the SHAPE dialect? I can access 
the glyphs in OpenType Font File now, and I would like to draw the 
Chinese characters using SHAPE dialect in R3.

Changing the topology of the panel by ignoring the face requires 
some considerations. What happens if a focused face is ignored?

There is a demo of above mentioned features here:

http://94.145.78.91/files/r3/gui/panels-24.r3

It requires the latest sources. I'm not sure a build is made yet.

I do not think the build has been committed.

ok

%trunk/r3-gui/build/r3-gui.r3 is able to run the test

build/? hmm...

I've published it here:

http://94.145.78.91/files/r3/gui/r3-gui.r3

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

my opinion is, that most of the time I just want to unview everything, 
and only from time to time I want to unview particular window

Jerry, shape dialect is fully supported. Also note you can use chinese 
glyphs as normal unicode chars in the richtext dialect so no need 
to render it custom way in R3. Also any feedback on the rendered 
unicode fonts usage would be useful as it was just tested in basic 
tests and not in any native language like chinese, japanese etc.

Pekr, yes I thought about the UNVIEW in simmilar way.

About showing faces: In R2 I found it quite annoying not to be able 
to create an image of a layout without viewing it on screen first.

If I did things like set the face size to 0x0 or move the faces outside 
the window bounds, clipping would introduce artefacts (black regions 
not supposed to be there) in the image created by TO-IMAGE.

So, in R3 at least, I'd like to be able to create an image of a panel 
layout in R3 without first viewing on screen.

I think I thought that an UPDATE FACE function, being similar to 
SHOW FACE, except without the final copy to the window buffer, might 
be what's needed.

Cyphre, Thanks. I'd just tested it. Chinese characters can be rendered 
correctly and perfectly.

Anton, as long as you have a face you can to-image it.  no need to 
show it first.  I've done this many times.  many your problem is 
related to a specific style like a iterated face.

Late to the game, but


as for A) - don't we have already tags? It could all be in the tags 
block, not in the new field. And if tags block is just flat, and 
those for states could collide with another flag names, we could 
use nested blocks flags: [ show? [visible]]. I see no reason why 
to introduce new field, unless from the speed reasons

Generally I like B) more, but:


I definitely don't like being dependant upon the size of 0x0? That 
seems really strange to me. Visibility state in the gob-tree should 
be imo independent from the size? E.g. look at Cyphre's code example:

button 0x0 "test" options [resizes?: true]

Do you really want to see code like that in the VID level?

ah, should read the whole discussion first - already decided ...

I see no reason why to introduce new field, unless from the speed 
reasons

. Yes, it's faster and the code is also easier to handle for user.
already decided
 - really?

Cyphre: "Brian, yes, what would you want to see on the screen if 
something has zero size?" - really, I am not sure I care about if 
something is theoretically visible in 0x0 size, because face itself 
will not have a meaning even with 1x1 size, but I think that visibility 
(event flow) should be separate. OTOH, I can't find any practical 
reason how it could be internally usefull to have some inner state 
as shown, while being at 0x0. I thought about some graph models, 
event flows via the face hierarchies, etc., but with 0x0 size, you 
can't receive events anyway (apart from timer events maybe)

Max - speak on :-)