World: r3wp

We had a small discussion about MAX-SIZE this morning. In short, 
I don't like it and think it's not needed. Everyone else loves it, 
so it won't go away. Therefore I'm proposing a RESTRAIN facet (name 
not final). Without explaining what it is, can you guess what this 
does:

Before:

bar: box [
	facets: [
		init-size: 100x2
		min-size: 20x2
		max-size: 10000x2
	]
]

After:

bar: box [
	facets: [
		init-size: 20x2
		restrain: [vertical]
	]
]

why it's a block?

Decided that it may not need to be a block: Another suggestion is 
words: HORIZONTAL, H, VERTICAL, V, or BOTH.

I propose -1 as unlimited value.

also if you give me such a piece of code (both), I'm not sure what 
the results will be, but I'm not following the developement so I 
don't know details about resizing.

for example, when I would use bar, what size it will have? 100x2, 
20x2 or max-widthx2?

with max-width i mean max available width of course.

For max-width you would use max-size: -1x2

you mean the max width which the resizer could use? Do I understand 
it well that the BAR shoudl be something like HR tag in html? Then 
it should be possible to specify width in percent, shouldn't it?

restrain is not typical word of my english vocabulary (I know, my 
fault), and even reading its 20 meanings gives me almost zero idea 
of what it does.

Oldes, it means a full width line across the widht of the parent 
face

Using max-size: -1x2 still requires you to know the Y value, if you 
are using it as an option in layout, so you need to study the style 
code to know it. Hence the need for RESTRAIN.

Your example is not layout but stylize example, but ok.

facets: I'm all for keeping one single place to keep all these properties 
and throw everything in there. No further sub-structuring. Why? Because 
this would require a MECE approach (which is IMO a very subjective 
thing) and I have to remember more things. Now I know the stuff is 
in: facets/<some-meaningful-word>

Rebolek, same issue: STYLIZE may be used by a third party person, 
not knowing the original style size or not wanting to depend on it, 
if the original style changes.

Robert - OK, then lelt's keep the organized a bit by spacing (new 
lines) and comments, as I suggested ... that might be enough imo 
and grouping certain areas together helps users to faster identify 
particular related facet?

No problem with this. What I would like to have is a way that I can 
write:

? text-table/facets


And get a dump of all available facets and a description what it's 
for.

Hi, guys

Once again, congratulations for the excellent work done.

As Rebolek suggested in ALTME, I have some modifications to submit 
(of course, to check from your side) for the next r3-gui release.


I must first mention that I just realized this morning that the r3.exe 
 pre-compiled version of march 11th was not working properly, bugging 
with some very simple text displays (probably an old version). That's 
the reason why I did not update the demo with the most recent r3-gui 
file. By the way, the  build date displayed by the exe remains the 
same whatever the real building date. I don't know how we could have 
an automatic update of the build version.


Rebuilding from your sources (march 11th) allowed the demo to work 
properly apart from some appearence differences (I have even seen 
some bugs solved compared to my demo version). However, I will wait 
for your next weekly release ;-) to update my demo.

Coming back to the propositions of modifications :


It seems that there are definitions problems, or incompatibilities
in r3-gui (around line 66)        
;-- circle: [pair! | number! | number!]    
circle: [pair! | pair! |number! | number!]

in r3-gui (around line 1729) 
;-- scale: [decimal! decimal!]  
scale: [pair!]

also, I overload the drawing style by this code :
stylize [
    drawing: sensor [
        about: "Simple scalar vector draw block. Can be clicked."
        tags: [input tab]
        facets: [
            init-size: 100x100
        ]
        options: [
            drawing: [block!]
            init-size: [pair!]
        ]

        actors: [
            on-make: [
            ;    if block? drw: face/facets/drawing [
            ;       bind face/gob/draw: copy drw face/facets]

            ]
            ;-- JC
            on-draw: [face/facets/drawing]
        ]
    ]
]


Concerning the discussion of this morning on groups and panels, I 
would also prefer to have a default horizontal arrangement, and only 
precise when vertical: group, panel, vgroup, vpanel. A side effect 
is that it would remain compatible with Carl's doc.

By the way, it seems that tight is vtight. Logically, it should be 
htight.


That's all for the moment. When debugging the last demos, I may find 
other issues.

From R3 GUI sources:

tight: vtight [] ; for compatibility right now, will be removed

