World: r3wp

instead of 			unless any [
				(length? word) < 2

how about 

			unless any [
				1 = length? word

Button and many other widgets have an 'info option already. Any solution 
to disable a widget dynamically would have to be generic and done 
via functions like:

	set-disable
	set-enable


On a related note, I'm thinking a request-progress function might 
be handy. Would have the following format:

	request-progress 10000 [foreach f read %. [...]]
	request-progress/cancel 10000 [foreach f read %. [...]] [...]


Advantage would be that it is modal and provides useful feedback. 
The /cancel block provides a "cleanup" routine if the window is closed 
the cancel button is pressed. Without the refinement no window close 
button would be present and no cancel button. Useful?

A progress function would be useful .. but less useful for me, because 
modal windows can disrupt BEER async communications

hence I strive to avoid any modal windows if I can

I don't know if this applies to the async protocol in general as 
well

async tcp ie.

All the request-* functions are modal.

(length? word) < 2

 ... I think that was guarding against the empty string case as well. 
 But can be expressed better as "2 > length? word" anyway. Or just 
 drop the condition entirely. After all, "a" is a valid "word" "z" 
 is not.

yes, I know about the modal request functions, and I have to write 
my own non-modal ones

What a pain :(

Spell

 checking 'a' and 'I', note uppercase only, would be handy.  Then 
 math gets in the way  :)

I'd be 'either or' on that one.  No vote.


Wait, I take that back.  I haven't been in a math class for 25+ years 
now.  :)  I vote yes on one-letter words, IFF those words are a, 
A and I.

write my own non-modal ones
 ... what do you do about drop-list and edit-list then?

if those words are a, A and I
 ... is that an [English] language assumption?

Correct.  Damn Canadians  :)  I should know the French words as well. 
 J, J'

Am I ever glad there are more thorough people in the REBOL community 
than your's truly.  I'll shut up now, and then try and figure out 
how much I weigh in kilograms.  :)

There's a particular combination of events that kills BEER.  I think 
it is mainly when you are in the callback phase of a BEER async function 
that using a modal requester causes problems.

as for request-progress - I propose the same usage as with Calendar! 
Not every time you want a dialog box, which is stupidly blocking 
your UI.

those who want to pop-up dialog-box, still can.

set-disable, set-enable - I welcome it. Some time ago I wrote disable-face, 
enable-face, which simply put transparent face with whatever effect 
block in front of widget you wanted to "disable". It did not block 
the keyboard, but Anton fixed it IIRC, and those two small functions 
are on rebol.org.

Those were handy, but I don't recommend that approach anymore. I 
now recommend that each widget have a "ghosted" flag. Depending on 
whether the flag is set, the widget draws itself differently and 
also responds differently to events.

It's more work, but only the widget really knows how to do these 
things properly.

Agreed, but it's not high on my list of things to do.

Ashely - as you mentioned "to do", what is your prioritisation towards 
RebGUI? Just curious ...

Like RebDB and the SQLite Driver I want to get it to the point where 
"it just works", and fixes/enhancements are rarely required. Currently 
it does most of what *I* need it to do, so I'm focusing on nailing 
the few remaining bugs and getting the documentation up to scratch 
for a 1.0 release. I'm envisaging a lot of changes once R3 is released 
so this won't happen until after that.

Is the tree widget review part of the equation?

as for R3 - we don't know for sure, but maybe View will not contain 
any significant changes. My opinion is, that VID and desktop should 
be separate packages, and that View should contain only general gfx 
functionality ...

A simple tree widget, suitable for request-dir, is in development.


I hope that R3 splits VID off as an optional dialect (much like the 
SDK already does), leaving View as the raw graphics engine to which 
many domain specific dialects can be written (e.g. an animation dialect, 
a gaming dialect, an HTML dialect, etc).


I'm hoping R3 introduces at least these View changes at a minimum:

	Rich Text Support

 Different face types (e.g. min-face, text-face, draw-face, image-face, 
 etc)

 Fixes the long-standing detect face bug (or defines the current behaviour 
 as being correct)

