r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3 GUI]

Henrik
14-Dec-2010
[4541]
Prior R3 demo was nice app

, from what I believe, that app served the same purpose as the style-browser. 
Having Carl's R3 GUI being more limited, it could be considered more 
bug free than the current version, thus made a better impression.
Pekr
14-Dec-2010
[4542]
well, it did not show single styles. It more showed whole topics, 
so you could see the whole forms with various styles, their setting, 
resetting, etc.  And yes, it was about the impression. I'll wait 
for style-browser fixes - the truth is, that it was never bug free 
:-)
Henrik
14-Dec-2010
[4543]
style-browser fixes - the truth is, that it was never bug free

 - the style browser does not have any relevant bugs. the styles have 
 bugs. that's the point of the style browser.
Pekr
14-Dec-2010
[4544]
whatever ... this is just playing with words, and I think it does 
not matter, as it is not a big deal (btw - when I found the bug, 
I reported it). My observation though is, that ppl naturally expect 
some visual demo or something like that - being it a former demo, 
or a style-browser - it does not matter. So - hopefully when things 
turn more stable, we could ask Carl to link R3 console demo function 
to launch a style browser?
Henrik
14-Dec-2010
[4545]
this is just playing with words, and I think it does not matter

 - sorry, I think you don't understand the importance of the style 
 browser as a *testing* tool rather than as something to show off 
 with.


If we blamed the style browser for the bugs, we'd never finish the 
GUI. I really mean that style browser bugs are irrelevant. Any more 
development on it would be to make testing more thorough. At this 
stage, it's important to build the programs as we want to see them 
working, and if they don't, the underpinnings are to blame and should 
be change to accommodate the needs. That is what's going on now.


We publish the style browser to help users get the quickest possible 
overview of the styles as they are right now, crashing or not. Showing 
off is too early.


It should be possible to have the style browser as part of the demos.
Ladislav
14-Dec-2010
[4546]
A RETURN keyword poll.


The RETURN keyword is used in groups (Hgroup, Vgroup) to signal the 
end of line/column. Panels, however, neither need nor can use RETURN 
as a keyword. There is a question, whether the RETURN keyword in 
panel specifications should be:

a) silently ignored
b) considered an error
Henrik
14-Dec-2010
[4547]
beginners will probably be irritated at b), but b) makes the most 
sense to me right now.
Ladislav
14-Dec-2010
[4548]
As far as I am concerned, I am slightly in favour of the b), which 
makes the starting score A:B=0:2
Andreas
14-Dec-2010
[4549]
b) -- also gives you the option to add a meaningful RETURN for panels 
later on.
BrianH
14-Dec-2010
[4550]
b) for the reasons Andreas said.
Kaj
14-Dec-2010
[4551]
It may be helpful to put a warning in the style browser GUI
BrianH
14-Dec-2010
[4552]
This is not a demo, this is a style browser, just like the label 
says.
Ladislav
14-Dec-2010
[4553]
:-D
Kaj
14-Dec-2010
[4554]
Browser still sounds like a working utility. It could mention that 
it's for testing the styles and they are currently expected not to 
work
Jerry
14-Dec-2010
[4555]
I used to develop a Chinese Font Engine in R2 using Win32 API GetGlyphOutline(). 
Now I am trying to do it again in R3, but this time I will get the 
glyth data from OpenType font files directly. Basically, I can read 
the Glyph data now, However, when the glyth has zero contour, my 
OpenType font format parser got error. The OpenType Spec offered 
by Microsoft is not clear to me on this.... Hope I can solve this 
problem soon. I cannot wait to see Chinese Characters in My R3 GUI. 
:-)
Kaj
14-Dec-2010
[4556]
You could use FreeType to parse the OpenType fonts
Jerry
14-Dec-2010
[4557]
FreeType? I'll check it out.
Robert
15-Dec-2010
[4558]
Jerry, the R3 stuff we have uses Freetype and should be able to handle 
Unicode.
Jerry
15-Dec-2010
[4559]
I know that, Robert. I just can't wait. :-)
Ladislav
15-Dec-2010
[4560x4]
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?
Cyphre
15-Dec-2010
[4564]
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?
Ladislav
15-Dec-2010
[4565]
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
Cyphre
15-Dec-2010
[4566]
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...
Ladislav
15-Dec-2010
[4567]
Initialization is hard: for a FIXED face we still don't have a way 
how to specify the offset, do we?
Cyphre
15-Dec-2010
[4568]
I put the GOB-OFFSET here but yes, this is not set in stone as well.
Ladislav
15-Dec-2010
[4569x2]
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
Cyphre
15-Dec-2010
[4571x2]
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
Ladislav
15-Dec-2010
[4573x2]
aha, but that requires some parsing changes?
or, is that alternative already available?
Cyphre
15-Dec-2010
[4575]
yes, easy to do
Ladislav
15-Dec-2010
[4576]
a similar approach might be useful for HIDDEN faces as well, I guess
BrianH
15-Dec-2010
[4577]
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.
Cyphre
15-Dec-2010
[4578]
yes, we could use gob-size in OPTIONS block as 'gob/size setter' 
too.
Ladislav
15-Dec-2010
[4579]
I did not mean GOB-SIZE - that already exists as INIT-SIZE, what 
I had in mind was the HIDDEN keyword
BrianH
15-Dec-2010
[4580]
Do you really hide something by setting its size to 0x0?
Cyphre
15-Dec-2010
[4581x5]
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
BrianH
15-Dec-2010
[4586]
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.
Ladislav
15-Dec-2010
[4587]
Fortunately enough, it does not have side effects of that kind (we 
have to take care of one specific situation, though)
Cyphre
15-Dec-2010
[4588x2]
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)
BrianH
15-Dec-2010
[4590]
Sounds good.