World: r3wp

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

Or I have something wrong in the demo code, not yet fully adapted:

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 'vpanel [columns: 1 content: pick test-blocks index]
;		insert-panel-content pan pick test-blocks index
		poke test-panels index pan
	]

	set-panel-content main-pan pan
;	switch-panel main-pan pan 'fly-right
]

view [
	title "R3 GUI Tests"
	text (reform ["R3 V" system/version "of" system/build])
	bar
	hgroup [

		; List of test sections:
		text-list test-sections do [view-sub-panel value main-pan desc]

		; Panel for showing test results:
		vgroup  [
			desc: text-area "Please read the instructions below."
			options [
				max-size: 2000x40
				text-style: 'bold
			]

			main-pan: vpanel [
				text "test" ;doc instructions
			] options [columns: 1 init-size: 280x380]

			hgroup [
				button "Source" do [
					either current-panel [
						view-code trim/head mold/only pick test-blocks 
current-panel
					][
						request "Note:" "Pick a test first."
					]
				]
				button "Halt" leaf close halt
				button "Quit" maroon quit
				check "Debug"  do [guie/debug: if value [[all]]]
				check "Remind" guie/remind do [guie/remind: value]
			]
		]
	]
;	when [enter] do [
;		if quick-start [
;			if spot: find test-sections quick-start [

;				view-sub-panel index? spot main-pan desc  ; for faster testing
;			]
;		]
;		;[request "Alert" instructions]
;	]
]
;[reactors: [[moved [save %win-xy.r face/gob/offset]]]]

Pekr, can't you post the whole script somewhere on the net so I can 
download and see what it does?

yes, sorry, wait a little bit, I am at our subsidiary. But maybe 
I could discuss it personally with Ladislav, as I am in Turnov, some 
20 km from Liberec :-)

hmm, do you intend to visit Liberec today or tomorrow?

:-) I don't know if I will have time for that. Still at Aminostar, 
today 3 hours I will write a project doc, tomorrow ditto Aminostar, 
and I should leave for Prague in teh evening. So - if I would be 
supposed to visit Liberec, it would be sometimes after the luch, 
having some 1-2 hours at max ....

As Cyphre explained one concept to me, and because I have some questions, 
I post it publicly, so that others might benefit from the info. I 
was not properly understanding the structure of the panel. Cyphre 
was kind of surprised why do I need to know it, and that I might 
not eventually need it for the layout work, but the truth is, that 
I would like to understand system internals.


In R2, the structure of the face was mostly the same IIRC. And you 
put your elements into face/pane. I found out, that structure of 
face might be different for various styles. I hope I am not wrong. 
And in such a case, I suggest to document particular style fields, 
so that one does know, what does it serve for. That might be really 
good for programmers ...

I was particularly interested to know, what is the difference between 
- style/facets/names and style/names

style/facets/names is a logic value, which you can set to true, and 
it is usefull for compound styles. Sub-faces referenced by name is 
then style local, and does not leak to globals, does not get rewritten 
by new instance of the style ....

example:

stylize [
container: hpanel [
	content: [a: button "A" b: button "B"]
	facets: [names: true]
]

style/names/a, style/names/b is example for the access to the above 
....

Now I have following points to think about:


1) in REBOL we often don't user conventional naming, but if we would 
use it, then probably 'locals? would be a better name?
2) it is a logic value, why 'names, and not 'names? ?

3) for the instance locals, we use name 'intern during the style 
creation, so why not 'intern?

4) I was really so used to the 'pane (or container in other environments), 
that so far I don't like 'content, and I don't like referring to 
the name referenced faces by style/names/a. So, if my understanding 
is correct, and /content just stores the dialect (not reduced?), 
then why not:

face/intern?: true
face/pane/a, face/pane/b
face/facets/layout?


