AltME groups: search

this is also just one approach, one strongly advocated for by Robert 
and if done right, it will be quite fast to work with

A basic example of how it looks right now:

f: view [
	form-panel: panel 2 [
		group 1 [
			title "Record fields"
			bar
			group 2 [
				label "Name"		name: field		; stored as name
				label "Address"	address: field	; stored as address
				label "Age"		age: field		; stored as age

    label "Skipped"	skip-field: field options [skip: true]	; not in the 
    list
				label "Ignored"	field			; not in the list
			]
		]
	] options [record: 'rec]
	group 6 [
		button "New" obtain 'form-panel add-record
		button "Save" emit 'form-panel update-record
		button "Delete" do [delete-record]
		pad
		button "<" obtain 'form-panel next-record
		button ">" obtain 'form-panel previous-record
	]
]


The 'rec is a record object, which is filled with data from the server, 
using the backend function, and when submitting, is used to gather 
data from the form and into the server.

then there are OBTAIN and EMIT reactors, which are siblings to the 
SUBMIT and ACQUIRE reactors.

The SKIP and RECORD options are scoping, so if you define a panel 
with SKIP, everything inside it is skipped on EMIT.

RIF is RIF, let's wait for RIF, and not use pseudo dbs! Apart form 
that, doesn't Robert have SQLite for R3?

why ignore what Pavel has done?  why shoudn't his research contend 
for being RIF if it actually tackles the issues and works?

The thing is, that for multimedia, kiosk, tablet, multitouch etc. 
UIs, all that stuff is useless, and that is my point all the time 
:-) Henrik - one question - aren't you afraid, that all the stuff 
you work on, might be dismissed by possible change in architecture, 
when some other subsystems are going to be added? And also - how 
all this stuff is going to be optional? Look - even low-level R3 
now has various boot options, so e.g. someone can write and replace 
even module system. Now how pluggable (functionality wise) is new 
GUI going to be?

What if I don't care for your validation, your DB reactors? What 
if I am used to work with form and db my own way? Will I get one 
bloated gui? Carl was very picky for each single function to add, 
and now we are adding whole layers upon the GUI, which is still far 
from being finished.

Pekr, db-reactors and validation are optional features. Reactors 
are made using the MAKE-FACE-ACTIONS function, which specifically 
is designed to add a new aspect to the GUI in a way that doesn't 
interfere with its original functionality. And while you don't care 
about it, we do, because we need specifically to builds apps that 
use them, and I've missed these things in VID since I first used 
it. There's also that little detail about shaving off months of development 
and testing of large apps. The "bloat" you talk about would be around 
5 kb of code for now.

That's not bloat of code, but bloat of functionality I tam talking 
about. My experience is as follows - sometimes I like to use frameworks, 
but I don't like using frameworks just for the sake of frameworks 
themselves. Young guys did new SW for our old kiosks we installed 
around, and it seems so complicated (all xamp, web, replicated mysql), 
that they had to call their guru to set-it up.

I just wanted to say, that sometimes it is easier to not use some 
framework, because 1) each framework can do only certain stuff 2) 
you have learn this stuff 3) more complicated things are difificult 
to do. Goog example is that overhyped DB for Rails, don't remember 
the name. In 5 minutes, I needed more complicated set-up, and the 
answer? Bad excuse about framework being good just for certain things 
... no, thank you ...

Bloat of functionality: That's not the point of these frameworks. 
The point is to make certain rudimentary things quick and easy to 
set up for anyone trying to write a GUI. I'm pretty sure that once 
you've fixed the 657283th bug in a javascript/HTML webform, you will 
really wish this was already worked out for you.


If the frameworks don't work out for you, then they are poorly written.

It is often about the clash of how we are used to think, and use 
some functionality, about our workflows. If everything is gluable, 
well then. I would not just like to see, that each style has tonnes 
of fields, to support upper layer frameworks. I hope you keep it 
streamlined to some flags, and custom data fields ...

You have some rules that you need to follow in any framework, otherwise 
they won't work for you. In the case for, for example db reactors, 
you need to know about the specific options, the rule that fields 
must be named for them to be used and how. But really, there are 
only few rules and once you've worked with attaching database records 
to a form, in a manual  way versus this way, you probably don't want 
to go back.


