World: r3wp

and the index:

	unless pan [
		insert-panel-content/pos/no-show test-panels compose/only [
			pan: hpanel 1 (pick test-blocks index)
		] index
	]

aha, insert is probably not good, since it does not replace the previous 
content - well, the problem is, that change does not work for gobs 
yet, so you need to remove and insert, until change is corrected 
for gobs

or, looking at it, we could temporarily make a work-around, until 
change is corrected

I will try after the lunch :-) The "poke" above should still be there, 
Carl imo stores already used "forms" with their last values in temporarily 
block called test-panels....

Did you have a look at the panels-20.r3 file?

Do we have a good documentation on how SHOW or screen updates occur? 
There is little point in the user having to figure this out himself 
to optimize display for speed.

Another option is to use something like:

pan: make-face 'hpanel [columns: 1]
insert-panel-content pan pick test-blocks index

, etc...

OK, I looked at it now, thanks for pointing that out. I downloaded 
it some time ago, it is not part of the distro, so I forgot about 
those tests ...

btw - I expect that you guys surely know what you do, and so far 
my gui understanding is still minimal :-) But anyway - was there 
really a need to make make-panel internal? Except for the options 
block, I found it nice, that you can easily create panel from the 
stored layout block, just by one function ....

Then I found out, that their max size was set to 900 pixels. I asked 
Carl - why? And he told me, that fields should not be long, or it 
does not look nice anyway.

 - This is the main problem I have with VID and the "official" GUI 
 stuff. If I want it that way, I want it. I don't need a framework 
 that makes my life hard. There are zillions of things people want, 
 and others don't like. For commercial apps, we need to deliver what 
 the customer wants, not what we think is best.

And, to do this, all parts of the GUI must be accessible and able 
to describe. Hence, MIN-SIZE & MAX-SIZE make sense on a face level. 
If I need to specify it, at least I can.

Our GUI will not be a toy. It's not for people just starting to play 
around. R3 needs a full blown commercial & enterprise app enabled 
GUI framework. Otherwise it will stay a toy no one cares about.

Robert - agreed - as much as there is a way to override some "defaults" 
by the stuff I want, I am mostly OK. Of course I still care for things 
being easily useable, if possible ...

Is 'switch-panel supposed to work? I get error on the following line:

new-panel/gob/offset: margin

it breaks in the following demo function:

view-sub-panel: funct [
	index
	main-pan
	desc
][
	set 'current-panel index
	set-face desc form pick test-notes index
	pan: pick test-panels index
	unless pan [
		pan: make-face 'hpanel [columns: 1]
		insert-panel-content pan pick test-blocks index
		poke test-panels index pan
	]
	switch-panel main-pan pan 'fly-right
]

I think Faced should be renamed Local. What do you think?

I find other names better, like content or collection.

Content isn't bad, but I think local is more descriptive.

http://www.rebol.com/r3/docs/gui/styles.html#section-19

The faced block is similar to facets block, but makes them local 
to each instance of the face. Now, they can be modified without effecting 
any other faces that are of the same circle style.

Faced is awful. Content has the same meaning and is less jargony. 
Maybe it's better.

I meant that content has the same meaning as local.

FACED is supposed to be long gone. Maybe that's not the case for 
the current release?

I think that in the new release FACED is really gone. Nicolas points 
to RT's docs, which imo refer to Carl's GUI, not RMA's one.

Hmm, so I did some tests, and here's my observation:


- I still have to complain, that in order to MAKE PANEL, I have to 
use function MAKE FACE, even if function of corresponding name exists, 
and was made useless for such purpose :-( Easy things SHOULD be easy 
to do


- The suggested code of pan: make-face 'hpanel [columns: 1] is self-explanatory, 
but then SWITCH-PANEL function does not work. And the possibilities 
are:
                     - this function is obsolete
                     - this function was not adapted to new stuff

                     - make-face does not create sufficient/expected output


The problem is in the following code - I have two panels - m = main, 
p = child:


view [m: hpanel [text "test"] options [init-size: 200x200] button 
"switch" do [switch-panel m p 'fly-right]] 

p: make-face 'hpanel [columns: 1]
insert-panel-content p [button "hello"]
view p ;- check it ....

It crashes on switch-panel, because:

>> p/gob/offset
== 571x384

>> margin: get-facet m 'margin
== [0x0 0x0]

>> p/gob/offset: get-facet m 'margin
** Script error: cannot set offset in path p/gob/offset:


So - does make-face create incompatible structure? Is 'switch-panel 
supposed to work? And if not, how do I support those fly effect for 
switching panels? Just don't push me to manually use insert-panel-content 
and tonnes of similar functions?

SWITCH-PANEL is not supposed to work, since it was not adapted yet, 
not having high enough priority.

(in the above example you see, that the margin uses two pairs, while 
gob/offset is just one)

I know, I thought I would adapt switch-panel, but dunno if it would 
be usefull.

I would also like to understand your working plan - why are some 
usefull features removed at all? I can understand, that if things 
break, you set some priority to fix them, or not. But both make-panel 
and switch-panel just worked, whereas now they are replaced but tonnes 
maybe fine-grained functions = better flexibility, but also removing 
visual effects.


I still hope, that having switch-panel is possible, using new *-panel-content 
functions, and that transition effects are still possible ....

Once again - simple things should be simple to do, and simple even 
in my code - when I make-panel, I make panel, not a face. When I 
switch-panels, I just switch panels, so no need for user to care 
about panel content handling funcitons imo ....

OK, I will adapt ... the intention is to make demo working on RMA's 
GUI. We will see, how it turns out down the road ... I am slow, because 
I still have little knowledge of GUI itself, pluse I am really not 
a programmer :-)

... but -better to do something, than nothing ...

it's possible that you have to use different methods than what Carl 
used. many functions were dismantled and rebuilt to support higher 
granularity and this process is not entirely complete yet. in the 
end, it should be just about as easy to build the demo using RM Asset's 
version as well as Carls, except for more solid behavior.

Yes, it is just my general opinion is, that higher modularity could 
be hidden from user, if possible. But as I said - I now have an idea, 
that something like switch-panels should be rather easy to be rewritten 
using new functions ... I got simply confused, as I found the switch-panel 
function in the distro, so I assumed it should work. Now I will be 
more carefull ...

transition effects: that may have to wait as animation is low priority, 
but when it becomes possible, you may well have much better options 
for doing real animation.

OK

Should text style work?

text [bold "Toggle button..."] gives me:


Script: "R3 GUI - Development Test Script" Version: 0.1.2 Date: none

** User error: {TO-TEXT - syntax error at: [bold "Toggle button..."] 
...}

Got to go - but - is there anything like vpanl alignment? I got first 
form of demo kind of working (buttons), but the content is aligned 
to the bottom. Also - pressing buttons does not work so far either:


** GUI ERROR: Cannot parse the GUI dialect at: panel 240.100.80 title 
Alert grou
p doc Button pressed! scroller

But both make-panel and switch-panel just worked, whereas now they 
are replaced but tonnes maybe fine-grained functions = better flexibility, 
but also removing visual effects.

 - are you not able to read? SWITCH-PANEL is not replaced by anything

Carl's comment after a "preliminary peek": "It seems that the design 
is going well, and this team is very REBOLish in their methods and 
concepts.  So, I am not worried."

preliminary peak
 = Carl did some recent revision? :-)

If so, good he is catching-up back to R3 stuff!

He also reviewed CureCode

I am still probably not understanding, how to properly use panel-content 
functions. Second consecutive run of following code causes a stack 
overflow ...

lay: [button "OK"]

child: make-face 'vpanel [columns: 1]
set-panel-content child lay
view child

how exactly am I supposed to reproduce it?

Err, that [columns: 1] is an anachronism, we replaced it by [break-after: 
1] (for a hpanel, break-after specifies, how long the rows are, while 
for a vpanel, how long the columns are)

so, the [columns: 1] is ignored

Ladisla - thank, that was it. I mean - break-after fixed it.  With 
above - columns, to simply reproduce it, just view child, close the 
window, and call view child once again ... it breaks to console after 
a while with stack overflow. Well, now I know that 'columns is not 
used anymore, but you might try to look at it, if you have time, 
to see why it causes stack overflow ...

Hmm, nothing seems to be fixed ...

Could you try following code? You can eventually replace 'vpanel 
by 'hpanel [break-after: 1]. With vpanel, it just causes stack overflow, 
with hpanel, it kind of displays panel, but try to resize the window 
and see the mes ...


REBOL []

do %r3-gui.r3

lay: [

		when [load] do [print "Load trigger!"]
		clicker
		button "Do" alert "Button pressed!"

  button "Big Quit Button" maroon options [max-size: 2000x50] quit
		bar
		text "Toggle button..."
		t1: toggle "Toggle" of 'tog
		button "Set False" set 't1 false
		button "Set True"  set 't1 true
		toggle "Mirror" attach 't1
		toggle "Mutex" of 'tog
		bar
		text "Radios and check boxes"
		radio "Set above toggle on"  set 't1 true
		radio "Set above toggle off" set 't1 false
		bar
		check "Checkbox attached to above toggle" attach 't1


]

child: make-face 'vpanel []
set-panel-content child lay
view child

Well, I stop my tries to port a demo now. My take is, that following 
primitive code should work easily, when repeated for the second time, 
but it does not:

lay: [button "OK"]

child: make-face 'hpanel [break-after: 1]
set-panel-content/no-show child lay
view child


My take is, that either make-face is not creating a structure needed 
later, or 'parse-panel is buggy, or I don't know what :-)

** Internal error: stack overflow

** Where: reduce switch parse to-text reduce parse to-draw all update-subgobs 
fo

reach update-subgobs show-native show-native show-native show-native 
show-native

 show-native show-native show-native show-native show-native show-native 
 show-na

tive show-native show-native show-native show-native show-native 
show-native sho

w-native show-native show-native show-native show-native show-native 
show-native

 show-native show-native show-native show-native show-native show-native 
 show-na

tive show-native show-native show-native show-native show-native 
show-native sho
w-native show-native show-native show-native s...

eh, excuse me, couldn't following code be causing an infinite loop? 
:-)

show-native: :show
show: funct [gob][
;	print "SHOW>>>>"
;	set 'gcnt 0
;	t: now/time/precise
	update-subgobs gob
;	print ["updated:" gcnt "GOB(s) in " now/time/precise - t]
;	t: now/time/precise
	show-native gob	
;	print [now/time/precise "SHOW call in" now/time/precise - t]
;	gob
]