AltME groups: search

i try to put a table in a tab

tab-box [
			"tab" [
				title "tab 1"
						text-table ["1" "2" "3"][
			["text table" "a" "10"]
			["line 2" "b" "9"]
			["line 3" "c" "8"]
			["line 4" "d" "7"]
			["line 5" "e" "6"]
			["line 6" "f" "5"]
			["line 7" "g" "4"]
			["line 8" "h" "3"]
			["line 9" "i" "2"]
			["last line" "j" "1"]
		]

Sorry, Claude. I have trouple reading names of that color on a white 
background :(

Following few things:


- why is "custom" include needed? We should either user R3 native 
facilities, or include an include as a standard into R3 :-) (this 
is no real question, just a remark that if we find it usefull, then 
why notto make it part of R3?)

- RMA does not work with CureCode tickets. It would be good to either 
dismiss/close or resolve them? E.g. I find renaming of do-style and 
do-face to do-action, do-reaction a good tip to implement


- we should resolve the size of buttons vs scroller vs tabs. In Carl's 
GUI, button is 28 pixels tall, and it feels OK. Our's here is 22, 
I have no preference here, but could be those 28 pixels. Scroller 
is only 16pix - not acceptable imo. It should be of the size of the 
progress. Tabs are proportionally too tall.

- tabs should have line removed for actual tab. I suspect it might 
be more difficult to draw the container then.

- there seems to be someone at RMA liking Old aqua interface of MacOS. 
Tabs, buttons and scrollers are a good example ... of how to not 
do visuals anymore :-)

- area - enter few lines, go to bottom, and try to hilite the text 
by keyboard (shift plus arrow-up). It always hilites only actual 
line

- info areas, labes, etc., should prohibit display of caret, maybe 
allow hilighting, but allowing to have caret in "disabled" area is 
not looking nice

- text-table buttons are Excel filter inspired, but looking strange 
- some more thoughts needed
- select-an-option does not allow keyboard navigation

- text-list does not scroll, when navigated by keyboard, ditto text-table

- tabbing feels strange for text table. I alway said, that we need 
nested tabbing. I can imagine tab stopping on table, but next tab 
moving away, not actually going into tabbing in terms of the hilited 
widget. Enter should enter the more complex style, escape move away. 
That is not typical also at OS level, but then - everybody has it 
wrong :-)

- between the text-list and text-table, I have to press tab three 
times -visually I am not sure, "where" hilite disappears

- is text-table a compound style? What sense does it have to have 
buttons hilighted, not being able to enter the action? Why are not 
arrows tabbable? Table headers cells should be one style, not two.

- text-table is the weakest "grid" we ever had. Comparing to Cyphre's 
style pack, and rebgui grid. This is like 5% of functionality, not 
thought out style, useless for any serious data. I want to see the 
display of infiinte amount of data, proper caching.

- tab should be tabbable, ctrl-tab allowed to switch between the 
tabs  


I find the styles/gui inconsistent. There should be someone defining 
the styles, their behaviour to keyboard navigation, tabbing, etc. 
So far it seems like style being put together with no deeper thought 
about the end result of the whole GUI.

Someone might have a feeling, that I sound negative. I don't :-) 
The achievement is concrete, material, good. But to have consistent 
and well behaved GUI, business grade, we need to introduce anyther 
layer - consistency:


- tabbing and visual representation of in-focuse styles - currently 
very inconsistent. Maybe not just implemented for all styles

- keyboard navigation is a must. We have to be able to navigate by 
keyboard thru allowed guielements, consistently
- keyboard acceleration keys are completly missing so far
- style metrics
- final design/skin as a last one

Thanks for reply, Pekr.

- curecode - I'm not sure about others but I don't have enough rights 
on curecode to change state of tickets.

- visuals - 1) as has been said many times, not a priority right 
now and also 2) highly subjective

- tabs should have line removed - see above reply to Graham, why 
it's problematic

- keyboard navigation is broken in this release, subject for next 
release

- text-table is useless - I really like these statements of yours 
without any serious backing. "I want to see the display of infiinte 
amount of data, proper caching." - please, elaborate of what's not 
possible here.