The other thing is an illusion of control with absolute flexibility 
without a framework. It simply lengthens development time and introduces 
bugs (something that we keep overlooking, eh?), and generally keeps 
the customer unhappy.

I worked with similar aproach in Clipper, and most of the time it 
was not flexible enough ...

And _data should be renamed into BAG, because this better describes 
what it is.

Got a pattern on the resize loop bug, but I guess it requires a very 
specific VM setup:

1. Start the R3 GUI and make a window. Maximize it.
2. Resize the VM desktop window

3. Hope that your resize action is slow enough to allow you to doubleclick 
the titlebar to de-maximize it.
4. Now it loops between maximized and normal size.

Perhaps there is some confusion about screen-face size changing.

re 'area style - trying auto-scrolling or scrolling in general:


1) still the same bad aproach as with R2 area - I don't care that 
it does not hilite right now, that can be added, but when dragging 
the mouse outside of the area, it stops scrolling, and that is wrong 
- it should scroll even if I move mouse out of the window, wherever 
around my 2 monitors ....


2) when I start dragging, the proportional size of scroller is lost, 
and it gets reset to its full-size dragger ....

I think, that system metrics are still under-developed. In fact, 
they were never correct in REBOL, and it is known fact, that R2 crashed 
when you changed resulution of window. I would like to see screen-face 
more developed - it should be a block, along with proper system metrics, 
number of monitors, their orientation, resolution, etc.

Uploaded panel scoping prototype:

http://94.145.78.91/files/r3/gui/panel-scoping.r3

Test support file:

http://94.145.78.91/files/r3/gui/file.txt


It's an earlier prototype that eventually became db-reactors, but 
it shows much more of the panel scoping features and uses EMIT, OBTAIN, 
ACQUIRE and SUBMIT.

Area style report:


1) hilite some few chars, then you click elsewhere in the text, or 
just move the caret using arrows - the text stays hilited, whereas 
default OS behaviour is, that the hilite is discarded. The question 
is, if we are targeting for REBOL specific behaviour, e.g. allowing 
to move caret, and have multi-hilte areas? I think not.


2) hilite autoscroll works chaotically. Sometimes it scrolls the 
area, sometime it does not. Dragging the mouse outside the window 
does not work at all.


3) scroll by mouse-wheel. When I reach the "bottom" of the area, 
I loose my focus, and scrolling back up does not work


4) moving up/down by arrow. It seems that in OS native widget (Notepad), 
the caret position is counted by the follow-the-leftmost-tex-length 
rule. So if I e.g. go via an empty line, caret should stay at the 
beginning of line for all other rows.

5) cut and paste into Notepad discards newlines


6) cut and paste from Notepad inserts text in hilited form - random 
behaviour here, ot it needs more observation ...


7) hilited text should be deleled by hitting delete, backspace, or 
by typing any character

8) when hiliting the text by mouse, scroller gets reset to 100%

Is that enough bug-reporting for the starter? :-)

Is there some easy way of of hot obtain list of available styles? 
Are styles somehow divided upon internal (thsoe are more of classes 
you use to construct other styles) and user useable styles?

btw - I really hate guie name. It reminds me of Internet Explorer 
and I can't decode its meaning at first sight ....

is there anything like 'flags item in new VID? I find tagging very 
usefull technique. That way you could simply add a tag, e.g. 'internal, 
and such style would not appear int he list of styles for something 
like get-styles function. Simply put - only styles/widgets which 
are able to function on their own, would be shown ...

there definitely have to be accessors like get-styles (get-style-list) 
or something like that. Playing in console and trying to display 
tabbox, container, errors out ...

Tags were implemented by me. They are used in validation and keyboard 
navigation for now.

tabbox, tab-box and container are tests of tab-box implementation 
and only tab-box (name) will stay. They actually shouldn't be in 
SVN, so ignore them for now, please.

They get into a "fight" and the field tabbing "wins".

OK, so there's recently no way of how to programatically cycle via 
available and displayable widgets, and put them on screen. Just remember 
my request for the tagging and obtaining the list of usefull styles/widgets 
:-)

scroller has been rewritten and is not fully axis-independent yet, 
so displaying stand-alone scroller is problematic right now.

Small bug -  view [bar box check radio arrow-button slider p: progress 
field] .... type something in the field - the text jumps up and down 
as you type ....

