World: r3wp

the GUIE context may also change, once the R3 GUI becomes a module.

eg. set the face of the 3rd field ...

we have something like that with the NEXT-FACE? BACK-FACE? FIND-FACE? 
functions.

and to traverse the pane of a face, you traverse the FACES block. 
the setup for the face tree is simpler to navigate than in R2, because 
you are for example not allowed to make that block into a face, I 
believe.

I mean from outside ..

found the path. not in GUIE, but from what's returned from VIEW:

l: view/no-wait [f: field]

l/data/faces/1/faces/1 ; the field, but not with variable name

so there's a context which has to be found

an alternative, probably a more sensible one for large GUIs is to 
reference the faces from within the layout and then using functions 
externally:

boo: func [face] [print get-face face]

view [f: field button submit 'f boo]

with the problem that if your function sets a large number of faces 
...

fortunately we can set a large number of faces at once, if your layout 
is properly arranged.

Bolek, our private world is down, so I have to post here:


1. Some pointers on SPACING, MARGIN and PADDING: I think they should 
be standardized so that SPACING is 2-5 pixels, while PADDING and 
MARGIN remain at zero, so we can special-case them. We should reference 
these values in each style by STANDARD-SPACING, STANDARD-MARGIN and 
STANDARD-PADDING, rather than hardcoded values.


2. The PAD style retains its color on a differently colored PANEL.

2. (which it shouldn't do. it should be transparent.)

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

Slightly more meaningful display of form validation.

keep them coming :-)

Bolek, I partially take back point 1. It seems that SPACING both 
does spacing outside the faces and between them. IMHO, they are two 
separate parameters.

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


The ABOUT-PROGRAM function. Only a few lines of code to produce an 
About window. Information is grabbed from the script header.

the last one is very uninteresting gfx wise :-) Better let's add 
another 20 lines of code, and format it to look less dull ... :-)

that would not be the place to do it. it would happen on a lower 
level.

Thanks for posting Henrik!


On About, let's not forget encapped apps and multi-script apps. That 
is, how we should use system/script/header in various scenarios.

yes, we'll get that done too.

after seing the few screen caps i would say it"s flat ...  teh whole 
interface apears so flat .... other while i like the grouping and 
the global look of gob elements.

shadwolf, yes. that's because no time has been spent on skinning.

so once again: complaints about issues that have no relevance to 
the current state of the R3 GUI. I would rather have wishes for dialog 
handling, form validation, how the help system should work and how 
to build more intelligence into the GUI.

ok that's just what i noticed and i'm sure most people will notice 
that too ...  but it's a now in days visual fashion to have flat 
styled GUI but in general it all flat appart the buttons and  the 
text fields or text area wich are sunken and break the visual monotony 
...

that's not a complain that's a constation .... i will not say what 
it is not true just to flater your ego ... it's flat and it's dark 
grey ...

most people will notice that too

 - yes. unfortunately, it's the *least* relevant thing to worry about 
 right now.

henrik GUI was is and will always be for ever look issue over functionnalities 
...

shadwolf, you are pretty good at misunderstanding how large GUIs 
are and should be constructed.

As ever do the hard things first ...

maybe ... but being ugly shouldn't be you main motivation :)

because pretty or ugly: it will not help to speed up development 
time for a large program from months to weeks. having a proper GUI 
architecture saves money in the end. money! :-)

GRaham sure ... but you know things piles up you don't do the most 
 easy part and having the most  impact because you have other better 
things to add more important and in the end you have 10 times the 
gob doing the same thing in an ugly way ...

compare the 10 years that Max has spent on glass vs the months that 
Henrik has spent

graham yeah but who said henrik was supposed to be lonely ? ok are 
we talking about the default set of widget or are we speaking of 
custom made widget set. that's not the same...

graham most of those 10  years of developpement were based on overcomming 
limitations of R2 VID...

We need to get the basic infrastructure code to a level that it can 
be used by others and won't result in everyone fixen (and by this 
forking) the R3-GUI code.

As soon as this is done, it's released and you all can start writing 
styles like made. At this time it's ensured that it all will fit 
together.

And how close are we?

It doesn't make any sense to fragment our community by having 10 
different GUI libs.

And any idea why the new draw stuff wasn't in the A103 hostkit?

host-kit was the first mandatory step so that we can now fix GUI 
bugs that we find while developing the base infrastructure code. 
This is now done.

draw: No specific reason. I think Carl, wanted to get A103 out of 
the door to get feedback on callbacks. I think an update will come 
soon, as everything is there and can be included.

basic-styles: We need to provide some basic styles with resizing 
etc. included, so you can see how this all works. This is what we 
currently do. Sprint review is today. Than I will have a better overview 
about where we are at the moment. ASAP we will release the GUI to 
you.

Shadwolf, if you have suggestions for the UI look, by all means post 
samples. Maybe you didn't know the look hadn't been decided, so just 
consider posting messages with a positive spin to encourage those 
working for our benefit to continue doing so. ;-)

If say I wanted to try helping out with the graphic design of the 
GUI, what would be the best approach? Create some mock-up using a 
graphics design app? Can REBOL create anything I could come up with? 
What are the limitations I should impose on the design in terms of 
UI states, style overlapping, transparency, etc?

maybe we should put up a bounty and try to get a bunch of proposals 
done using www.99designs.com - seems a pretty decent way of getting 
ideas from a whole bunch of designers all the while being able to 
guide their designs using feedback

I'd put up some cash for that

but even there, the problem could be that a concept that looks good 
as a 2D design can't be implemented adequately in the REBOL's GUI

R3Gui is a closed development ... they're not looking to be distracted 
from finishing their design goals.  After that ... I guess it would 
be much more feasible.

I'm not talking about the programming part, but strictly the look