r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3 GUI]

Maxim
9-Mar-2011
[6735]
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.
Ladislav
9-Mar-2011
[6736]
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.
BrianH
9-Mar-2011
[6737x2]
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.
Ladislav
9-Mar-2011
[6739x3]
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.
BrianH
9-Mar-2011
[6742]
Yup. And it should continue to be clipped in that way :)
Gregg
9-Mar-2011
[6743]
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.
BrianH
9-Mar-2011
[6744x2]
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.
Ladislav
9-Mar-2011
[6746]
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
Maxim
9-Mar-2011
[6747]
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.
GrahamC
9-Mar-2011
[6748]
I hate gui errors .. I'd rather have a screwed up display
Gregg
10-Mar-2011
[6749]
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.
GrahamC
10-Mar-2011
[6750]
Maybe there should be an option to log errors somewhere?
jocko
10-Mar-2011
[6751]
I'm trying to change the font color and size in a button, and in 
a field ... need some help !
Gregg
10-Mar-2011
[6752]
Something like this?


view layout [button "Help" with [font: [size: 16 colors/1: 255.0.0]]]
jocko
10-Mar-2011
[6753]
yes, but not working with r3
Gregg
10-Mar-2011
[6754]
Doh! I should pay attention to the group name. :-\ Must be time to 
sleep.
jocko
10-Mar-2011
[6755]
Never mind, from my side, I'm just getting up !
Henrik
10-Mar-2011
[6756]
you need to make new styles to do this.
GiuseppeC
11-Mar-2011
[6757]
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.
Rebolek
11-Mar-2011
[6758]
Yes, that's possible to implement, there probably was no need for 
yet.
Pekr
11-Mar-2011
[6759x7]
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?
And you thought, I might like following coder, right? :-)

 view [hpanel [button button button] options [box-model: 'frame]]
If we can't come up with something better (which is beyond my imagination 
and the "proper" way would require to come up with xy alternate names 
for all panel/group combinations), I am definitely at least not sure 
about the facet (property) name. Does drawing the surounding frame 
(or simply parametrisation of one of style visual) has anything to 
do with the term "box model"?


I would probably use draw-mode name, but not sure it would not be 
confused with draw frames then? What do you think? Forget the syntax, 
we can't do any better here imo, but what about the name?
Align examples - I don't understand the align+halign at all. Why 
the vertical coordinates of red and blue boxes are reversed?
Also - please use halign instead of allignt, to be consistent with 
hpanel, vpanel, etc. It has imo no sense to name one property valign, 
and the other one align.
as some things might get lost in the discussion, I am really thinking 
about putting some of above stuff into CC. Please add Rebolek the 
right to edit tickets status.
Panel example #35 - I just wonder, how many ppl will feel lost the 
same way as I feel. The naming terms in regards to results are difficult 
for me to resolve. As for alignment, there is several way of how 
to name things:

halign, valing


left , right, center (vleft, vright, vcenter, hleft, hright, hcenter)


left, right, center, top, middle, bottom (or the corner alignment 
-  top-left, top-right, buttom-left, bottom-right - if those would 
be used, I would immediatelly understand it)


But - let's try to think about it a bit - we have some alignements 
in various GUI levels. If possible, let's stay consistent (e.g. it 
is enough that low-level text handling uses MS Word like terms, which 
don't relate to the rest of the gui)
Rebolek
12-Mar-2011
[6766x3]
re 15) text-resizing was enabled, so DOC-browser can render documents 
properly, but it seems that it doesn't sem max-size properly. I will 
check it.
ALIGN, VALIGN - this is same naming as in HTML, so you can expect 
most people be familiar with it.
box-model facet name - what about FRAME? name: none, frame: 'simple, 
frame: 'fillet etc
Pekr
12-Mar-2011
[6769x2]
frame name works better for me than box-model, although it suggests 
a bit - frame - yes or no? frame-type would be more descriptive, 
but longer. I would be ok with frame, frame-type (mode), draw-mode 
- all better than box-mode imo ....
as for alignment - from html I do remember align="left | right | 
center" .....
Henrik
12-Mar-2011
[6771]
I would go for EDGE, like VID, if you are to implement such a feature.
Pekr
12-Mar-2011
[6772x2]
alignemnt - really - go to example #35, write down all variants on 
paper, forget the visual representation you are provided with, and 
just draw it on the paper out from your head. I bet you will make 
a mistake. And align + valign is not understandable for me at all 
....
Henrik - whatever name might work. As for EDGE - this is yet another 
term though. EDGE was regular facet in VID though, and in R3 it is 
replaced by BORDER, no?
Henrik
12-Mar-2011
[6774]
I think the edge/frame/border usage is a little confusing. EDGE was 
a standard feature for every face in VID and it was fixed how it 
worked. In R3, an edge would be implemented on the DRAW level and 
could basically mean anything, including what it means in relation 
to the box model. This is why I'm still advocating a special FRAME 
style, which in *one* place, settles the meaning and the appearance.


Furthermore, a FRAME could be required for any type of face, be it 
a form with many fields, a compound of faces or groups of compounds 
of faces, which need to be surrounded by a pixel accurate frame, 
like in the example below, which I had trouble defining properly, 
when I experimented with skinning:

http://94.145.78.91/files/r3/gui/162.png


I had problems with it, because it had to be part of COMPOUND, and 
yet, certain COMPOUNDs would not have a frame and certain other panel 
types would also require the frame, but not be a compound. It is 
just much simpler to have it in a separate style.
Pekr
12-Mar-2011
[6775x2]
but how would you define, what layout engine should be used? We have 
two, no? panel, and group ... and their respective vertical vs horizontal 
variants ...
The question is, if we can please all users. Some will like borderless, 
backgroundless clean style. Some might want frame around the panel, 
and I can imagine users wanting just a bit different color or gradient 
to distinguish the panel from the surrounding.
Ladislav
12-Mar-2011
[6777x2]
#[[Pekr

Does drawing the surounding frame (or simply parametrisation of one 
of style visual) has anything to do with the term "box model"?

Pekr]] - surely it does, the box model specifies that, and other 
properties
#[[Pekr
frame name works better for me than box-model

Pekr]] - it does not for us, since that way, you would be limited 
only to one of the box-model aspects
Pekr
12-Mar-2011
[6779]
Ladislav - I know, but imagine user will just want above mentioned 
variant - panel, which will be distinguished by a bit brighter bg 
color, not a drawn frame.
Henrik
12-Mar-2011
[6780]
Pekr, by only allowing a single face (with any number of subfaces) 
inside such a frame style, layout would not be an issue.
Pekr
12-Mar-2011
[6781x3]
What do you mean by box model aspects? margin, border, padding, content?
Henrik - aha, so you mean that FRAME would be special face type allowing 
to create various surroudings upone certain face? So that it would 
containt panel, or group? That might work ...
But of course then - we have altready those facilities for all faces 
- a box model, where's the space to draw any borders,etc. Well, we 
could say then, that FRAME is special decorative kind of style. The 
question is, if it would not be overused by uesrs, putting even buttons 
inside of FRAME, to have a decoration? :-)
Henrik
12-Mar-2011
[6784]
Pekr, "That might work" - precisely. :-)