World: r3wp

So a script should be able to check for the latest version and download 
it into the public cache (which may be successful or not, depending 
if net connection is available), eg:
	do load-thru http://www.dobeash.com/it/rebgui/get-latest.r
and then just
	do path-thru http://www.dobeash.com/it/rebgui/rebgui.r

to initialize (which automatically falls back to any previously cached 
version).

Another issue:  Excuse me if this has come up before..  

The archetypal View face has some of its facets set to none, which 
makes using VID styles alongside RebGUI more difficult (because the 
VID-based styles are not expecting those facets to be changed.)

Suggestion: create widgets/rebgui-face and encourage widget creators 
to make from that.

And now a question:
	widgets: make widgets [ my-widget: make face [ ... ] ]

the best (or only) way to add your widget to rebgui, making it available 
to DISPLAY ?

table: Is the table widget missing an action when clicking a line? 
Of how do I add this feature? Is there a way to color odd/even rows 
differently?

mixing vid with rebgui has also some api-problems. some i found:

 /action: has in vid this args: [face value]. value is something usefull, 
 like area/text, slider/tdata, first text-list/picked etc. maybe its 
 not needed, "value" saves not much to "face/text". but supporting 
 that arg would be compatible

 /init: in vid this is a block and 'done. in rebgui it is a function. 
 vid has the advantage that init can be easily extended in substyles, 
 just add to it. rebgui has locals because it uses a function.
 /init2: not called by vid. 

resizing: not in vid, but one could write a /resize and plug it in 
the vid-face.

also there are some global changes which may break other things (removing 
event-func and changing global face IIRC).


If there is interest in making such small changes, i would help with 
making the rest compatible. adding #xh - parsing to 'layout and such. 
for "keep small" rebgui could have a "load-time-flag" to decide about 
using vid-stuff or all own.

What i would really like is rebgui for complex style-building (area 
with slider etc). this is closer to raw faces. and vid for quickly 
writing "pages", IMHO it has a rest of advantages there. (maybe not, 
i am a rebgui-beginner).

Robert looks to my listview code ;)

http://shadwolf.free.fr/rebgui-list49.r

I already did ;-) and got it mostly working. but not that straight 
forward as I like to see it.

Anton

 1) Design decisions: thanks; if you think any of them were *bad* 
 then let me know, that's the reason it's still alpha ;)

 2) I like the edit-pair demo, I'll look at adding a cut-down version 
 of it to %tour.r

 3) Versioning / caching was something I was going to look at once 
 RebGUI goes beta and / or we have more of a handle on how REBOL/Services 
 works.
	4) "local" face definition: good point, added to next build.

 5) Extending widgets object: Yes, RebGUI doesn't have a "stylize" 
 system so you have to extend the widgets object when you need to 
 add your own. My hope is that with a functionally rich set of widgets 
 this will be the exception rather than the rule!

Robert

 Action handler not yet added to table widget. I'll add odd/even coloring 
 to the ToDo list.

Volker

 [face value] - less important for RebGUI as face/text or face/data 
 covers almost all cases; but I'll think on it a bit more as the compatibility 
 aspect is worth considering.
	/init - I'll look at making this a block in the next build.

 event-func removal - I'm considering a "load-time-flag" as you suggested
	system/standard/face - as per comments to Anton above
	"If there is ..." - agree fully with everything stated here ;)


RebGUI development is taking a slight pause until View 1.3 is released, 
as I want to baseline against that and remove all the pre-1.3 exceptions 
that have crept in.

Ashley you are right we need to base RebGUI on REBOL/View 1.3 that's 
the way it must be done ...

What's the time line on focus and tabbing between gadgets?

Ashley, I had also wrote a VID integer-edit style, then I decided 
to make a single function to generate pair, integer and decimal-edit 
styles. I could convert this in future. It kind of violates your 
"each widget self-contained" design feature, but the code shrinkage 
was too hard to resist, and the potential is there to support more 
datatypes...

5) Extending widgets object:   I was looking for a doc to show how 
to create the simplest widget ever. If you are happy keeping it this 
way (ie. "do it yourself") then I could write the example script 
and accompanying doc, to add to the Widget Designer's Guide.