btw - why field style metrics are so wrong? Sometimes I can see proportionally 
too big fields - e.g. Facebook main page. And new R3 GUI uses too 
thin field. Look at old R3 View demo, section 'Form, how nice it 
looks :-) I just hope it is just question of some tweaking :-)

scroller: I'm not sure it makes sense to attach scroller to various 
styles inside the layout. You may not realize it, but that code is 
very complex to write and also difficult for the style writer to 
use. It's easier to write styles with scrollers attached in a fixed 
way and much easier to maintain.

Rebolek - those are details which could be corrected in 1 minute, 
and make the overall feel for the tester much better. The whole team 
is not even at the level of Carl's VID, not unless R3 GUI can do 
anything usefull. I don't care for look now, but correct system metrics, 
closer to typography rules, are always welcomed. The screen forms 
should look relaxed. E.g. I was lately suprised, that I tried some 
Air app, and it was unpleasant experience in that regard ...

Henrik - are you trying to suggest, that scroller will not exist 
as a stand-alone style, and that you will not be able to attach it 
to other style, like Carl's VID? While I really don't like it, if 
it is that way, I at least hope that the code is reused, and not 
hardwired for any widget, which needs scroller, once and once again 
...

Yes, and that is exactly the thing we are missing - the big picture. 
Noone said there's anything wrong with Rich Text, para handling, 
etc.

Pekr, as I see it, it's not necessary. If you want a specific style 
with and without a scroller, first write the style without the scrollers. 
Then write a new style with the scrollers and appropriate scroller 
code attached. Very easy to debug and maintain. I know the convenience 
of "oh, I'll just throw in a scroller right here", but the code behind 
that is a nightmare to maintain for different types of scrolling, 
because it has to go both ways and some styles have very particular 
ways of handling scroller behavior that is not easy to resolve with 
actors alone.


I assume Carl added this, because he didn't consider the implications 
of adding scrolling to other than a pixel based area.

The problem with original scroller is, that is was 'too smart', it 
was scrolling area it was attached too. That may seem like a good 
idea at first unless you don't need the scroller to do something 
different like instead of setting area's offset, you need to change 
e.g. text's scroll. So right now the scroller just returns value 
and the style needs to handle that value by itself.

I don't understand! Scroller can do only following work - move slider, 
set slider size, react upon mouse-over. That is all. And scroller 
will never do anything else. The rest is the work for corresponding 
style on-scroll handler, which can do whatever is needed for the 
style ...

I'm starting to think that this "release often" strategy is not a 
good idea at all and a waste of time.

Rebolek - I will be harsh, but others might feel, that what is waste 
of time is lack of communication and providing big picture. You accepted 
SCRUM methodology, but only for your team internal purposes. The 
rest of us knows nothing about what's happening at particular levels. 
If you stop informing ppl, then the only thing we would know about 
the GUI would be, that team of 4 ppl are working on it for 4-5 monts, 
with no visible result. Ppl are very eager to have GUI.

OK, I can test personally. In the past I worked privately for Romano, 
Cyphre. We can concentrate upon some more concrete stuff. You can 
say just few points, like - new area, please test. And I will do. 
Recently Henrik releases new version without telling what has changes, 
just 21KB was added :-) That is really difficult to estimate what 
changes should be tested :-)

And testers pull the source down.

They can diff the changes and not wonder what that 21kb was that 
was added.

public repository is not likely to happen, as RM Asset keeps private 
sources in the same repository as the R3 GUI to accommodate private 
projects and build system, but I will continue to release the r3-gui.r3 
file until a better arrangement is made.

We release often and I think we should continue to do it but it helps 
a lot if we just focus on the stuff that is there, and not the stuff 
that is not there.

Petr, a lot of your points are valid and have been discussed several 
times. Nevertheless, we need to do it all.

And, let's make a test:

How want to work with the RMA team on the R3-GUI? By work I mean, 
really getting something done. Writing code, styles etc. not discussing 
generic, high-level architecture stuff and future things to do.

And by work you mean paid?

Henrik -- FYI: Can you confirm an odd behavior for me?  Whenever 
I minimize a panel and reopen it, it works as expected.  When I resize 
the object to a bigger size, minimize it, then reopen it, I get a 
weird strobe effect of the two panels, one the original size and 
then the other at the bigger size.

