AltME groups: search

Ah, wrong group then. The layout dialect is implicit in R3's VIEW 
function now, not implemented by a separate LAYOUT function.

Get rid of the call to LAYOUT, and it will create and show a layout 
with a button titled "test Brian". When that button is clicked, the 
button's action will be triggered, and the result of NOW will be 
printed to the console.

Graham - in R3 VID there is simply a 'do keyword, preceeding the 
action block, nothing more ...

so either there is a compose/deep somewhere .. or there is a switch 
to the do dialect occuring

That demo is outdated, but yes, there is a compose somewhere.

whether it has, or whether it should be put in ... I do a lot

Actually there are several changes by Bolek and Cyphre, that I've 
not yet studied, but much of the work that was handled by LAYOUT 
before is now relegated to PANEL and GROUP, which is why we talk 
so much about them and not a central LAYOUT function. They call various 
subfunctions that specifically focus on creating faces and laying 
them out and resizing them.


So the styles themselves are capable of custom layouts and resizing 
mechanisms and also mechanisms such as face init and triggers. So 
that means you are no longer a "slave" of the LAYOUT function.

That's also why:


1. I was talking a while ago about that you can build a style that 
emulates VID, complete with a dialect, or replace the layout mechanism 
with your own, by rewriting PANEL or GROUP or adding new panel styles.

2. That whenever you want to do a new thing, you should make it as 
a style. That's where you start.

BrianH: stop claiming we don't refer to R3 GUI as VID, please? Where 
did you find out such a claim? It was VID 3 (Gab's version), and 
Carl's version was marked as VID 3.4 by Carl himself imo. There is 
NO point to stop calling it a VID, unless we find another marketing 
name, just because the architecture changed ...

in a panel ?

Yeah. And then we decided to stop calling it VID because of the confusion. 
There was even a blog where a new name was requested, but it never 
came to a consensus. So we ended up calling it the R# GUI by default. 
The only one who still calls it VID is Pekr.

graham, if you want, you can do something like this:

view [vid [...regular vid dialect...]]

If you write a style called VID and implement the dialect in it.

there's no limit to the size and complexity of a style, if that's 
what you mean.

There is no confusion, sooner or later we do reach the matrix's "there 
is no spoon" = there is no R2 - old, forgotten, boring. Do you call 
Delphi 6 not a Delphi, because you can't run the code in Delphi 2 
anymore? Does Perl 6 rename, even if different to the old generation? 
VID is a good name. Simply put version 3.x is not compatible with 
version 2.x, easy as that ... I can't see any confusion, if we talk 
about VID in R3 related channels ...

R3GUI is surely not a final name, althought not that bad. It reads 
as REGUI, which is close to RebGUI :-) It will not work, once R4 
is introduced (in 2020 or so :-)

vivid.com si a porn-site though, so I think that VIVID is 1) not 
useable due to the factor mentioned 2) maybe too general name to 
google for? maybe vivid-gui.com would work though, dunno ... let's 
not opent the topic right now, there was something like 40 or more 
names suggested :-)

Vivid is a standard english word, so it will not be as easy to search 
for on the internet.

(finally a topic that everyone can contribute to :-))

A search for GOD may take a lifetime to find any useful answers :)

How would a search for REBOL GOD not turn up references to Carl, 
Gabriele or Ladislav? :)

http://www.rebol.net/wiki/Glossary
Face

A REBOL object serving as a VID element. A higher level than the 
gob! datatype.

Gabriele, thanks for that "dying for our sins" thing. That was a 
classy thing to do :)

You'll be more than a tea port in a planetary orbit

Ahh... Gabriele has gone .. in a puff of celestial smoke!  http://en.wikipedia.org/wiki/Russell's_teapot

steeve is doing an irc mini client like ... the font is well designed 
but a gamma correction 2.0 isn't it a bit too clear ? why 2.0 and 
not 20.0 ? seems something completly arbitrary again a speudo hack 
to solve a lack of real work ...

