World: r3wp

align and valign are pretty standard names if you've ever seen HTML, 
what's so confusing about them?

#[[Pekr
And align + valign is not understandable for me at all ....

Pekr]] - right you are, you should see the code to understand what 
the text means. In short, it means, that the HALIGN and VALIGN properties 
are set somehow, instead of using the default values, that are 'LEFT 
+ 'TOP

everything. Have YOU ever seen  html?

as I said - in html align = left | right | center ...

can you please explain to me, why the align + valign aligns left 
red box vertically in reverse position than signle align?

err, I meant: "ALIGN and VALIGN are set somehow, instead of using 
the default LEFT + TOP setting"

ALIGN + VALIGN does nothing

their values do

aha, now I look into the code - makes much more sense now. Then it 
is about the description in the demo, which confused me

ALIGN can be: LEFT CENTER RIGHT

as opposed to left right center... ;)

It is in the documentation

ok, my question towards the align, valign. I know we might want to 
be "compatible" to html, but to stay consistent - we have vpanel, 
and hpanel, not vpanel and panel. Wouldn't it be wise to use valign, 
halign too?

ok, got to go. So the only yet unexplained part to me is that of 
a resizing. As Rebolek hinted, it might be caused by the text being 
resized. It is just, that with examples I mentioned, the result is 
(of course IMO) not a desired one.

Regarding Henrik's FRAME note - that is a surprise for me, never 
heard about such a proposal, and disagree with it.

E.g. try also panels-26.r3 - why the last line of boxes stays "attached" 
to the bottomof the window, causing a space?

If you will say, that it is explainable by how the resizing model 
works, then I might reshape the question and ask how to avoid it?

#[[Pekr

I think that worse problem for me is how currently resizing is behaving 
in above mentioned styles

Pekr]] - resizing is behaving as it should. The problem is just that 
Bolek specified that the vertical size of the text is "unlimited" 
for resizing purposes. That is causing the layout to look ugly.

Ladislav, I discussed it a few days ago, but not to worry. Rebolek 
disagrees too, so it probably won't be done. My worry is that the 
act of creating a border or frame around a style will be an obscure 
part of a base style.

#[[Pekr

E.g. try also panels-26.r3 - why the last line of boxes stays "attached" 
to the bottomof the window, causing a space?

Pekr]] - that is an example "inherited" from Carl, and it behaves 
as it should, taking into account, how it was defined. You need to 
take a look at the code

#[[GiuseppeC

I have ran the latest RE-GUI and the examples. I have see that when 
the CHECK is off the "v" is still visible but greyed.

GiuseppeC]] - you are not the only one who dislikes this. Count me 
in.

#[[Henrik

My worry is that the act of creating a border or frame around a style 
will be an obscure part of a base style.
Henrik]] - you need not worry, it already works for all styles

Ladislav, we'll see.

No, you already can see it *is* implemented.

No, what we don't have is many varied types of compound styles, where 
this would be used. That is why I'm not convinced.

Used how? As I said it already *is* implemented.

Used for multiple compound fields, calendars, for example.

I don't understand where you see any problem.

We have also not shown that text-table can place widgets with pixel 
accuracy.

But never mind, it probably won't be really relevant until skinning 
starts.

As for example #26, I checked by adding following line to stylize:

    pad: pad [facets: [bg-color: orange]] 


So Ladislav is right, code behaves correctly - the last line of color 
boxes is shifted to the bottom by upper 'pad style resizing.

We here to help you, Pekr, we don't understand why you resist us.

What's the resistance? You just need to understand, that there might 
be some users, not understanding GUI internals imo. I put above comment 
on purpose here, explaining WHY exactly it behaves as it does. Just 
stating the something is correct without further explanation does 
not help to understand the case ..

as you can see from the discussion between Henrik and Ladislav - 
 not even RMA has unified point of view on how some features could 
be designed. So what is problem with me not eventually agree with 
what you cook behind the doors? :-)

Two notes:

- RMA is neither me, nor Henrik

- RMA has a unified point of view, it is the one you can observe 
when examining the published code and docs, all other things are 
just speculations

So what is problem with me not eventually agree with what you cook 
behind the doors?

