World: r3wp

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.

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.