Robert - I can't work with RMA team by writing code etc. My primary 
job makes me come home between 18:00 - 20:00, then I have another 
company where we run 700+ wifi users, some other projects. I am not 
complaining, I like it :-) It is just that a) little of free time 
remains b) you would not want my "code" to oficially accept :-)


But - I don't necessarily be the one, who just talks. Give me something 
specific to test. I think I now will find my way with Henrik/Rebolek 
on my own. It is just the current release format (flattened source) 
is a bit uncomfort to study code segmentation and separation, and 
- difficult to know what changed, if there's no changelog. (I know 
I could use diff on 256kb source, but ....)


So - I think I will let it as it is - it is enough if e.g. Rebolek 
says just few words for the release - e.g. - please test new tab 
... and I can look at it, and givi it a run ...

Ok, that's a good start and helps us.

I was thinking more about some mock-ups, rather than someone altering 
new styles to some new design. But as you said - it might be preliminary 
and there are more important things to solve first. If the  system 
is good, I bet there will be more stylesets/skins anyway. rebol.com 
needs some designer too :-)

Validation notes:


1. can't tab out of a field and unfocus does not activate the reactor

2. numeric fields will respond to an empty field or a number. they 
are string fields for now.

And it won't lock you in the field, it just indicates it's not valid. 
So you can tab around like mad but the save button might not be enabled.

BTW, it's subtle, but if you make mistakes and validate, the validation 
will automatically focus the first field with an error in it.

So, it will both support Robert's method of a disabled save button 
and one that only validates at the end.

What I hate most about validations, is sometimes their strictness. 
I would break anyone's hands, who pushes me to write a phone number 
to some "standard". The phone number is used by humans anyway, and 
even then, it can be still parsed even by automat. My number is +420-777-172 
171 .... I choose my own format for the readability purposes, and 
I hate, when the form blocks me :-)

Must have selected value

 in item list 1, but doesn't mark a non-selection as invalid after 
 marking a selected item as valid and deselecting it by clicking in 
 the list-view somewhere below item "3".

hrm... I responded and it showed up on the list, saying that my mail 
address is blocked due to spam. Did it show up?

I'm thinking there is a design issue with validation, particularly 
the initial state:


The latest version will show that the "Only Chars" field validates 
as OK, which is technically correct, but confusing, as absolutely 
nothing has been entered in the field.


The issue is that the VALIDATE-PANEL/INIT function will see the field 
prefilled with an empty value and this passes validation. All fields 
that show a black dot, actually fail validation and a black dot is 
shown as the initial state.


I understand what this means, but it may be confusing for someone 
who is using the validation system for the first time. The fix is 
simply to add the NOT-EMPTY validator to the field, for the field 
to fail validation initially.

Is this easy to understand?


I've studied the issue with setting an initial state for each field, 
but then there would be a problem with the validation system understanding 
prefilled values, and I would have to add functions to the validation 
system to mimick SET-PANEL that setup fields in a special way. I 
don't want to bloat the GUI like that. This method works fine, as 
long as you know what's going on.

I just don't understand, why is that being a design issue? Any design, 
which pretends empty field belongs to "only chars", is wrong. And 
if it is difficult to fix, then the validation mechanism design is 
wrong as well ...

The issue is that the VALIDATE-PANEL/INIT function will see the field 
prefilled with an empty value and this passes validation
 - why is that so?

As for me, I can imagine Henrik doing much more important work, especially, 
as we have just few basic styles, which are even not working properly 
yet. But - we can't see the big picture. Henrik's work can go in 
parallel, and I think that Robert is sane enough to know what he 
is doing/requesting and why. That means - we have to be missing something 
...

I just think that the work is running in multiple levels (native 
- Cyphre, styles - Rebolek, high-level - Henrik), and at some point 
in time, it will all settle down and merge together ...

Of course I am tempted to see things we expect most - more complete 
styleset and at least basically usable gui, but I will test what 
comes-out, as I think talking about what will come next just makes 
guys nervous :-) Of course some basic time-frame  would be usefull 
...

yes. what if you want to allow both empty and only-chars?

If I want to allow both empty and only-chars, then I have to explicitly 
express that. But only-chars itself has to fail on an empty field, 
no? Maybe I am just wrongly guessing something from the validation 
test example form field descritions ... I will wait for docs ...

