World: r3wp

sorry, my last example should have been:

child: make-face 'window compose/only [content: (lay)]

lay: [button "OK"]
child: make-face 'window compose/deep [content: (lay)]
view child

ah, my bad :-( I miss the enclosing block to lay

you need to use either the one you wrote:

child: make-face 'window compose/deep [content: [(lay)]]

,or the one I wrote

can you pass an object to make-face?

the style has to be specified as a word, if that is what your question 
was about

it was the data argument, instead of fiddling with composing a block.

Aha, you meant options? They can be supplied as #[none] meaning "no 
options supplied", or as a map! as well

but not an object?

not currently, do you want to have such an alternative as well?

you should use a map when you don't like a block

I don't see why not. I think there would be plenty of advantages 
in allowing objects as face options. They are easier to build, store 
and configure than blocks.

If it's not against some security aspects, then I support Henrik, 
and such alternative could be added. You can decide priority for 
yourself, I am not pushing for it ...

The reason we didn't allow object! for options was the 'inconsistency' 
of:
make object! object!
vs.
make object! [block! | map! | none]


in R3. We might add support for object!s but it will make the function 
a bit more complex.

I am against it, when:

- maps are available
- no convincing reason exists

As long as you can do at least the same with maps as with objects, 
then it's ok. I'm focusing on ease of building, storing and configuring 
potentially very large options for faces.

You can do more with maps - e.g. remove fields

ok, then I retract my request.

Pekr, any news about porting the Carl's gui demo ?

Not yet, apart from initial tries. I will work on it today in the 
afternoon though.

One thing is clear - it will not be complete port, e.g. fly-in/out 
effects are not supported when changing the panel content (switch-panel 
function is not adapted yet). Somy styles are also not adapted to 
the new GUI, and some are not adapted to the resizing model. I would 
welcome if RMA would do that basic work. E.g. even something like 
view [doc "text"] is guggy, and it displays the content twice, etc.

I expect those things being fixed as we go, though ...

I encourage you (with the support of RMA) to do it , as far as it 
is possible, as this demo is well conceived, very "pedagogic", and 
auto-documented.

Pekr's contribution is very appreciated, thanks.

I have a question to 'when style - is that adapted? Well, it basically 
works, in a simple panel example:


lay: [button "OK" do [print "OK"] when [load] do [print "screen on-load"]]
view lay

But when I simulate the demo, it is not triggered:


lay: [button "OK" do [print "OK"] when [load] do [print "screen on-load"]]

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

win: make-face 'window []
set-panel-content win panel

view win

in the second example, we don't even need to use 'win, just "view 
panel", and the result is the same. I simply wonder, where's the 
problem. My suspicion is, that panel content functions are not compatible 
with the 'when style?

Pekr, currently, the LOAD trigger is triggered during the 'making 
of panel' and not when the content of the panel changes. But you 
can 'workaround ' that.

Also the content handling functions doesn't process the triggers 
correctly but we'll fix that part.
The questions are:

1. Should be LOAD triggered when whole content of panel changes? 
I'd say yes.

2. Should be LOAD triggered when part of the content of panel changes? 
I'm not sure here.

To workaround the current issue you should build the panel like:


lay: [button "OK" do [print "OK"] when [load] do [print "screen on-load"]]
panel: make-face 'vpanel [columns: 1 content: lay]
win: make-face 'window []
set-panel-content win panel
view win

I such case the lay is built during the 'vpanel creation so the triggers 
get called.

OK, leaving for a business trip, but one other question:


when I click toggle, it crashes. It seems to me, that the 'of reactor 
and namely exclude panel is not handled properly, but I will try 
later ...

** Script error: cannot access faces in path panel/faces

** Where: exclude-faces -apply- apply if foreach if do-face if do 
do-bind-actor

actor all foreach do-style until if do-event do-event do-event either 
-apply- wa

ke-up loop -apply- wait do-events if view catch either either -apply- 
do
** Near: exclude-faces face name

Cyphre, thanks for the tips. If you will have any new release with 
some bugs fixed, please post it, so that I don't try to adapt already 
dated sources ...

We'll definitely release new version this week, as usually ;)

Ah, I thought that each new version is announced? OK, I will watch 
for changes myself, no problem ;-)

