AltME groups: search

Behaviour for chars under particular keys:

2 - losing the focus of area
3 - tpyes "a"
4 - arrow down
5 - writes "Y"
6 - writes "~"
7, 8, 9, 0 - types correct Czech chars ...

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.

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.

New R3 compile should fix a scroll-wheel issue:

http://94.145.78.91/files/r3/gui/r3.exe
http://94.145.78.91/files/r3/gui/r3lib.dll

I need a function to figure out the style tree. Will have to write 
it later. That would be part of the documentation.

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

This will have to be done anyway, or how are you supposed to display 
styles for REBOL IDE, which you can place on a form? Unless you are 
supposed to do it manually of course ...

Since the GUI is not a module yet, I don't know whether the GUIE 
name stays.

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

we need a style browser, because that is a very quick way to check 
which styles are crashing. could not have shipped the vid extension 
kit without it.

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.

a 5% color difference can completely fix/destroy a style.

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

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.

You still can attach scroller to any style, but if the style has 
no code to handle scrolling, the scroller will just sit there, doing 
nothing. That's a good thing, because scroller cannot know how to 
scroll all styles it can be attached too. Carl's scroll did this, 
but all the styles must have supported only the one method of scrolling 
the scroller was able to use.

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

pekr... you seem to miss the point that no one is saying it is finished. 
  most of what you point out seems to be readily obvious.


give them a break, they are releasing as a curteousy since it helps 
make it obvious that its progressing.

Releasing often is a waste of time.

The appropriate way is to have a public repository

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:

No, because this will than become a community project. I'm going 
to pay the RMA Team, which is than indirectly a sponsoring of the 
R3-GUI project for the community to keep the momentum.

*want* = yes

*can* = only sporadically.  Tough I'll make it a point to make integration 
of my research stuff into yours (so I guess that counts as working 
*with* you :-).

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.

We are still buildin a bunch of infrastructure on our side, so that 
we can release stuff faster, know it will build for you, generate 
automatic change-logs etc.

Good to have at least something visual! As for use of multiple draw 
blocks - is it feature which is going to be implemented? I remember 
when Carl did VID 3.4, it was not plan. But I could not understand, 
how else some more complex styles, could be built, displaying various 
states, which are not easily doable by only parametrisation of one 
draw block. If it is planned, it is a good news.

Thanks. Btw - were we succesfull in getting in contact with the gfx 
artist? IIRC someone suggested one person to Robert, but I think 
that the person in question was not interested. I wonder if Amiga 
community could help here? :-) I think they will be kind of friendly 
to REBOL, because of Carl. Or put it another way - will you Henrik 
come up with some final skin, once there is a time to address it?

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.

Henrik - generally - do we have per-field validation, or per-form 
validation? I e.g. don't like systems, which lock me inside a field, 
untill I correct it. I hope it is the latter :-)

The scope is whatever you want to validate, whether it be a field 
or a whole form.

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

updated validation.r3. added also a field for the only-chars validator.

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

Is validation a fundamental gui aspect that has to be dealt with 
now?

Pekr, what if you have a case, where you want both?

Machine should have never a precedence instead of the human common 
sense :-)

new validation prototype at:

http://94.145.78.91/files/r3/gui/validation.r3

requires a new R3 GUI:

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

the ON-VALIDATE actor allows you to modify the face, based on the 
validation result. also simplified the validation process a bit, 
while adding the ability to use ANY for validators, as shown in the 
"Eric or James" field.

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

Will give it a try in the evening ...

need to get into the field by RM Asset as soon as possible

 ... wouldn't they be better off using R2? I gather SDK is not a requirement?

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.

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

I thought it was a great pity you never finished it

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

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 [...]?

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

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.

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.

VPANEL, HPANEL - very non-rebolish names, but I already have seen 
a departure from pure REBOL naming convention, with LIB, SYS introduction 
- very non rebolish too, whatever BrianH says :-)

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

do we want more names, or not?

 - it's very simple actually. if the options are too comprehensive 
 or to unclear to set for a style, make a derivative style. so, work 
 it out from that.

The Panel style until now lays the gobs horizontally; in a Panel 
with at least two columns, the second gob is laid out to the right 
of the first one.

If a VPanel existed, then it should lay the gobs out so, that in 
a VPanel with at least two rows, the second gob should be laid out 
below the first one. Does somebody see this differently?

DELECT allows a variable number of arguments. But the order of arguments 
must be fixed.

well, I would call it expected behavior. you have a known model you 
can simulate in your head.

Well, Pekr, if writtent this way, I wonder whether COLUMNS 1 could 
be understood as "a layout having 1 column", instead of "a layout 
having 1 row"?

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.

TIGHT is just a shorcut. I was using it, but I won't miss it if we 
agree to remove it.

TIGHT, I believe, is a concept that is useful, when you don't consider 
compound styles, which only works, with Carl's dead simple styles. 
Now that we have compound styles, it makes better sense to have a 
specific COMPOUND panel that produces the desired spacing.