... simplest widget ever ...
 How much is there to write about?

	widgets: make widgets [my-widget: make face []]

Or am I missing something? ;)


Your VID edit styles sound interesting, but I'm looking for a more 
universal solution to "field input masks" and "field input validation". 
Something that would let me define a telephone number mask for example.

some thing like a ###-#### for fone number for example and ??##??? 
for 2 strings followed by 2 number then by three  strings

like 555-1234

or AD21SQF

rafinement could be a coded like mask like 3#-4# (for fone number 
mask ) and 2?2#3? (for the 2chars then 2 number then 3 chars mask 
)

as fone number are different betwin areas it would be nice to can 
specify localisation for masks rules in the localisation file ;)

so ? = what ever a to z ot A to Z character and # = What ever 0 to 
 9 char all other caracteres  in it are considered as always needed 
 things. Repetition can be simplify be using numbers in the mask

like 2?-3#-5?

I think parsing rules that complains to my description is not so 
hard to do ;)

when an entry doesn"t feet to the mask a message must be displayed 
showwing and automated example of what must be a good entry to warn 
user :)

Nice, try just typing rebgui into the location bar on FireFox...

Ammon :when I type rebgui in the firefox 1.0.4 location bar I get 
the redirection to the rebol france article (in french) I wrote ;) 
king of little presentation for french readers

Hm...  You must be in france and Google's france branch must be redirecting 
you differently...

Ashley, very nice work. I have probably asked everyone in this group 
at one time or another about how VID works (or doesn't seem to). 
I really appreciate that you are working on something like this. 
I had all but given up trying to get my interfaces to function the 
way I wanted them to. At some point one has to just give in and focus 
on the actual program. Now I'm thinking I can have my cake and eat 
it too. Thanks big guy.

Ashley, I felt the need for this kind of validation / masking as 
well. Just never got around to it.  It's not simple.

Simplest widget ever
: you got it. :-)   That saves a lot of time getting started.

What is the mechanism to know which line in a table has been selected?

Not implemented yet.

Thanks.

Latest build available at: http://www.dobeash.com/files/RebGUI-024.zip

Highlights include:


 - New edit object / feel added in a separate file, %rebgui-edit.r

 - Documentation on above at: http://www.dobeash.com/it/rebgui/edit.html
	- Face redefinition localised to widgets object
	- Radio-group color toned down from green to leaf

Known issues:

	- auto-fill broken for the time being

 - edit feel needs to support tab / shift+tab into and out of "grouping" 
 widgets

 - cursor down goes to end of text instead of next line?! (yell if 
 you know the answer as I'm stumped on this one)

On the drawing board

	- area widget needs a scroller added to it by default
	- field format / validation masks
	- inline spell-checker

ashley I'll take a look at auto-fill on the weekend, and try and 
get it to behave like the VID version does. anything to look out 
for?

request-color

** Script Error: in expected object argument of type: object port
** Where: wake-event

** Near: if in pop-face/feel 'pop-detect [event: pop-face/feel/pop-detect 
pop-face event]
>>

drop-list

** Script Error: in expected object argument of type: object port
** Where: wake-event

** Near: if in pop-face/feel 'pop-detect [event: pop-face/feel/pop-detect 
pop-face event]
>>

with rebol/VM 1.2.116.3.1 and windows XP SP2 ( i don't experiment 
those bugs by my own there where submitted in the Form of rebolfrance.org 
website by cr8825.)

Allen: Thanks, should be a bit easier now that we have a [relatively] 
complete feel / focus system that is similar to VID's. ;)


shadwolf: these occur with latest View releases. They'll be corrected 
once View 1.3 is released.

Regarding use of color in RebGUI:


I don't think color choices for LEDs in RebGUI are good, which is 
namely because the default colors are red and green.

That not only excludes the color blinds, but even the red-green-blinds 
(sort of lesser color blinds), which applies to even more people 
(mainly male ones). 


Using blue and yellow would make things slightly better, but would 
still be a hurdle for full color blinds. Probably different shapes 
would be more usefull here, as they'd give an additional clue.