Rebolek - easy to describe. Cyphre is the guru of grids. I remember 
his Cyphre styles grid, and I also do remember grid my company paid 
for, for RebGUI. And I really don't understand, why witch each new 
GUI, we have to start from scratch, and introduce something which 
is clear departure from what was achieved before? Here's few features, 
which were supported:

- cell can be ANY style (VID dialect)

- virtual columns/rows. Simply put - no need to reformat data obtained 
from some data source. Easy to switch/hide columns/row. Only pointers 
to data moved, no need to reformat data, easy to submit back to db 
backends, without the need to reformat the data again

- hilighting - row or cell or cell + row, full keyboard navigation
- horizontal scrolling
- ultra fast, unlimited amount of records


In the past (1998) we bought a product called GridPlus for our CA 
Visual objects. It was few thousands of lines of code, but it just 
smashed any other grids from Delphi, etc. Ditto for DOS era - EzBrowse 
- it even allowed to freeze columns, save set-up of grid plus filters 
for particular windows etc. I have very good idea what kind of functionality 
should grid allow.

Pekr, it might actually be that it's not a good idea to use the same 
arrow for things that are quite different, for skinning reasons. 
But I also suspect, you wouldn't complain, if the arrows were skinned 
identically.

Rebolek - I am suggesting that anyone doing a serious GUI work should 
do some mock-ups, and build a spec table. rows= style name, columns= 
tabblable? | accelerator key |  shared visuals. It is not about the 
look, but it is about the behaviour imo. Just look at the text-table 
arrow - it is a separate button. It will have influence to tabbing 
for e.g.?

text-table: This is a very good and powerful style already. It solves 
80% of all use-cases in commercial apps. It's lean, fast and supports 
some advanced features out of the box. Speed of implementaiton is 
focus here, not configurability. The auto-filters are XLS inspired 
but the semantics are extended. You see all available values divided 
into from current shown list (above divider) and from all data (below 
the divider).

Will there be any interim release of already known bugs, or will 
it be typical "friday" release in a week or two?

I'm not sure if the direction is possible other than by simply doing 
it with layout, where you can flow faces in a particular direction, 
but ordering by specifying a number should be possible.

I think it would be fairly easy to do a straight mirror of the GUI 
and just flow text in the opposite direction.

I remember style of such a name from some prior gui attempts, and 
it used tight spacing between the elements. What I am looking after 
is precise copy of vpanel, hpanel, with just zero graphics, or at 
least different border

I can see there is a backdrop style, but dunno what kind of functionality 
it uses ....

hmm, there seems to be so much of colors, etc. I sometimes almost 
feel, that we overload GUI once again. In R2, there was a face. We 
introduced gob, as a means of having smaller object in memory. In 
fact, there is a face linked to each gob, no? And just print recent 
styles structure - it is now bigger than R2's face. And you also 
don't use 'intern for things which could be shared between the instances 
= wasting memory again?

Also, the size of the face structure is not at question. It hardly 
eats any memory, a few bytes at worst.

I am not sure, just brainstorming loudly. I can as well push my brain 
to accept the fact, that face/facets is a junk block, containing 
whatever you want ....

btw - I am not sure "hint" is a good name? I know term hinting, being 
related to fonts. But - above is the way - group values together, 
add comment, use empty line as a separator from other group of settings 
...

By creating new contexts, we would have to have an advantage to using 
them. In a way, I don't mind it, as it could be used to apply particular 
groups of facets, in a standardized way, so you know that a particular 
context will have these items. But FACETS does technically not prevent 
this. From a technical perspective, I'm not sure I can find an advantage, 
since there is no difference from R3's perspective on speed or efficiency 
in accessing size, color or hinting information.

However, I can see the following groupings or contexts:

- color
- hint
- size

btw - when I met Ladislav, I asked him, why there is a face/gob, 
and face/facets/gob, and he was not sure it is like that IIRC. Later 
on I checked it, and it is really like that. But I don't remember, 
if he gave me an answer - are those identical gobs? Why I am seeing 
them in two places, when I mold the face?