CAn we have a better calling for R3 hostkit package ... since it's 
supposed to haven't change on API level can't we distinguish the 
number for the hostkit api version and a number for the GUI related 
engine ? something like r3-hostkit-102-GUI-still-the-same.zip ?

IIRC there was a screenshot showing grid is available for new gui? 
Done by Cyphre?

resizing: This is a quite complex topic and we need to make tests, 
try different approaches and fine tune tor the special cases we find. 
So, we don't do it completely up-front, but we adopt it on the way 
until it stabilizes.

In my GUI trial, the resizing of styles use a small amount of primitives.
When a resize event is triggered. I mix them in an intuitive way.

....
when [
	resize [resize xy]  ;full resizing both direction
	resize [resize x]   ; resize the height only (for menu bar)

 resize [move x resize y] ; move the x offset, resize the width (for 
 right scroll bar)

 resize [move y resize x] ; move the y offset, resize the height (for 
 bottom scroll bar)

 resize [resize xy do-childs [trigger resize]] ;full resize + pass 
 the resize event thru all child gobs (for container)
]

or, he has a swivel monitor?

A bit of status: Lots of work on resizing right now, specifically 
a bug that occurs on maximize.

James Marsden was also writing a GUI for R3

I need a code/prototype reviewer for reviewing the validation prototype 
and the dialogs prototype.

I need a review of specific source code, the concepts and prototype 
documents. This is to ensure that the prototype doesn't lack important 
features that I didn't think about, before the prototypes are integrated 
into the R3 GUI.

Im waiting for a more stable R3 before I continue GUI work.  Too 
busy at the moment to play with the host-kits.

ok, I am leaving for a tomorrow's management meeting, so first day 
I will be able to play with it is Sunday, and maybe some of evenings 
next week, we will see ...

argh... I don't like those compressed scripts, i don't run them if 
can't have a look before :o

not yet. I can upload a bunch in a minute, but try:

view [button]

Steeve, that's a lowlevel bug that Cyphre wants to fix. it's in the 
queue.

that is the resize bug mentioned a couple of pages back, also in 
the queue.

I take it that this is a hidden queue

I hope they have a way of integrating back to CC later on!

it's not a formal release. I decided to do this, because the build 
system became available for use internally today.

Any R3VIDs available for playing with yet?
 ... I'm still experimenting, but nothing in a useable state.

well, did you see the images?

henrik (and I) did a few aqua-esque AGG driven buttons.

That is, Thanks a lot

well, they were just a test of what DRAW could do. I have something 
hopefully better in mind. :-)

that part is not so difficult. it's more difficult to get a style 
that works in both high and low contrast and with many different 
colors. much of what is in that script is hardcoded.

http://rebol.hmkdesign.dk/files/r3/gui/026.png


Some of the last glow stuff I did which is not hardcoded, but done 
using a real material system with calculated specular highlight.

http://rebol.hmkdesign.dk/files/r3/gui/143.png


It'll probably be closer to this. I find a good source of inspiration 
in this skin that can yield some interesting results.

yep... in my experience ... back face glowing is the hardest color 
staturation issue to solve  :-)


we must not think in terme of color but energy, which is related 
to gamma and brightness of the color saturation (probably even channel 
based, since green is perceived twice or fourtimes a smuch as blue 
and red)

also note that wavelenghts for red don't penetrate as well thru blue 
IIRC... so a red sign under water appears black at a VERY short distance... 
something like 30meters IIRC.

Henrik... if it's not too soon to talk about look, but please, make 
a light version as well... I would like to know, what's your monitor's 
resolution because I have 1440x900 and you style is so heavy!

Oldes, I have changed display a couple of times since the cool-widget 
script was made and the heavy look in the later screenshot is mostly 
because I found fonts to be not very readable in buttons unless it 
was precisely that look and size. My current screen is 1680x1050 
and I test also on a bad 1280x800 display. I have some ideas for 
different widget sizes and different types of contrast.

It's also a lot wider than that of RebGUI's