And, finally, the colours are named wrong in the LED group: check-group 
60x4 data ["Red" true "Green" false "Blue" none]

Believe me, I had to measure the valve values to find that out ;-)

And personally, I find the visuals of the sliders and draggering 
irritating, too.


The gradient in the sliders container IMHO doesn't integrate in the 
overall RebGUI appearence - since it's (button left aside) nearly 
the only pseudo-3d effect - and the visual contrast between dragger 
an container IMHO isn't very strong. I usually find me clicking in 
the container when I expected to grab the dragger.


The gradient in itself is somewhat unsual, too, since it makes the 
container appear standing out of screen, if one assumes that light 
falls from upper left corner (which is how most pseudo-3d screen 
elements are designed).

draggering = draggers

I second Christian's thoughts on the dragger and gradient.  I also 
found myself reaching for the gradient section thinking it was the 
dragger.  Because it has more graphic detail, it attracts the eye 
first... that should be left for the dragger/button itself in my 
opinion.  The background of the slider area should be flat.

Yep. And the current style doesn't fit to the rest of RebGUI.

I think the slider and scroller were quite quickly implemented and 
are not expected to be perfect at this stage. Having said that, I 
am now wondering if anyone else is working on new ones. It's the 
scroller widget I noticed yesterday needs some work and I thought 
I might contribute a new one.

By all means, please do. With regards to, "... wondering if anyone 
else is working on ...", I am in the process of putting together 
a dependency / project plan that shows how everything is related 
and what stage each widget / functional area is at (along with who 
is currently working on it). It's the first step to a more cooperative 
development model, but I'll implement it as a static web page until 
REBOL/Services is out.

Ok, so I'll do slider and scroller.

Good idea about the plan.

Here's another issue:
rebgui 0.2.4 defines a new global word 'edit

  This interfered with my custom edit function, which I use to launch 
  my favourite editor.
  I'm not changing it for you ! :)

  This is an example of the problem of adding words to the global context 
  without doing
  an environmental impact study first.

  The user should be given the choice whether to export your words 
  to the global context or not.
  But probably most of them don't need to be out there at all.

  My advice is to add only these words to the global context: [

 ctx-rebgui display show-text show-data show-title splash request-color 
 request-date request-file
  ]
  
  --- rebgui.r ---
  
	CTX-REBGUI: context [

		...

		edit: none
		widgets: none
		requestors: none
		display: none

		foreach [word file][
			edit		%rebgui-edit.r
			widgets		%rebgui-widgets.r
			requestors	%rebgui-requestors.r
			display		%rebgui-display.r
		][
			if none? word [set word do file]
		]
	]

	;if not value? 'edit [do %rebgui-edit.r]
	;if not value? 'widgets [do %rebgui-widgets.r]
	;if not value? 'requestors [do %rebgui-requestors.r]
	;if not value? 'display [do %rebgui-display.r]

	; export DISPLAY and the accessor functions to global context
	foreach word [display show-text show-data show-title splash][
		set word get in ctx-rebgui word
	]


  And each file no longer has a *named* context:

  --- edit.r ---

	REBOL [...]
	
	context [...]


  The above changes should mean few changes to the rebgui code. For 
  example, the body

  of the display function refers to the widgets context, but this is 
  still accessible
  because both DISPLAY and WIDGETS are inside ctx-rebgui.

ChristianE

 1) LED color / design choices. Agreed. Can anyone point me to where 
 this has been solved? Or suggest a design alternative?

 2) Red, Green, Blue. These were example LED titles (much like the 
 previous "One Two Three" example) *not* a statement about the actual 
 LED colors. ;) If the example's that confusing I'll change it.

 3) Sliders / Scrollers. Agreed. The priority has been to get a complete 
 set of widgets, *then* ensure each is functionally complete, and 
 *then* ensure they are aesthetically pleasing as a whole and in their 
 own right. As I'm no graphics artist, I've taken the easy approach 
 at first by mimicking what I'm familiar with: Windows XP.

The words I don't think need to be global are: [sld slm slc slw edit 
widgets requestors]
(and even the ones I have set out above I would scrutinize more.)