World: r3wp

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.

As a non-native speaker CONTENTS sounds quite strange... and I wouldn't 
remember to add the S after a couple of weeks not using it.

Is CONTENT(S) the best word here? You said "to signal something inside 
the face changed, and the face needs to update". How about:
- DIRTY
- MEMBERS
- STATE

...after a couple of weeks not using it
 - in fact, there was UPDATE-FACE/CONTENTS from the start

:-) So, I might haven't found it at all yet.

I am used to contents. But maybe I agree with Robert, that it does 
not clearly describe, what does it mean, so update-face/changed, 
update-face/dirty, would be more appropriate. Anyway - I voted for 
CONTENTS.

UPDATE-FACE is quite low-level, so you may not be forced to use the 
function at all.

Thanks, Pekr

My vote goes to: CONTENTS

As a non native speaker, I would prefere just CONTENT

'Content sounds singular; 'contents  sounds plural. Are there more 
cases than resizing and members changing to consider? It's a very 
general name, and 'content or 'contents doesn't add a lot of meaning 
to what it does exactly.

What does UPDATE-FACE do without the refinement?

I wrote it above, did you find the post?

Ah, saw it now, thanks.

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

Because of the difference between UPDATE-FACE (meaning: face dimensions 
changed) and UPDATE-FACE/CONTENTS (meaning: face contents changed), 
neither of /DIRTY, /STATE makes sense to me. /MEMBERS instead of 
/CONTENTS looks more appropriate than the other alternatives, but 
still not preferable to /CONTENTS (at least to me).

If you're not planning to have both refinements meaning different 
things, I'll go for CONTENT. But I'm also non native english speaking.