the scroller handle looks as though it is illuminated from a different 
side to the scroller ??

Generally, always use this (please download as it's on a low bandwidth 
connection):

http://rebol.hmkdesign.dk/files/r3/gui/r3-gui.r3

For validation, a proposal was written:


http://rebol.hmkdesign.dk/files/r3/gui/docs/validation-proposal.html

This has been translated into a prototype:

http://rebol.hmkdesign.dk/files/r3/gui/validation.r3


and then a set of notes on how the prototype works has been written:


http://rebol.hmkdesign.dk/files/r3/gui/docs/validation-prototype.html

and building it into the style we need to validate is as far as I 
can tell, a whole lot more work.

yes, validation is a simple indicator style. the "catch" is that 
you need to place it one place to the right of the style to validate. 
Carl also talked about doing the validation action itself as a reactor, 
but the role of reactors is still not clearly defined to me.

instead of having a dedicated icon

Probably a bit different topic, albeit related - in one DOS app generator 
I worked with, there was a possibility to e.g.:

- init form values (e.g. when you create new record)

- set 'update trigger - you could have multiple update actions (it 
was quite primitive, but sufficient - operators like +, -, replace), 
so e.g. entering some value into 'amount field, could trigger an 
update into other field on the form, or later during the commit, 
to even a different table.

- getting/setting values of the form/panel is surely going to come 
IIRC

graham, that's not a good alternative:

1. you create multiple ways of indicating validation

2. you may not be validating a field, but an entire panel or any 
other style

3. you still need to alter the style itself, which will be a ton 
of work.

that's a small problem compared to working validation into each style

also fields will eventually become sub-fields in tight panels, where 
the fields themselves may not be incorrect, but the overall value 
combination may be wrong, such as that for a date field and that 
can be for multiple different reasons. this is why the valid-indicator 
would contain a tool-tip to describe the problem. you would be eventually 
able to click on it, to get an overview or deeper help on how to 
solve the issue via the help system (not yet written).

As for business apps - that sounds fine, it is just that we did not 
see e.g. list of styles, you might need. Is there e.g. a tree-view? 
Tabs? Table is there IIRC (there is a screenshot on henrik's site)

graham, and I posted all the relevant information to validation and 
dialogs a week ago, the build system 2 weeks ago. zero feedback.

when is validation triggered? In DOS app generator I mentioned, there 
was such a functionality, that you could limit values to type - it 
was called 'vtg - variable-to-get, and it was used e.g. when you 
wanted to limit selection to floppy drive A, B values, etc. :-) Nowadays 
we have list-boxes, but I still can imagine special kind of fields, 
e.g. Date, IP field with various masks, allowing to type only numbers 
for e.g. But that would require validation being triggered on per-press 
basis ... just thinking out loudly ....

currently validation is triggered on window open to init state. then 
you can call it on the window as needed and it runs also as a reactor, 
hence every time a field is unfocused or a button is pressed. it 
also is triggered on window close, given the button that closes the 
window is a dialog button.

as for the type of validation, that is completely customizable. you 
can also scope validation, so you can say that a panel of fields 
may not be empty, by adding that option to the panel instead of each 
field.

http://rebol.hmkdesign.dk/files/r3/gui/236.png

Materials system is back in (just a quick test)

Cool :-) Cold you please say few words about the material system? 
What's its purpose, design? Is it more complex/flexible system, or 
just mostly a gradient/background replacement? thanks ....

the purpose is both to eliminate the need for fiddling with colors 
directly when creating a gradient surface for, say, a button, and 
both to store material settings, so you can switch quickly between 
them or select one for a style. so for gradients, instead of working 
with RGB values (unwieldy), you work with brightness, diffusion and 
specular.

and also - does material mean a skin? Or is material system going 
to be part of even more complex/flexible skinning? Note - those are 
just question, so no offense :-)

no, material doesn't mean skin. it's only a small part of the skin 
where you can reference a pre-calculated gradient by name for a single 
part in the draw block.

