World: r3wp

thank you sunanda ... but then we don't have any idea of the converting 
lenght ... ok so the info are ''at August 14 th  2010, the Rich text 
dialect is adapted to the new project GUI using host kit . And Robert 
could compile it properly"

and i think if i try to discuss the dialect content in the new host 
kit i will be once again of topic ...

off topic ...

Cyphre, you GUI update inside a network looks similar to what I did 
... but which didn't work!  Ok, time for me to try again.

All my GUI updates occurred after network activity completed.

Graham , you have to send small chunks of the data (according to 
Carls notes for the R3 schemes the chunk should be smaller than 32Kb..this 
is true othervise the port connection 'hangs' for me if the chunks 
are bigger ) and do the update during that periods when you need. 
That's all the magic.

My data was a lot smaller than 32k so I think i have some other issue

Just in relation to the binding issues being discussed in core, how 
does R3 gui work ... are named gobs in the global context or private?

they are in a private context

so how does one access them?

this is a problem that needs to be solved. I don't remember the exact 
path inside the GUIE context to the faces.

however the context privacy feature should be kept. it's very useful 
with multiple instances of the same layout.

sure ...

But I was wondering how to access the faces by name

inside the layout, you are fine:

view [f: field button do [set-face f "boo"]]


Outside, you need to go through the GUIE context, but I don't recall 
the path.

I think what would be neat would be a way to access widgets by index 
...

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