(in case you don't have access to source comments)

Both of these loom wrong, Janko:
;-- circle: [pair! | number! | number!]    
circle: [pair! | pair! |number! | number!]

Wouldn't it be this instead?
circle: [pair! | number! number!]

loom -> look

yes you 're right. Surprisingly the second works.

My notes to the HPANEL versus PANEL issue:

* Carl appears to prefer PANEL

* unfortunately, the situation is not as easy as it looks at the 
first look, since Carl's documentation uses the word 'panel' it yet 
another sense, every style able to contain faces, such as a group, 
etc. is called "a panel" in Carl's documentation, which would immediately 
lead to confusions, requring rewrite

* e.g. the INSERT-PANEL-CONTENT, or some other function names would 
be confusing because of the above mentioned issue, since the function 
in fact inserts content to any "face containing style", not just 
to HPANELs


So, the amount of rewriting both the code and the documentation would 
be quite big.

Everyone else loves it

 - I expect a little more objective statements than this. In fact, 
 I don't "love" MAX-SIZE at all. I just know (you have proven it), 
 that some relevant frameworks (like the OSX GUI) include it. I am 
 sure that is the reason, why Carl insists on it as well. So, if we 
 want Carl to "throw our changes to the R3-GUI to the basket", we 
 can remove the MAX-SIZE to achieve that goal.

Ladislav, Carl told me that MAX-SIZE was necessary so that buttons 
would not become unnecessarily wide, but it is the wrong way to solve 
such a problem, much like putting a rock under the gas pedal to prevent 
the kid from going more than 30 mph in dad's car. Nevertheless, when 
(hopefully) we get some parts automated here, I will never need to 
deal with MAX-SIZE again directly.

And OSX does not provide maximum size for widgets, only windows.

Henrik - two things - first you should consult Carl (if he is available 
to RMA), and second - Ladislav will probably state, if there is a 
way of how to adapt his alghoritm, so that we can work without the 
MAX-SIZE? I personally don't mind MAX-SIZE anymore, as I have to 
set xy things anyway - hints, init-size, min-size, as needed. And 
if I am a style authoer, then I can always set MAX-SIZE to some artificial 
value, so :-)

Pekr, a solution has been found, so no worries.

much like putting a rock under the gas pedal to prevent the kid from 
going more than 30 mph in dad's car

 - that is a nice metaphor, but I would use a different one. In many 
 contemporary cars there are means to limit the revolutions of the 
 engine. They are there, and I do not think they are meaningless. 
 They limit the revolutions of the engine exactly like a rock under 
 a gas pedal eventually could (rock under a gas pedal certainly cannot 
 limit the speed).

Very short initial report to the new release:


- keyboard area text hilight problem still persists (when hiliting 
from the bottom up, only one line is hilited)

- drop-down shold be closeable by - clicking elsewhere in the gui, 
clicking arrow of drop-down, or hitting ESC

As we have DO-TRIGGERS, what do you guys think about my CC ticket, 
suggesting to rename DO-FACE and DO-STYLE by DO-ACTION, DO-REACTION?

Pekr,

text hilight problem

text highliting is not yet reviewed so it will be probably fixed 
in the next week.

drop-down shold be closeable by

we'll be adding more robust system/user shortcuts system soon so 
all styles controls will be corrected during that round

regarding th emoving style settings from FACETS to TAGS..this is 
not much practical as it is not to redefine TAGS by inline definiton 
in the layout.

Jocko, rgearding the: circle: [pair! | number! | number!] definition.

This is correct as the definition doesn't describe the exact syntax 
of the command but it works more like the rules used by DELECT.

So in this case the CIRCLE command can be used only in these combination:
circle pair! number!
circle pair! number! number! 


which corresponds to the syntax described here: http://www.rebol.com/r3/docs/view/draw-curves.html#section-3


Ofcourse, now when the float pair! has been implemented we could 
extend the syntax for another pair to:
circle: [pair! | pair! | number! | number!]
to allow also:
circle pair! pair!


but this change needs to be reflected also in the to-draw function 
and dialect-draw definition object used by DELECT in the R3GUI.


I'll add this enhancement so it will be available in the next RMA 
release for you.


Also note, the current DRAW dialect (implemented by the preprocessor 
mezzanines) is trying to reflect only  the R3 draw reference documentation 
(in the link above) syntax which has been designed at the time the 
float pair! was not available. The review of the syntax is planned 
in the future.

Cyphre, thank you for the info and the link.

Please don't do special changes for me, unless you see a real interest 
to do so.

User poll, which of the following refinement names would you prefer?

    UPDATE-FACE/CONTENT

, or

    UPDATE-FACE/CONTENTS

?

Contents sounds more natural to me so I'll vote for it.

That is what I thought was more "natural" for native english speakers 
too. But, looks like Cyphre (maybe other non-native speakers as well) 
is not used to it, (e.g. in Czech the equivalent "content" is usually 
singular).

For me, the differences in the two words is quite sublte. The word 
contents gives the impression of something more tangible than content. 
As an example, I would say the content of the book to refer to the 
overall meaning of the book. I would refer to the contents of the 
book as the list of chapters.

Though I'm not sure that examples is relevant in this case.

I think it is, thanks

Just to explain what should the meaning of the UPDATE-FACE/CONTENT(S) 
be. It shall be used to "signal", that something inside the face 
has been changed, and the face needs update.

It is used for panels, groups, windows, etc.

I'd still go for CONTENTS.

As opposed to that, when just UPDATE-FACE is called, it means only 
that the face dimensions have been changed.

Most people I know would say "The contents have changed" rather than 
"The content has changed" even though the second may be "more correct".

By the way, I probably should only be given 0.1 of a vote as I have 
hardly done any GUI programming with REBOL and certainly none with 
REBOL3.

Does not seem relevant in this case.

should the name not be the same as the CONTENT(S) block of the face? 
if it's named CONTENT(S).

Yes, unification is necessary, correct, we just need to find which 
alternative is preferred.

I checked the Oxford English Dictionary for Content when referring 
to a container of some kind:


(usually in plural) what is contained in something, especially in 
a vessel, book or house.