Different face types

 - who knows, maybe that is what GOB (graphics object) is supposed 
 to be for ...

I wonder what does it mean "simple" tree widget :-) it will not be 
full-blown tree? Will automatic scroll bars, hilite, keyboard navigation 
as in OS? I will ask Cyphre if he was successfull in extracting tree 
widget from drop-tree ...

nice thing about RebGUI is, that styles are self-contained. Anyone 
can create new. I am with Anton here towards widget containing each 
its own implementation (method) of particular functionality, e.g. 
already mentioned set-disable, set-enable, as each widget (its author) 
knows best, how to implement it for the particular widget.

Build #83 Released. For more information see:

	http://www.dobeash.com/RebGUI/release.html#section-8

and:

	http://www.dobeash.com/RebGUI/user-guide.html

Includes changes from builds 73-83, plus new dictionary files.

Wow impressive documentation

in request-spellchecker/next-word .. is this clearer removing the 
double negative ?

		if all [ init word ][
				;	update dialog
				txt/text: fld/text: word
				show [txt fld]
				insert clear lst/data edit/lookup-word word lst/redraw
				;	hilight word
				view*/focal-face: face
				view*/caret: none
				edit/hilight-text start end
				show face		
		]
		none? word

oops .. last line should be 

word? word

If I resize a window containing a chat widget, it corrupts the widget. 
 Can I link to the resize event to do a show on the chat widget?

You're on the right track. Code can be refactored as:

			unless any [
				empty? word
				find ignore word
				...
			]
			...
		]
		if all [none? init word] [
			...
		]
		string? word
	]
	if next-word/init [

If you look at the source code for chat.r you'll see a commented 
out show face/pane/1 and show pane/1. Uncommenting either of these 
will fix all display problems for chat, BUT, subsequent widgets will 
not render correctly as the show "eats" subsequent resize events. 
You can see this with the following code:

	display "" [
		after 1
		button "One"
		chat #HW data ["a" none "b" none 1-Mar-2007/10:00:00]
		button "Two"
	]

where button 2 is not drawn correctly.

Build #85 uploaded with above spellcheck changes and an improved 
anagram algorithm (about 10 times faster).

I'm having problems with tables.  the new table appears in some instances 
to lock up my entire application.

An error has occurred.  If this occurred with an upgrade, please 
revert to the older version for the meantime, and report the error 
message as documented below.

make object! [
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'clear
    arg2: 'series
    arg3: [series! port! bitset! none!]
    near: [clear f/text 
        all [f/type = 'area f/para/scroll: 0x0 f/pane/data: 0] 
        f/line-list:
    ]
    where: 'clear-text
]

It's occuring only on edit-list widget where there is some text displayed

the new table appears

 ... tables aren't new, there're one of the widgets I have yet to 
 code review (although I have made some face-iterator changes which 
 handle row selection and on-click actions).


clear-text is not used by anything in the base distribution. Looks 
like something is doing a 'clear-text without providing a face argument.

>> display "" [ el: edit-list data [ "1" "2" ] button "Set" [ el/text: 
1 show el ] button "clear" [ clear-text el
]] do-events

** Script Error: clear expected series argument of type: series port 
bitset none
** Where: clear-text
** Near: clear f/text
all [f/type = 'area f/para/scroll: 0x0 f/pane/data: 0]
f/line-list:

Looks like I set it to integer and it displays okay, but then clear-text 
fails

So, in clear-text, changing clear f/text to f/text: copy "" fixes 
the problem

I guess the point is that one should always use the accessors

Assigning a non-string value to face/text is not a good practice. 
It just means more work for View (which has to dynamically form the 
value) and might break several things that depend on face/text being 
none! or string!

otoh, it makes less work for users not to have to form dates and 
numbers being displaying them in widgets

and let the accessor do the job

Looking at my code, it's a form that loads the data from a database, 
and then uses a routine to go through all the widgets and set the 
data.  Just need to add a 'form to it.

it is curious how each of us think differently about priorities. 
E.g. dictionaries - I never thought I could use them in my db "apps". 
Are you guys really using the features so much?