World: r3wp

Henrik - you see? I just wanted to have a "button" inside of view, 
and by change of stylize parameter, to change some aspect of the 
button. But I might be mixing few things together. In your above 
example, my-button is a class. So your saying that in R3 GUI, classess 
are not usefull, is an incorrect statement, as we already do have 
classes? Or what you would call your 'my-button then?

ad 1. I have a feeling, that we incorrectly mixed two things. TAGs, 
in my vocabulary or understanding, are "categorisation" elements. 
As for "state", there should be FLAGs, no? :-)

The feature list is not complete, we miss - 5a. ordering of faces 
for tabbing purpose

There is a slight discrepancy in the syntax of stylize and view. 
Not saying, that they should be identical, just a food for thought:

stylize [my-button: button [facets: [text: "Pekr!"]]]

view [
   b1: my-button
   b2: button options [text: "Henrik!"]
]


1) 'Stylize could theoretically use the same syntax as 'view? So 
the code above could just be:

stylize [my-button: button options [text: "Pekr!"]


That would make it more (almost) compatible with the layout definition


2) Currently set-word inside the stylize defines a new style (class), 
whereas a set-word inside of 'view, defines a face name = ID. There 
is no simple way, of how to resolve that, maybe something like:

stylize [
   my-button: button options [text: "Pekr!"]

   button options [text: "Henrik!" name: b1] ; no set-word, so probably 
   a problem syntaxwise. We simply can't style particular named face?
]


view [ my-button b1: button] ; b1 kind of simulates ID, inherits 
from stylize definition


Of course, it all depends how far do we want to go. We can introduce 
completly different semantics to the stylize function, even a complete 
selector behaviour from CSS, if there is a need ....

So your saying that in R3 GUI, classess are not usefull, is an incorrect 
statement, as we already do have classes? Or what you would call 
your 'my-button then?

 - A style is not a class in the HTML sense, where you can apply a 
 particular class to any tag.

I just wanted to have a 

button" inside of view, and by change of stylize parameter, to change 
some aspect of the button." - the method I posted is exactly what 
you need to do in order to allow such a change.

There is a slight discrepancy in the syntax of stylize and view.
 - there should be, since they are not the same at all:

stylize: func [
	"Create one or more styles (with simple style dialect)."
	list [block!] "Format: name: [def], name: parent [def]"
...

http://design.canonical.com/2011/03/introducing-overlay-scrollbars-in-unity/

the method I posted is exactly what you need to do in order to allow 
such a change

. Not sure - my idea was to use only "Button" name in the layout, 
not my-button, and diversify upon e.g. where the button is placed 
... but otoh even  in CSS/html, in most cases, you have to specify 
class or id, and hence my-button is kind of equivalent - you have 
to declare the special case. But - not sure all aspects of CSS are 
usefull to us.

I will be glad, if we have system, where I can easily style elements, 
and configure their parameters. I'll wait how you resolve the FRAME 
style or simply borderless PANEL, GROUP, etc.

stylize - thanks for explaining to me, that the function is different, 
because it is different :-)

the function is different, because it is different

 - it's different, because when you stylize, you make style objects. 
 when creating layouts, you are creating faces. faces and styles are 
 not the same kind of object.

what is the difference to state fields, in comparison to holding 
a value in the facet field? Are state fields meant to hold interim/computed 
values? Is there any usage rule?

guie/face: object [
	; Faces hold the state and options of instances of a style.
	style:   ; WORD!   - name of the style for this face
	facets:  ; OBJECT! - properties unique to this face
	state:   ; OBJECT! - state variables (not properties)
	gob:     ; GOB!    - graphical object(s) for this face
	options: ; OBJECT! - optional facet changes as specified
	tags:    ; MAP!    - tags for this face

	; NOTE: optionally extended in face creation with:
	;name    ; WORD!   - reference name
	;reactors; BLOCK!  - block of user actions

	; PANEL faces also add:

 ;trigger-faces; BLOCK!  - faces which reacts on triggers in panels
]

Cyphre - what will layout be good in next version? To preconstruct 
GUI, not displaying it?

yes, mostlt...but you should be able to pass LAYOUT result  to VEW 
function as well without any problem

=mostly

so we are going back to view layout [], or not necessarily, and layout 
is just a helper to prebuild a gui?

it doesn't matter what way you use...even if you use view [...] the 
equivalent of 'layout function must be called internally

so to clarify: you will be able to  write  view layout [...] OR view 
[...] , depends on you.

Hi, here is an R3-GUI poll once again:


For the resizing purposes, all elements have MIN-SIZE and MAX-SIZE 
specifying the limits of resizing. It is easy to see, that, unless 
MIN-SIZE <= MAX-SIZE in both coordinates, the requirements are contradictory. 
(For example, if we set MIN-SIZE: 100x100 and MAX-SIZE: 50x50 for 
the same object.) Currently, the code does not trigger an error in 
such case (not having a built-in test for it), giving the priority 
to the MIN-SIZE.

The poll question:


What do you prefer to happen in case object MIN-SIZE and MAX-SIZE 
dimensions are contradictory? Do you think the current behaviour 
is acceptable, or do you want the code to always trigger an error, 
if conflicting requirements are given?

the max of any x y should be used as max-size

I prefer that max-size have some meaning. So if the size is set outside 
of max-size, the size should be constrained to max-size. That is 
the whole point of having a max-size setting in the first place. 
If a style has a max-size setting below max-int/max-int it should 
be there for a reason, and max-size can be overriden explicitly in 
the layout so it doesn't constrain unnecessarily.

As for whether min-size should trump max-size or vice-versa, I prefer 
min-size to trump max-size, or maybe even push up max-size. The min-size 
setting is usually more important for styles, since it often has 
to do with making the face larger than the smallest size of its contents.

Screen size probably should trump min-size though.

it shoudn't be an error.  popping errors in gui code is generally 
pretty evil if it can be prevented...  its better for the gui to 
look weird than the interpreter to jam for an unknown reason.   the 
possible layout screw-up will be incentive enough for the bug to 
be fixed.


a logging system could help us identify where the engine "thinks" 
there might be problems...

a debug switch which compiles warnings like this would be nice.

So, currently it seems to me, that Graham's idea to set the MIN-SIZE 
to be the minimum of MIN-SIZE and MAX-SIZE and vice versa, to set 
the MAX-SIZE to be the maximum of the MIN-SIZE and MAX-SIZE is supported 
by BrianH as well, and, possibly, Max would support such a method 
too, based on the fact, that it does not "jam" the application. Count 
my vote too.

As long as they are actually set that way, sure. If they are left 
as they are and then just interpreted that way at runtime, that can 
get confusing.

And the actual size should be constrained by min-size and max-size; 
setting the size outside that range should not push the limits outwards.

Yes, I indeed meant "actually set that way", but, probably, will 
use the method just for panel/group columns/rows. Whether I should 
cater for the dimensions of all objects as well is not decided yet, 
since the problem actually occurred for column width in a panel.

(where the user may not give some numbers, but rely on some algorithm 
to calculate the widths, having currently a choice of five methods)

And the actual size should be constrained by min-size and max-size

 - the actual size is a result of the resizing algorithm, and it indeed 
 is clipped to the MIN-to-MAX range.

Yup. And it should continue to be clipped in that way :)

Using the true min and max value, regardless of which property they 
are in, may keep things from going disastrously wrong in some cases. 
If it were just the app programmer in charge of things, I would vote 
for raising an error. Resizing systems are another story, and I agree 
with the new plan in that context, though it would be nice if there 
is a way to trace the bad cases when they occur.

The problem with raising an error is that these values can change 
at runtime, but runtime error reporting about this kind of thing 
is poor ar best. As Maxim said, we need infrastructure for logging 
errors, particularly ones that are really more warnings.

Are these size constraints set through accessor functions, or otherwise 
processed by standard code before they are applied? That would allow 
the min-size and max-size to be repaired before they are used, so 
the min constraints can be ensured to be <= the max constraints.

Are these size constraints set through accessor functions, or otherwise 
processed by standard code before they are applied? That would allow 
the min-size and max-size to be repaired before they are used
 - yes

in glayout I had a lot of these issues to manage, and generally, 
I always had some part of the setup func which would normalize all 
the values to layout function expected behaviour.


this allowed voluntary programmatic side-effects, but not thru the 
layout dialect.


for example, all sizing values where clipped to be at least as large 
as min-size as the first step.

I hate gui errors .. I'd rather have a screwed up display

I don't think anyone is arguing that Graham, but I would rather see 
an error myself than to have my users see a screwed up display.

Maybe there should be an option to log errors somewhere?

I'm trying to change the font color and size in a button, and in 
a field ... need some help !

Something like this?


view layout [button "Help" with [font: [size: 16 colors/1: 255.0.0]]]

yes, but not working with r3

Doh! I should pay attention to the group name. :-\ Must be time to 
sleep.

Never mind, from my side, I'm just getting up !

you need to make new styles to do this.

A small note:

I have ran the latest RE-GUI and the examples. I have see that when 
the CHECK is off the "v" is still visible but greyed.

In GUI language I have seen the GREYED "v" means BOTH "true" and 
"false".

Example: you want to filter in a database which customers are active, 
you set it to true,  which are inactive, you set it to false (nothing 
visible). You want both true and false the you have a third state: 
the grayed V.

Yes, that's possible to implement, there probably was no need for 
yet.

I have problem accepting result of examples:

15, 23, 24, 25, 26, and I stop here, probably many others ...


The problem I see is,that I don''t want elements to jump during resizing 
the way it does. Please try form example 15. IMO if we don't support 
scaling, the text and its spacing should not change at all. I would 
expect panel being enlarged, but all it does is the panel moves down, 
and GUI creates space between the header text and the consecutive 
text.


Also - look at example 26 - why the last line of boxes is shifted 
down the window from all the rest of the boxes?