I think I still don't understand the issue. And also - many users 
might not care much about the implementation issues, but about the 
validity of the output. And not-numers positive validation for an 
empty field is simply incorrect imo ... I will wait for the planned 
changes, and then reevaluate ...

What about introducing special validators then? I know that would 
create several possible combinations - not-empty-only-chars, but 
you could still be safe. Just thinking loud. And also - the naming 
conventions: 

not-empty --> required
not-empty only-chars --> required-chars
not-empty only-numbers --> required-numbers


Also thinking about the analogy to parse, but ppl would have to be 
familiar with parse dialect:

some-chars (includes not-empty)
any-chars (empty or any char)

Not sure it would be usefull today, but would it be possible to have 
some validation per keypress? In the past I remember fields, which 
were defined as variable to get VTG = $("A", "B"), allowing to enter 
only A and B (for the floppy drive purpose :-)

It was decided a long time ago to do future projects in R3 as we 
felt that continuing to write testing tools, frameworks, etc. under 
R2 would give a big pile of work later, when converting that to R3.

Considering also that the result of that decision is that Carl is 
now in tight communication with RM Asset, I think it was a good decision, 
as we avoid the months of darkness without info. It gives RM Asset 
control in what direction to take the GUI and to work towards R3 
being a usable product as quickly as possible, when you have to answer 
to other companies and customers. SDK is also a requirement, that 
we hope can be pushed through as quickly as possible.

Pekr, I'd like to hear your opinion on this: Instead of PANEL and 
GROUP there will be VPANEL, HPANEL, VGROUP and HGROUP. Is it end 
of the world as we know it, or are you fine with it? ;)

There are some more details: The reason would be to no longer have 
it be unclear from source what the layout direction is. Prepending 
V and H removes that doubt. Also you would no longer need to write:

panel 0 [...

to get a horizontal panel with an infinite amount of columns.

just write:

hpanel [...

it always was a prototype.... and the finished product always was 
meant to be glass.

right now, glass is being used in my largest commercial app I've 
ever developped and its 100% stable.

Henrik, I too think the biggest difference between a VPANEL and a 
HGROUP is the orientation, more so than applied or missing spacing/padding 
as is established thru PANELs vs GROUPs. Yet with this naming is 
encoded in just one letter H and V.  

What's the reasoning to not use something like PILE [...] vs LINE 
[...] or just COLUMN [...] vs ROW [...] or, even, HORIZONTAL [...] 
vs VERTICAL [...]?

And making the difference between GROUPs and PANELs an attribute 
to those? Are there fundamental behavioural differences between panels 
and groups?

Yes, unlike in Carl's R3GUI, PANEL and GROUP are now different internally.

Just thinking loud: What if, since as you say, panels use a grid 
layout, you just name them GRID? With ROWs and COLUMNS being horizontal 
and vertical subtypes of GRIDs. Like PILE and LINE could be subtypes 
of GROUPS. GOUPS and GRIDS finally being subtypes of PANEL. I don't 
think the behavioural difference between "your" groups and panels 
is communicated very well by these names inherited from Carl's work.

Rebolek, yes,hence my question on making PANEL and GROUP behaviour 
an attribute ;-)

I do understand that you want to express the behavioural symmetry 
in PANELS and GROUPS. It's a bit like multiple inheritance: Inherit 
behaviour from PANEL or GROUP, inherit orientation from HORIZONTAL 
or VERTICAL. That's 4 possibilities, and any name chosen is likely 
to overemphasize one aspect over the other.

groups flow faces by their individual size, like Google Images, while 
panels use a grid of cells.

 - that is important to know, and it will be missed by many, unless 
 properly documented ...

Originally, GROUP and PANEL were same styles with different orientation. 
That has changed and now GROUP and PANEL are two different layout 
engines. So we need to come up with names for horizontal and vertical 
variations of GROUP and PANEL. So far we've got H*/V*, but if there 
are better names, it can be changed.

Also the names GROUP and PANEL can be changed if someone can come 
up with a better word to describe the layout engine (like GRID for 
PANEL, but I think GRID should be reserved for true GRID style).

The problem is we are trying to eliminate the need for using column 
definitions in case of one row/one column layout.

Currently you would write:
view [
	panel 1 [
		panel [
			button
			button
		]
		panel 1 [
			button
			button
		]
	]
]

or in case of 'inverted defaults' for panel without any number:

view [
	panel [
		panel 2 [
			button
			button
		]
		panel [
			button
			button
		]
	]
]




Which would make two panels in one column. First panel would have 
2 buttons in one row and second panel 2 buttons in one column.


I personally think this description of the same layout would be more 
readable:

view [
	vpanel [
		hpanel [
			button
			button
		]
		vpanel [
			button
			button
		]
	]
]


So the key is to improve readablility of the layout definition in 
cases that will be used from 99% IMO.

Anyone have better solution?

As for naming - it was/is Carl, who tends to be picky upon the names. 
It is very understandable, otoh we introduced many concepts, as face, 
feel, which will say nothing to ppl coming from external environment. 
OTOH when I talked to Carl during the period when he tried to redefine 
View, he said something like - ppl will extend/improve/use system, 
which they like to use. So - with vpanel, hpanel, it is imediatelly 
imo obvious to users, what does it mean. I know that we can learn 
from docs first, but there is nothing better than self-explanatory 
code. We have to find some balance here, and with more higher level 
dialects, I would try to be closer to occassional users, rather than 
sticking to strict REBOL naming conventions ... that is my opinion 
...

Back to ACROSS and BELOW, then? Those have never been misleading, 
they just weren't styles in R2/VID but layout directives which were 
lost after the layout phase finished. And make the difference between 
PANEL, GROUP, TIGHT behaviour an attribute to them, with reasonable 
defaults. Would that even work?

layout [
	below [
		across [ ... ]
		below [ ... ]
		below 'tight [		; TIGHT behaviour
			button
			button
		]
	]
	across [
		...
	]
]