if anything, inspiration was drawn from 3D modelers on how they apply 
textures and surface to a 3D model. Bolek is working on improving 
the way that materials are created and used.

no, the material system simply calculates a gradient block or a color. 
then you are free to use it whereever you want.

Henrik - maybe I do, maybe I don't. What I did not get is - why the 
stuff is not nested? I mean - is 'required parameter kind of related 
to validation stuff? If so, I would expect something like:

validate [method: not-empty required: true]


... the way it is - we  might polute 'options namespace, which serves 
also other purpose. But again - its just a note, not a complain ...

it is nested. 'required indicates that the field is required, so 
that if the field does not validate, that constitutes a fatal error. 
otherwise it only presents a warning.

btw - back to my DOS app generator (Clipper + Zachary) :-) There 
was one other interesting feature. Let's say you have an invoice. 
And you have field to enter a company. That field is validated against 
customers table. There was a validation option named 'must-exist, 
may-not-exist. That way user could either enter new value, or only 
choose from existing values. But - the customer table was not probably 
a good example. 


And then - each grid/table had options too, called AED (Add, Edit, 
Delete), plus option, if you allow ADD option caused by validation. 
Example - you enter customer name - it is not found in customer table. 
If you allow 'Add option for grid, when user entered new customer 
name, and not found, it automatically popped-up a form, to enter 
new customer. If 'Add option was not allowed, then the person had 
to call someone, who had rights to enter the data directly into Customer 
table ... well, probably confusing description :-)

there was a download link posted on altme... though its probably 
lost in the chat.

Pekr, must-exist or may-not-exist could be done as validation, but 
unsure if it's a good workflow. That depends on each UI case, however 
you are free to design the validators as you see fit. you can also 
run mulitple validators in sequence.

I think robert also had a precompiled version ... or is that in the 
zip file nowadays?

I think that a compiled version of each host-kit should always be 
included in every release. who will mind the few extra kb required?

this way a single rebol release channel covers everyone.

i like henrik's work so far  that's what i was talking about when 
i was asking for a mature widget set...

thanks to Gregg for a really good session on reviewing the validation 
scheme. this is precisely what I needed.

some notes:


- validators 'not-empty and 'selected are overlapping, so maybe 'selected 
should not work on blocks but simply check if the output of the face 
is NONE

- using the 'only-positive validator alone will cause a crash, if 
the input is not a number and if the previous validator is not a 
check for number values. I designed it like this to indicate that 
the value may not be anything but a number, but there is a disagreement 
over whether incorrect usage should cause a crash.

only-positive: I would expect an implicit check for a number. If 
it fails, it's not positive.

The message to the user should be: Not a number.

Hence with the correct setup, you would get a not a number error.

you can combine multiple validators in sequence for a face and the 
first one that fails, stops validation for that face.

Yes, I understand. I would expect that only-positive than combines 
two validators: is-number & greater-zero as a pre-set validator.

ok, I guess we need a way to combine validators

It enforces a minimum size window but only after you first resize 
it

it seems to be a broken exe. a new one should be distributed.

Also size must be a pair?  It complains if I just use an integer

there is a method to restrict the window size. perhaps it is a bit 
too aggressive, but the option is needed in some cases.

In that field, if you press backspace, do you get a crash?

And plese - tell me if you are interested in such hints, as it might 
get you nervous :-) We like pre-releases, but so far my feeling is 
- Gabs VID3 was able to show us Image Lab demo - resizing IIRC, drag 
and drop, alpha channels, changing mouse pointer ... then came the 
VID3.4 from Carl, it felt lightweight, but did 70% of Gabs VID? And 
now we are seing some XY percent of functionality of Carl's VID :-) 
I just hope it' still just work-in-progress, but I really wonder 
if stuff like validation is important now, in a state where there 
is very few usefull styles?

(that was caused by pressing the back-space in a field widget ....

As long as we don't explicitly state: Please give it a try and provide 
us feedback on A, B and C things might not work at all. you can give 
feedback but don't expect that we always care about it.