The thing is, that it is still difficult for me to understand the 
role of a gob! Because gob has a pane, and the concept of gob, multiple 
gobs, and faces organising gobs, made the concept messy in my head 
:-(

in above - one correction - face/facets/intern?, as a replacement 
for face/facets/names .....

what is actually being stored in panel/gob? And what is panel/draw-result? 
And is face/facets/content just a layout dialect stored, or already 
reduced?

Your suggestions seem logical (names? vs. names), I think it can 
be changed.

Gobs - you don't have to care about them.

Ah, return of lost son? :-)

I don't need to care about some stuff I can understand, so - I will 
investigate further anyway, just for the sake of better understanding, 
and .... because it is fun :-)

yes, from the land of flu :)

it's simple, there's tree-like gob structure. that's all

That gob structure does not comply with faces. I need to see some 
drawing, or it is a mess, which noone will ever understand. And I 
assure you, that programmers will require to understand that ...

what is the difference for e.g. between panel/gob, and panel/facets/gob?

to je kua pekne masne, to od Dakca postavime za tu cenu ve full-coloru 
:-)

akorat to proste neni potreba ... a vlastne mozna nepostavime - muselo 
by se zpocitat, kolik by z toho jednoho panelu byl prouzek

uh oh... is it really bad now? :-)

oh sh*t, that belonged to my brother into different world :-)

We can't easily make 50x50 button for e.g.? With Carl's GUI, it was 
really easy - button "50x50" 50x50, but with new gui, even if initial 
size is valid parameter of an option block, the requested size is 
not prserved, as can be seen by simple: view [button 50x50 "test"]


I hope we are not back to nonsense of being more clever than what 
user wants, limiting the size of a button?

right, and then you want to set the color and other appearance items 
that are supposed to be managed by the skin. :-)

but you need local overides for almost anything.

we musn't fall into the trap of *only* using styles.

I meant *pre-defined* styles.

honestly I want to be able create big red buttons.. :) I like freedom.

honesty, these things are what keeps us from doing really great GUIs.

no. having an engine which provides great GUI defaults is essential, 
but not at the cost of being able to tweak a widget .


skins/themes/stylesheets provide usefull defaults,  but having access 
to overide any of this is absolutely necessary.

I don't want to rely on the fact that   'red-button-which-doesnt-resize-aligns-right-bold-with-larger-white-font 
  is a style   ;-)

and all of this has to be able to change dynamically.

I have already explained why before, so I'm not going to do that 
again. But suffice it to say, that it's my personal opinion and may 
be overridden. I just think it's a shame to be blinded by apparent 
"freedom" by having the ability to meddle with faces directly. When 
building large apps, this is a mistake, an illusion of freedom.

sorry, but having built "large apps" and for clients, this freedom 
is very necessary.  


if you don't use it that will make the gui generally better, but 
there is always a time when its required and it has to be possible.


what VID lacked had nothing to do with styles and looks.  it was 
the fact that everything under it was insufficient at best... layout 
sucks, event system sucks, dynamicity sucks, no way to switch stylesheets 
on the fly, no locale, etc.

VID's strenghts where the fact that inline styling was possible and 
easy, you could store and use stylesheets and the dialect was very 
innovative.

the best VID users built stylesheets as a lib and then used that 
directly with the least inline styling possible.  but you always 
require to tweak things here and there.  even when the layout resizes 
on its own

I don't agree, and I've also built large apps, both with the VID 
Extension Kit, which supports the philosophy of restrained access 
to faces and RebGUI, where face hacking is necessary. The former 
is significantly easier to work with, than the latter due to not 
needing to be explicit on every single twist and turn. The lack of 
proper uniformity does not leave room for an intelligence beyond 
the style level, and you will not unveil the potential for reducing 
code size, testing times and greater overall consistency and stability.

the single most important part in all of that is "hacking is necessary" 
which means that without hacking you can't do much... 

it most not be necessary it must be possible.

When it becomes possible, people use it and then over-use it. Thereby 
we get incorrect methods for building proper layouts and we can't 
go beyond where we are in intelligent handling of a layout.