what about GROUP or TIGHT...

 - in case of GROUP it would become VGROUP and HGROUP. The TIGHT style 
 I see more loke a shortcut that can be specific to single kind of 
 container. Even if we have only PANEL and GROUP it would be specific 
 to only one variant. IMO the TIGHT style shouldn't be probably in 
 the basic style set. It would be better that user 'stylyze' the basic 
 styles  which with different box-model parameters according to  his 
 own needs.

I'm doing a document on compound styles. They are easy to understand. 
I ran into a few snags, which hopefully will be solved this week, 
and then you'll get the document.

Bolek +1 - Don't use GRID for these names, unless we call it a canonical-grid. 


Christian, I thought of across/below as well, but understand Cyphre's 
reasoning.

Panel 1

 or "group 2" give little meaning to the numbers. H and V prefixes 
 make things clear, but...


groups flow faces by their individual size, like Google Images, while 
panels use a grid of cells.
 


What are the use cases for each style? Is it accurate to say that 
PANEL is for cases where you want things neatly aligned, and GROUP 
is for cases where alignment isn't important, and tighter positioning 
based on face size is desired?

ok, so the number would means 'columns' for hpanel and 'rows' for 
vpanel. Anyone thinks it should be some other way?

I've actually not used either, Pekr just asked for other interpretations 
- and that's how I first read Cyphre's code.


Pekr:  Elements divided by number, rounded up (with final column 
simply containing the remainder) is how I would do it...

Izkata: understood, and how about the Hpanel? There you want the 
layout proposed by Pekr?

If you have V* than the number is always H and vice versa. IMO that's 
something good to remember. Otherwise source can become to chatty. 
And yes, laying out the code in the intended way is good style anyway.

So, if you specify an H or V mode (and mindset), then when you're 
grouping your faces, do you think in terms of a FORSKIP look or a 
SPLIT model? And what makes it easy to add a new row or col?

Note, I am not saying that's what I expect, but rather it's to visualize 
how the orientation affects the order. 


Something else to think about is whether you can, or should be able 
to, invert H and V and have the layout still work.

invert H and V and have the layout still work

 - that is generally not impossible, of course, but it is against 
 the readability requirement Cyphre mentioned as his reason why he 
 proposed Hpanel and Vpanel styles instead of having panel #H panel 
 #V

I don' t know how the row/col value overrides, or avoids conflicting 
with, the width of the face, or if the parent' panel is sized as 
a layout, based on sub-faces and you can't change it. A pair! would 
have the same problem, if used to explicity state both the number 
of rows and columns.

Yes, and I think the grouping of the data in the code layout is the 
driving force there. The number tells you how many "groups" (H or 
V) and then you enter items so they are contextually related in the 
code.