What does it mean to have a compound style?

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?

replacing faces with different faces in a panel.

yes, a problem with DRAW.

Henrik - the style browser text-list is somehow flawed :-) I can't 
e.g. see area there - when you drag a scroller a bit, you can see, 
that the list changes, listing styles, which were not available in 
previous view :-)

Hm, really. I'll have a look at that.

Henrik - the style browser text-list is somehow flawed :-)

 The correct phrase would be: "Henrik - The style browser shows a 
 problem in the text-list style, which is a good thing, because it 
 means Rebolek can fix it. :-)"

I know what you mean, but the style browser is meant to display any 
flaws. It's a great testing tool.

Henrik - I said nothing. Maybe it is incorrect wording, dunno. What 
is more I even said "text-list is somehow flawed", not that style 
browser is flawed. It took me 3 min. to find a problem, so keep it 
coming ....

The thing is: Either the number is like a SKIP refinement or like 
the number for LOOP

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?

This is more a dialect design problem, i.e. what will be more "intuitive" 
for the user

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.

A pair! has two more problems, actually:


1) it is redundant, since knowing the number of cells, and just one 
of the dimensions, you can easily compute the other one; such a data 
redundancy is, in databases, called "denormalized data" and is undesirable

2) the user frequently wants to give just one number, assuming, that 
the other is computed every time some cells are added or removed, 
thus, not wishing to give the value for both dimensions

the user frequently wants to...

 - that it is not a speculation, I was told by Cyphre that there are 
 at least two users frequently wanting that

the last time I worked on a grid, the sizing values where autocomputed 
and shared accross rows and columns.

when one cell changed a single X or Y value, all the other cells 
of the same row or column where aware and could update on their own.

but the *design* of the layout engine provides logical clues into 
how it should be expressed in terms of a dialect.

to me a lot of this discussion resembles HTML table box model discussion... 
maybe you should look into how they solved the various issues.


for example, cells can "span", which is an elegent way to solve the 
gaps in cell data.

Yes, I think tables are key here (tbl did spanning long before HTML 
I believe :-). Do H and V panels help that much, e.g. to reduce clutter? 
I imagine the team talked about that, and whether just a TABLE would 
be enough.

Gregg: regarding the difference between Vpanel and Hpanel. Pekr wrote 
something that makes sense to me, showing how a layout should look. 
You wrote a "source code", which does not allow me to "see the look 
you want", in fact.

I'm trying to think of a good scenario where I would use Vpanel. 
The first thing that comes to mind is a multi-column file or directory 
listing. Is there a particular need it's meant to fill?

Regarding Graham's note about RebGUI - Cyphre checked it, and there 
we can use just a PANEL (which corresponds to the above proposed 
HPANEL, as it looks), and an AFTER X value, which corresponds to 
HPANEL X specifying the number of columns, not the number of rows, 
as Gregg/Izkata seem to propose for HPANEL

New R3 GUI which fixes a few styles, like text list, although text 
list will eventually be rewritten:

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


Style browser now shows style options, alphabetic sorting of style 
names, face debug option (currently broken in the R3 GUI):

http://94.145.78.91/files/r3/gui/style-browser.r3

I think that having VPANEL and HPANEL is very helpful. I have buiilt 
a few screen layouts with Flex which has VBox and HBox which layout 
the elements they contain vertically and horizontally respectively.


Typically, I have used VBox as the "outside" container to enclose 
a number of HBox.


In Flex, both VBox and HBox are descendants of  Box which includes 
a direction property, the default of which is horizontal.

I find it much clearer to write:
 <VBox>
  <HBox>
  </HBox>
  <HBox>
  </HBox>
</VBox>

than

<Box direction="vertical">
  <Box>
  </Box>
  <Box>
  </Box>
</Box>

I'm going to rephrase my idea: In general it could be possible to 
use blocks of blocks inside the layout. This would make it easier 
to generate layouts and not care about style argument lengths:

view [[button button] [field field]]


Of course you can't split a style in two blocks, but this wouldn't 
be needed anyway:

view [[button] [do [something]]]


This is similar to how gradients can be put in blocks inside DRAW. 
Is there anything that would conflict with that?

Henrik, good point. We need to consider "generate by script" in all 
dialects etc. IMO being able to use even more abstract descriptional 
approach and generate on the fly is a key pattern.

what about this kind of IDE looks like small talk but for rebol and 
Rebol/GUI having such a tools could be crazy look at this and try 
it 
illumination Software Creator 
http://radicalbreeze.com/

maybe in a different way / shape but since along ago i like the idea 
very smalltalk like to organize Applications like a UML model ... 
And i think rebol GUI could shape that and use that ...

as a matter of fact some lot of years ago we tryed something like 
a MERISE model representation of database with some people of french 
community (coccinelle; lucho) the project was Called LadyReb it was 
dropped  but the idea behind it was pretty similar.