Yes, they are two identical gobs a the reason why it's also in facets 
is binding for draw block.

a=and

Pekr: 'btw - I am not sure "hint" is a good name?' - actually, yes, 
since the INIT-HINT is a hint (look up the word in the dictionary), 
how the algorithm should determine the INIT-SIZE value

(for a panel)

The 'AUTO hint just tells the algorithm to calculate the panel INIT-SIZE 
"automatically" (= using an algorithm) taking into account the panel 
contents. This means, that you, as a user, do not have to specify 
the panel INIT-SIZE, which might seem less comfortable to you.

Of course, if you know, what is the INIT-SIZE you want to have, you 
can specify it as well using a different hint.

'Yes, they are two identical gobs' - funny, that is a nice contradiction

I have a question towards the aproach to design a form. Following 
code does not work for me (result-wise):

view [hpanel 2 [label "Name:" field button "ok"]]


Simply put - button is on a new row, but it probably causes field 
to align to the right? Or more precisely - button extends the column 
cell, and so the field is pushed to the right in an undesirable (albeit 
expected) manner. Should I put buttons supporing the form out from 
the panel containing fields?

yes, buttons should be in a subpanel

GROUP and PANEL would by default not create a frame. Derivative FRAME 
styles would create a frame.

or will there be a different solution of inheriting cell-sizes across 
multiple panels? this is for forms where label width is necessary 
to be identical for multiple form parts, such as 4 column forms or 
forms separated vertically by full-width spanning parts.

I don't know how difficult it is to do, but it seems like a necessity 
to me in such cases.

But generally yes, for forms, I expect easily setting up pairs of 
right alighned labels, and fields. That has to be ultra easy, along 
with the ability to set some margin, but that should be workable 
via the stylize.


Henrik - I think that if you add frameless alternatives, then it 
is not a big deal ... I just have problem with current aproach, where 
subpanels create too many lines in the GUI :-)

#[[Pekr:

Does not work for me:


 view [hpanel 2 [label "name: " field hpanel 3 [button button button]]]


The nice thing is, that I do know, what it does not work, and I do 
know that the behaviour is correct, it is just - undesirable ... 
:-)

Pekr:]]


Could you please write it down in a form understandable to mere humans?

Something like "does not work for me" may be understandable to some 
supernatural beings with mind-reading capabilities, but, being a 
mere human, I am lost.

How about this, would you prefer such a result?

view [hgroup [label "name: " field return button button button]]

BTW, you can make a similar layout using hpanel as well. Are you 
able to do it, Pekr?

a similar layout
 = "a layout similar to the one I described above using HGROUP"

Ladislav - I will have to think about the challenge for a while, 
let me think :-)

is it a good idea to use issue! ? it will collide with build scripts.

hmm, I still have to think about all the skinning/material system. 
Just brainstorming, not able to foresee the consequences. So we have 
all those colors, draw blocks (multiple), gradients as a materials. 
I wonder - could we thought about the way style is being drawn in 
terms of a state/material?

I mean - what we are after is having tight, panel, and group being 
just displayed in a different way, no other change of functionality, 
no?

In the case of 

hpanel [] options [framed?: no]

I think that someone might want to create a shortcut:

stylize [hpanel-frame: hpanel [] options [framed?: no]


... so in the end ppl would try to come up with new name anyway? 
Just thinking lound, not having particular preferences here, but 
still not sure about #FRAME, as it introduces new way of how to parametrise 
the style?

I would rather have a specific HFRAME, a style that explicitly is 
created for visibly framing elements. This means you can tag it separately 
and it's easier to skin, because you don't have to create multiple 
draw blocks for a single style that is meant to do one thing. The 
end result is less complex.

Henrik - HFRAME, ok - but does it behave like a panel, or like a 
group? And how do you name it, if you want to support all variants? 
hpanel, hgroup, tight?

Alternatively, we have a FRAME style where you put GROUPS and PANELS 
inside.

I don't know if it is a bad idea, because the combinations would 
be fewer for what kinds of frames you want and you avoid cluttering 
GROUP and PANEL styles. You could say that FRAME supports only one 
face inside it to avoid deciding on flow.

I don't see a single reason why frame should be separate style when 
the border can be drawn very easily inside each style.

And, what about tagging? How do you discern a visible frame from 
an invisible one, in case we decide that skins should rely on tags?

To Pekr - here is a layout you might not know how to lay out:

stylize [lab: label [align: 'right]]

view/options [
	hpanel 2 [
		lab "name: " field
		lab "last name: " field
	]
	hpanel [button button button]
][break-after: 1]

as for your examples - this is method I used before. I thought that 
you might find a way of how to do it in terms of just one panel, 
which is not imo possible?

Guys - to make it obvious - I can find out the way of how to make 
things work. I was just curious, if mine example could be done in 
some easy way. I hope you don't take it as a complaint.

Cyphre - your method is OK with me, with just a small note, that 
I would welcome the option to have borderless panel in the case of 
buttons in your above example ....

hmm, interesting :-) I am curious what others think. It kind of adds 
another level of possibilites into the system, but maybe it makes 
it a bit more complicated too? :-)

borderless panel: we are working on a feature that makes the box 
model configurations easier to use

Hmm, I can't imagine, how should it work? Because on the low level, 
there is just a face, and a gob. So how do you internally distinguish, 
if the panel is separate, or nested in my-panel, and hence needs 
to use different styling?

re "I thought that you might find a way of how to do it in terms 
of just one panel" - it is possible to do it in "just one group". 
Do not forget, that R3-GUI H/Vgroups are more similar to R2 layouts 
than R3-GUI (H/V)panels.

By 'you are wrong' I meant your understanding whe 'cascading styles' 
really are is a bit blurry...if you check the 'selectors' section 
you'll see that this topic can be a bit more complex.

CSS is clearly much more flexible in setups. You use tree of definitions, 
which are then applied in particular cases in document hierarchy. 
 If I am not mistaken, right now we don't have no easy way, of how 
to make e.g. first button in a last row of the panel e.g. red, unless 
you first define red button, and use it in the source of the layout 
:-)

I've done a few quite complex CSS setups working with jquery, and 
at some point, CSS selectors become very brittle because the priority 
rules become a bit hard to properly prioritize.   


To reflect this, in some setups not all browsers actually match the 
same CSS selection rules.

In R3 GUI, style names themselves act as classes, where in HTML you 
have a fixed set of tags that need to have classes. IDs are set-word!s, 
so there is no need to add any superfluous layer to identify specific 
faces.

Henrik, not quite.


using CSS you effectively "tag" your gui and then you can apply effects 
to multiple types of things which match a tag or pattern.

a tag is a cross-cutting concept, not a family or class/type  like 
concept.

But - it might be a bit different anyway. If you make b1: button, 
it is a set-word, a name. And now how do you use stylize, to refer 
to such a name? Stylize creates new style name, e.g. b1, but that 
is direct name for the style itself

Pekr, you don't stylize a singel face. you stylize a style and then 
create an instance of that style as a face.

no henrik, its a completely different thing.  you can use a class 
name for completely different classes.


a button and an paragraph can share the same class name.   and you 
can then affect them both in the same way.

Henrik - ok, so to be clear - show me possible stylize definition 
of a button variant, and how you refer to it in the layout code?

I suggest that classes in the R3 GUI is not useful for the reason 
that it interferes with the "intelligence" layer, where we already 
have:


1. tags to identify state and capability of a face, such as finding 
the default button in the window or whether the button is disabled.
2. name to identify a specific face

3. style name to identify the style and to create a distinct appearance
4. the ability to group faces by panels

5. have information about the ordering of faces stored in the face 
tree

6. use specific policies on how to act on a particular face with 
particular tags

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? :-)

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

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.

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
]

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

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?

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.

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.

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.

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.

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.

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

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.

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)

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

I would go for EDGE, like VID, if you are to implement such a feature.

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

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.

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

Pekr, by only allowing a single face (with any number of subfaces) 
inside such a frame style, layout would not be an issue.