World: r3wp

and can't use the mouse to take the caret elsewhere :(

what a life .. trapped in an edit-list!

I have edit-list in caret-on-focus

and I did a show-focus to get to the edit-list

Yep. Reproduced. Give me another 10 minutes on the upload. ;)

thanks

Uploaded build#81 to SVN. Includes the following changes:

	Fixed label & text auto-sizing (now defaults to -1x-1)
	Spinner now accepts an empty starting value
	hilight-on-focus now works again

 [edit-list field password spinner] are now hilight-on-focus (area 
 remains caret-on-focus)
	edit-list fix

Also updated:
	http://www.dobeash.com/RebGUI/widgets.html
	http://www.dobeash.com/RebGUI/functions.html

Ashley, View system has broken highlighting and caret positioning 
with center and right aligned text. It's been a problem for a long 
time.

Well, the problems I hit were all at the mezz level (focus) so easily 
fixed.

why table and text-list are not hilight on focus too?

Ah, because they don't get keyboard focus like area and field do. 
The fact that they are not tabbable [yet] is a separate issue.

How is getting the keyboard focus solved in widget? Via some method? 
What is new widget supposed to implement in order to support it?

I'm getting a 5 second delay on using the "close" button in the spell 
checker, or on the final "add".  I wonder if it's better to close 
the spell checker window down first and then do the file maintenance.

Sometimes you need to disable buttons etc, until an action has been 
completed.  Rather than redefining the action of the face, how about 
a putting a flag that signifies whether the action is active or not?

in request-spellcheck.r, what does this line do?

	;	do we have a string with > 1 char?
	any [not string? face/text 2 > length? face/text] [exit]

Checks that face/text is in fact a string and has a length greater 
than one char. We don't really want to spellcheck an empty string 
or one with a single character in it. Why, is it causing a problem?

How come you don't need an 'if in front of that?

getting a 5 second delay
 Got it. Hard to believe, but:

	write file form sort unique dict

is about a hundred times slower than:

	write file form dict


Sorting isn't so bad, but unique absolutely grinds it to a halt. 
Timings are:

parse		00:00.2
plus sort	00:00.8
plus unique	00:05

Isn't the dictionary already unique ?

Why check it again?

Doh! Thanks, that's now two errors I need to fix in spellcheck. Will 
upload fix in a few minutes.

Uploaded build#82 with above changes. Note also that the request-spellcheck 
function now has a /anagram refinement (don't ask).

:)

Do you have a utility for us to build our own dictionaries?  Or is 
it just a collection of unique words?

What do you think about my question on disabling the action block?

The dictionary files are just a collection of sorted unique space 
separated words (all on one line, no carriage returns). I extracted 
them from the latest Abiword dictionary files. No utility as such, 
but the trick to generating them in REBOL is to get a block of strings 
then do a:

	write %my-dict.dat form sort unique my-block-of-strings


As for the button disabling question, I thought it was specifically 
related to the spellcheck taking 5 seconds. But, more generally, 
I'm against that type of thing. Far better to pop up an alert or 
progress bar for actions that will take time. Pressing a button should 
provide *immediate* feedback or results.

Ok, how about ghosting a button then?

or other face ...

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