World: r3wp

do you guys have an html version of that?  I don't have mdp setup.

no html needed when you just need to copy a part of it and do

...and, it is not mdp

seems to work good, nice work.

thanks

Ladislav: ""I can see you use empty rows...Aren't we wasting memory 
here?" - how can an empty row waste memory?" - :-) This is misunderstanding 
:-) My question relates to my previous discussion with Cyphre, about 
removal of 'faced element. Previously, we had facets, and faced (instance 
locals). Cyphre pointed out, that now everything is instance local, 
and goes into facets. If you want stuff to be shared, new 'intern 
slot should be used.


And that was my question - I can't see intern used anywhere in the 
stlyle definitions. What I noticed is, that in the facets blocks, 
stuff is somehow visually separated by empty rows. Hence my question 
- if I see things like min-size, max-size - aren't those a good candidate 
for items being shared? And if those are not shared (referenced), 
we are kind of "wasting" memory here. I think that it will not be 
significant though ...

In general, if you don't want to use the RETURN keyword, don't use 
the *group styles, they are designed *for the purpose* of supporting 
the RETURN keyword

 - not a big deal, really. My problem is, that what I want is behaviour 
 of panel style, but without gfx borders. But - I could create new 
 style, removing the visual elements of panel. Maybe such a style 
 could be added by default, but not sure others would find it usefull, 
 nor do I know what name to use ...

Well, empty rows in the source code are just means to organize the 
text anyway ;-)


Regarding your MIN-SIZE and MAX-SIZE - those aren't shared, since 
I thougth (and still think), that it is necessary to allow for every 
face to have individual MIN-SIZE and MAX-SIZE

Example: it is expectable, that two panels have different MIN-SIZE 
and MAX-SIZE, especially if their contents differ

Really? E.g. think about buttons. I think that all buttons will share 
those values, no? But anyway - this is just speculation on my part, 
and call for "premature optimisations". In fact I don't know how 
to measure memory consumption (even if we have stats function) of 
an object, which has two more fields (slots) plus values. Then you 
can count average number of instances your app has, and you can guess, 
how much more memory your app is going to use. I expect it being 
just KBs ....

Of course, some styles might "prefer" to use the same MIN-SIZE/MAX-SIZE 
for all their faces, but it is not a general property.

(as demonstrated for panels)

Ladislav - did not read all your posts here, but as you are here, 
and for me to proceed - how do I "easily" create panel, if I have 
layout stored in a block? Carl's demo uses:

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-panel 'group pick test-blocks index [columns: 1]
		poke test-panels index pan
	]
	switch-panel main-pan pan 'fly-right
]

his

 make-panel used three values. OK, options block is not needed, nor 
 supported right now. Function attributes are now reversed (dunno 
 why, the argument order is not compatible with make-face for e.g.). 
 That is still easily fixable. But now "rma's" make-panel accepts 
 face, not dialect block. I tried to use make-face on a dialect block, 
 but no luck ....

I simply need to fix this line: "pan: make-panel 'group pick test-blocks 
index [columns: 1]", if possible. Henrik suggested that the aproach 
is different, and that I should use 'content functions, which I know 
nothing about yet.

Maybe such a style could be added by default, but not sure others 
would find it usefull, nor do I know what name to use ...

 - yes, that is possible. The difference between original, Carl's 
 implementation, and the new one is, that you have all the box model 
 attributes accessible, so you can do it easily now on your own.

re min/max-size, here's my take. I don't mind having both, not a 
big deal for me. But - when I tried Carl's examples back then,I tried 
on my nice Samsung FullHD TV. I maximised the screen, and wondered, 
why the heck fields don't resize properly. 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. So - as I know myself, my intention for max-size for the 
years to come will always be to cover FullHD displays. But as you 
can see, then it is artificial - I will simply use values, just to 
avoid effect I had with Carl's example.


As for min-size - I was negatively surprised by its removal, because 
I wanted panel of certain min-size to be displayed. But - I found 
there is new item, called initial-size, which fixed the situation 
for me ...

btw - can someone confirm the rendering "bug" with simple example? 
I can see the black box next to "test" text, which is transparent, 
and I can see underlying window content.Resizing causes redraw, and 
corrects it. It still should not happen imo though ...

view [hpanel [text "test"]]

And he told me, that fields should not be long, or it does not look 
nice anyway.

 The problem is that you can't solve the maximum size restriction 
 issue of a nice-looking interface, by using a MAX-SIZE at the style 
 level. Such a problem would be at a higher layout level and much 
 easier for the UI designer to solve at the layout level. There is 
 simply no reason to have it.

yes, and R2 does the same btw... strange

(that was a reply to pekr)

Regarding the

	unless pan [
		pan: make-panel 'group pick test-blocks index [columns: 1]
		poke test-panels index pan
	]

code, you should be good with:

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

sorry, forgot the paren:

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

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 ....