World: r3wp

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?

Cyphre:

box-model:
---------------


Few notes. Certain systems use FLAGs, which could be thought about 
as kind of switches, or representing certains states, etc., used 
in binary masks for e.g. Then we have TAGs. Even R3 GUI uses tagging 
- it is used mostly to mark particular face as behaving some way, 
belonging to some area, etc. And in that regard, I wonder if box-model 
type could be done just by using TAGs? 


What I think about TAGs in GUI in general is, that we don't use the 
concept to the max. I mean - if tags were not be flat block, but 
block of blocks, it could be used even more, e.g.:


tags: [box-model [tag1 tag2 tag3] style [internal] draw-mode [normal] 
resizing-mode [.....] ....]


Of course that might not work for us in all cases, because as you 
could see in above example, it would be difficult to distinguish, 
if something should be a facet, or a tag. E.g. if we would move DRAW-MODE 
into TAGS, then why not moving MATERIAL there too, etc. My question 
is - is there any rule for me to remember - what should be a facet, 
and what could be a TAG? (I expect the difference in how you work 
with them underneath)


My general problem is, that FACETS block is becoming long and messy, 
so what to do about it? There were following suggestions to think 
about:


1) close particular settings in subobjects/maps (whatever). There 
are settings belonging to the areas of resizing, colors, box-moderl, 
others, etc. The question is, if we want to refer to such values 
by face/color/bg-color for e.g.?


2) the simplest solution is to at least use some source code conventions. 
E.g. Carl introduced comments to particular ACTORS, desribing what 
arguments are supported for the function. So my idea is:

facets: [

   ; colors
   bg-color:
   other-color:

   ;resizing
    resizes: 
    init-hint:
...
]

ALIGNment:
----------------


It is probably not wise to change all subsequent areas to halign, 
valign. But anyway, we are a bit chaotic here, unless someone tells 
me, what's the rule here - to stay compatible to html/css, or to 
be consistent REBOL wise? I mean - if various areas use ALIGN/VALIGN, 
then my logical question is - why HPANEL/VPANEL, and not PANEL/VPANEL?


My comment is just food for thought, not a claim to change anything.

Dunno where to chat about Jocko's demo, but as Henrik suggested to 
move here:

- some parts are sluggish


- for Rebolek - you can look at Demo/To-Do section - Jocko outlined 
some changes he made to some styles. His demo does not work with 
current RMA release if I am not wrong.


- we should generally start to think, about how to "unload" certain 
GUI parts from memory. By just clicking here or there I got from 
11MB to 38MB of memory usage. In some old GUI I used, it kept track 
of windows, and those were GC'ed when closed. In REBOL, if I am not 
mistaken, after the layout, faces objects are defined, and there 
is no automatic way of how to "undefine" them and free the memory. 
So my question is - will that be addressed, or is user responsible 
for the resource tracking? And is it even adressable?

re synonyms .. not really .. one understands that horizontal is default

which is why in html we have align, and valign

What Graham suggests is also my question above ... and it would be 
consistent with subsequent align vs valign?

I'd like to keep to convention as much as possible because you might 
be coding in 3 different languages at the same time

No worry - even if you will be coding in RED, it will not have GUI, 
so :-)

But - jokes aside, I am starting to like the idea of having PANEL/VPANEL, 
and GROUP/VGROUP .....

Pekr, so your convention would be opposite of Graham's? :-)

No, the same .... where's the opposition?

it's the same

If I understand Graham correctly, he suggest to have default a horizontal 
alignment = compatible with underlying align/valign. Hence what he 
imo proposes (and I agree with), is to remove "H" letter from PANEL/GROUP

Graham:

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

Pekr:


I am starting to like the idea of having PANEL/VPANEL, and GROUP/VGROUP 
.....

so, you have to agree on the flow direction. :-)

Henrik, I think that Graham and Pekr really want the same thing. 
Panel and hpanel as synonyms, in other words - panel/vpanel. :)

I was saying that group & hgroup are to be synonyms

Rebolek, yes, I was just teasing. Perhaps it's not a bad idea. VID 
itself also has a default direction that it lays out in, which can't 
be seen in layout code.

One general question to GUI/gfx gurus. I know it is very preliminary, 
but - what about scaling? I mean - playing with my phone, I wonder, 
if it is facility of mobile OS, or particular app is receiving some 
zooming info, and acts accordingly? Are we ready for something like 
that? Because just recently, what we do is - resize. But we don't 
scale (fonts). It is just question of catching particular OS events, 
and create particular actors?

What I am seeins is, that e.g. in mobile Opera, zooming in/out, steel 
keeps content nicely resized/scaled. And even very small fonts are 
nicely readable ....

I do remember, in R2 initial VID implementation (the times Holger 
was at RT), there was some facility to support scaling at "raster" 
level? But IIRC it was never used, or the result was ugly? I don't 
remember anymore. Because I can imagine two ways of how to do it 
- having some good raster level methods, or to scale particular UI 
elements.

The best way to check probably would be to buy some Windows 7 tablet, 
e.g. Galaxy tab 1, as R3 should work there out of the box - imo no 
chance to see R3 ported to any other mobile system in foreseable 
future, unless there is some background effort we don't know about 
...

I saw scalling mentioned in some early VID documentation and probably 
some facets were reserved for it, but that's all that has been done 
I think.

Is there a plan to use 'switch-panel function in future, along with 
its transition effects (fly-outs)?

I'm thinking about a style that is basically a fancy text list with 
the specific purpose of using it as a panel switcher. But specifically 
the animation part, it may be better to have some kind of actor (on-switch?) 
where the animation is handled and can be specified separately.

SWITCH-PANEL isn't needed anymore, as this functionality is covered 
(much better) by SET-PANEL-CONTENT. Transition effects are possible, 
but I would rather wait for timers, so they can be real non-blocking 
animations unlike old fly-outs.

Rebolek's response is more valid than mine.

Old flyouts changed offset in loop, so if you switch panel's show-mode 
to 'fixed, you can make this effect very easily. You can also animate 
resizing this way, but GUI will be blocked because show is handled 
inside loop and not using timer event. But if you keep the loop short, 
user won't notice that the GUI is blocked.

ah, timers - those are not part of R3 core yet, are they?

nope.

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.