- since we publish our results, I see this as a clear attempt to 
insult our good will.

And, especially from you, it is unfair, taking into account, how 
many times you did not put to use the oportunity to present your 
preference in various user polls. 'The informations about user preferences 
were much needed then, and it is a pity you, instead of helping us 
to know user preferences in many cases, try to dishonest our efforts 
publicly by misrepresenting it as "cooking behind the closed doors".

Ladislav - sorry, but now you should really take a break. What are 
you talking about here?

WTF is an attempt to insult your good will? Damned - this is SW development 
and desing, not a religion!

What users poll are you talking about? I do remember some, and when 
I can't take any preference, I don't participate. OTOH I put many 
comments in here. In fact - R3 situation is so "devastated" from 
the community point of view, that there is very little ppl participating 
in actually anything R3 related. Even in time of Carl's GUI, I might 
be the only public tester, may 1-3 other guys I remember. Where's 
all 300 ppl registered here with testing and comments? How much of 
input you get from any other person?

as for "cooking behind the doors" - where's the insult? Let's take 
an example with the FRAME. The only thing we knew for last two weeks 
was, that it will be somehow solved. And "somehow" = behind the closed 
door. I do remember Rebolek's preference of #FRAME keyword, some 
discussion about that, and then the release comes out, containing 
particular solution, which even Henrik (I regard him being part of 
RMA) questions ....

What I can see though, is a kind of syndrome of a developers, who 
live behind the closed door, and then wonder if another point of 
view is presented. It very often ends with statements like "you can 
take Carl's code, and do your own GUI". And I am far from alone receiving 
such a reply. And THIS is what I call as an insult, to ppl expressing 
different pov on the direction taken.

I very much respect Robert's explanation - this is not a democrary, 
this is RMA's business, and i have no problem with that. I just really 
don't understand, why when I put explanation to why I mistakenly 
marked panels-26.r3 demo as incorrectly behaving here, Rebolek comments 
that I am resisting something. I just put it here, because the group 
is searchable, and my reply contains explanation, which might be 
helpfull to others ...

This is really difficult to take, even for me. With each release, 
I download, go thru tests, read release notes, and I put my comments 
here on what i think about new additions, etc. I am the only one 
reporting actually anything here, so it logically can look like I 
am criticizing something. But could you please mark for me any insulting 
comment from my early morning report?

Guys, let's relax. Everyone can comment of course and people going 
through the code and comment help us. And it's OK if there are different 
POVs. As you can see even within the RMA team we discuss things back 
and forth and have different POVs. Which IMO is absolutly essential 
to come up with a good solution.

So, the only thing that can happen is, if you don't like something 
we still might not change it.... but IMO not that hard to life with.

Some comments:

-the TEXT style in the release has incorrect resizing settings so 
it makes layouts that are being resized ugly. We'll fix that.


-regarding the introduced and discussed:  options [box-model: 'some-word] 

The defined word! symbol should specifiy box-model preset. By 'box-model 
preset' we mean group of facets attributes that affect the box-model 
settings of the specific face/style. So this option is IMO correctly 
named.

Currently the box-model option was added as temporary solution to 
the PANEL style only. But in the next release it will be possible 
to set it on any face in the layout or style definiton. Also we'll 
add basic set of such box-model presets that will be part of the 
system by default.


-ALIGN vs. HALIGN: yes, we borrowed the terms ALIGN/VALIGN from HTML(but 
note, it is used also in R2 font object and in R3 para object) . 
As people today are familliar with it and have it 'wired' in their 
heads using the same name could avoid silly bugs in their code.

I presonally don't think this must be consistent with names of styles 
but if majority people insist of such kind of consistency we would 
probably need to unify also the align word in the PARA object as 
well.

Petr, I appreciate the effort you're putting into supporting the 
RMA team, especially since I haven't made time to do so myself. We 
can probably blame text communication, and different communication 
styles for most misunderstandings.

Robert, please consider that people is nervous for the lack of development 
and communication from CARL....

Why not leave panel and hpanel as synonyms, and group/hgroup ?


It's entirely possible, but would that not make layout code harder 
to read/understand?