World: r3wp

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.

(you won't get me to agree after 4 years of working with both methods, 
sorry)

well, we agree to disagree  :-D

Henrik - don't even try the old crap on me again :-( The reason why 
Carl started new GUI was because of Gab's GUI was not all that easy. 
If I want 50x50 button, don't even dare to dictate me, that I can't 
easily have it. If I can't, I almost refuse to use such a system 
period.

I refuse to build new button style, just to have it like I want it.

This is rudiculous - so you have init-size as an option, yet it is 
ignored,or totally twisted, in that regard, that only X axis gets 
adjusted. That simply does NOT work as expected, and if you guys 
refuse to understand, that the freedom of expression is what ppl 
are interested in, then you are building completly different GUI. 
It is supposed to be easily used.

So far - RMA - public | 0 : 3

sorry 1 : 3

Henrik - I believe you will fail explain technical reason, why it 
prevents proper skinning. Carl's GUI used skinning, and was able 
to provide such buttons. That is just stupid limitation imo, and 
should be removed ....

This is not even funny. I know your long time opinion, and I think 
that you pushed in into the design. I believe you have some reason 
based upon your experience, but I am really not surey, it is necessary 
limitation.

You have min-size and max-size still, right? To support resizing, 
you need to support sizing. But that doesn't mean the syntax is the 
same as in R2's VID or Carl's GUI.

Specifying color is a different matter though. You need abstract 
functional colors at most in styles and layouts to support skinning, 
not real colors.