Cyphre's "as usually" most probably means "on Friday", and I bet 
Cyphre will put a note to the announcement group when the update 
will be available.

Interesting. I know that I was told that 'when style is not adapted, 
but - you probably saw my earlier screenshot, which shows space at 
the top of the panel. I get this, when I use the following method:

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


But - if I use Cyphre's method, the visual space at the top of the 
panel is not there. My quick conclusion is, that panel content handling 
funcitons are not compatible for various creation methods:


pan: make-face 'vpanel [columns: 1content: pick test-blocks index]
set-panel-content main-pan pan

Going to temporarily use Cyphre's version ....

How is now R2's face/pane, and earlier face/faces replaced? I can't 
see it in the structure. Is that a gob!?

>> help main-pan
MAIN-PAN is an object of value:
   style           word!     vpanel

   facets          object!   [init-size min-size max-size align valign 
   res...
   state           object!   [mode over value]
   gob             gob!      offset: 3x46 size: 572x503
   options         object!   [content]
   tags            map!      make map! [ panel true ]
   draw-result     block!    length: 45
   intern          none!     none
   name            word!     main-pan
   names           object!   [t1]


I really miss the simple aproach of R2 guys. I wish I had a /pane, 
a simple block of stored subelements, accessible via normal rebol 
series functions, so no need for me to investigate the special purpose 
functions. That's what I call simplicity.

'of reactor does not work. It calls 'exclude-faces function, which 
crashes on trying to access panel/faces, which does not exist, as 
shown above.


I have also some difficulcy to understand, what is 'of good for. 
I am not sure I like the name, as I was not able to understand the 
code like:


t1: toggle "Toggle" of 'tog      .... where 'tog is not part of the 
panel. The help string says: "Mutual exclusion of logic SET on other 
faces (radio buttons)"


I suggest alternate names - mute, mutual, invert ... that's just 
a suggestion, simply put reading 'of in the code does not make the 
functionality obvious enough for me, unless I look into docs ...

set-panel-content is imo definitely buggy (well, apart from the fact, 
that when I find the bug, most of the time the bug is elsewhere :-)

I mean - insert-panel-content ...

It contains the following code:

	content: either block? content [
		apply :parse-panel [
			content all [in panel/facets 'names panel/facets/names]
		]


So, when I submit a block to set(insert)-panel-content, it tries 
to parse the dialect. But, there is no panel/facets/names.

I would also like to report, that R3 is highly unstable, when playing 
with panels, and trying to set their content, e.g. manually to some 
slots (I tried doing directly main-pan/content: lay, main-pan/facets: 
lay, main-pan/facets/content: lay, main-pan/gob/pane: lay), to simply 
obey insert-pane-content function. It does not take much time for 
R3 to crash, and now I mean hard-crash - exiting the R3. No matter 
what nonsense I am trying to do, it should not crash R3 imo ....

re "was told that 'when style is not adapted" - it's not adapted 
to use it with the dynamicc  *-panel-content functions but works 
well if  used in normal layout handling.

How is now R2's face/pane...
 - you can use: faces? my-face to get the block of sub-faces

 'of reactor does not work ...

 - I never tried/know about this one so either it is some obsolete 
 stuff or not updated to the new changes

it probably should work for radio groups

or should be made to work

re insert-panel-content: I don't see what is wrong with the code 
snippet you posted. Can you show some real example where it fails 
for you?

re "R3 is highly unstable..." - we know about a case where R3 crashes. 
We were able to isolate the problem so it can be reproduced. Carl 
is now investigating this issue. It is possible that all the crashes 
you see are because of this one problem. Let's see once this one 
is fixed.

Cyphre - simply put - in a demo I am porting, I am not able to get 
the subpanel to work - it displays, but  don't perform actions. E.g. 
single button press causes:


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