World: r3wp

Well, how do you provide a fully fledged edit mask solution ? Since 
folks could implement it many custom ways, I would provide a callback 
function when key input events are received. The user's callback 
function return value can indicate whether the key should be accepted 
or not. (it could return the character that should be inserted or 
none!)

When a bitset is provided, then the callback is set to a bitset masking 
function.

Build#73 committed to SVN. Mainly code reorganization with functions 
split off into separate scripts in a new functions directory and 
%rebgui.r preserving carriage returns so 'source works and it can 
be edited & viewed more easily. Increased code size by 8 Kb.

I want date masks, tel. number masks, where e.g. date format dots 
can't be deleted, automatically are skipped, etc. Everything else 
is - underpowered :-)

Great. Define a spec that everyone is happy with and I'll implement 
it.

I like the old dbase style of formatting.

where you can specify capitals, numerics, non editable chars etc.

I spent a lot of time working on that kind of thing for VB, and also 
used some commercial VBX/OCX packages that included them. Our target 
audience was data entry operators in call centers and, while this 
is what the internal analysts and user contacts said was what they 
wanted, the actual users hated it; it just got in their way. Asking 
around informally, I found that most users didn't care for them, 
while techies thought it was a great idea.

My layman's analysis is that, since there is no standard about how 
these things should work, you, as a user, have *no idea* how to predict 
what's going to happen when you hit a key (accept, skip, beep, autofill 
and move to next field, etc.). I think there is also overhead in 
thinking actively, and looking at the screen, to determine what the 
format is, and what you need to *not* type in order to make it happy.

in other words, there is no universal user model

So, the user needs a strong visual clue to show that a character 
is uneditable - perhaps even so much as to make it look like not 
part of the field.

Ashley; Thanks for the newlines.  Well worth the 8K.

Looking at how the rebface object has evolved I note we now have:

	action
	alt-action
	dbl-action
	focus-action
	unfocus-action


and possibly a new keystroke-action. To restore some sanity to this 
(one attribute for each possible type of action), I propose that 
action become a block of the following structure:

	action: make object! [
		on-click:
		on-alt-click:
		on-dbl-click:
		on-focus:
		on-unfocus:
		on-keystroke: none
	]

the on- prefix is deliberate so:


 a) You can read each entry as "action on such-and-such happening"

 b) there is no inadvertent mix-up with underlying functions such 
 as 'unfocus


Note that this change only effects the internal representation of 
actions, it will not change the layout specification (i.e. it will 
not require app script changes).

Comments? Names OK? Any additional actions we need to handle?

on-over:
on-out:
Mose movement without  the focus

Mose=Mouse

Looks good.  I've not delved deep enough, this may be redundant. 
 Do faces handle scroll events or is that just at the window level?

Just at the window level (with some hard-coded exceptions for slider 
and spinner). An 'on-scroll action is probably a good addition.

on-over and on-away are also probably useful (they can be coded in 
the feel object, but this is tough for widgets like button with an 
existing feel definition). Another good addition.

Ashley, This API reminds me of Hypercard.

Thanks Ashley.
I'm hoping to have screenshots of the FirM app up soon.

This API reminds me of Hypercard
 ... is this a good thing or a bad thing? ;)

I'm liking the new %tour.r Ashley.  The font selector works great 
on this Debian box...Thankees.

What font names look good? List them here and I'll add them to the 
default ones.


Note that as the new ctx-rebgui/font? function filters out fonts 
not available on the machine running RebGUI we can build up a superset 
of default font names for the big three: Win, Max and *nix.

Oh, your defaults.  monspace and serif, everything but courier on 
this box.

I'll do some more investigating and get back to you here.  Thanks 
again.

Ashley;  Well I'm more confused than when I started.  I got sick 
of bad Courier and fixed it.  It had to do with the order of 100dpi 
and 75dpi font lists and removing ghostscript font mapping.  Anyway, 
now REBOL/View can't find Serif, Sans Serif or Monospace.  The "real" 
names "DejaVu Serif", "DejaVu Sans", and "DejaVu Sans Mono" work 
in font [name: ] blocks.  So, I can't help much yet.

The short list (and I'll need to look into this more)  is
DejaVu Sans Mono
  for a good font-fixed
DejaVu Serif
 for a good font-serif
DejaVu Sans
 for a good font-sans-serif
These names may be very specific to my setup...not sure yet.


These fonts should map to "Monospace" "Serif" "Sans Serif", which 
I just broke.


And after I mucked around   the stock font names, which on this REBOL/View 
 2.7.5.4.2 18-Mar map to

font-fixed = "courier"  font-serif = "times"  and font-sans-serif 
= "helvetica", all look way better now.


Maybe I'll just let you get on with it, and quit mudding the waters 
 :)

FYI, View sets its fonts in %gfx-objects.r (part of the SDK) with 
the following code:

set [font-serif font-sans-serif font-fixed] any [
	select [
		1 ["CGTimes" "CGTriumvirate" "LetterGothic"]
		2 ["times" "arial" "courier new"]
		3 ["times" "arial" "courier new"]
		5 ["baskerville" "zurich" "courier10 bt"]
	] system/version/4
	["times" "helvetica" "courier"]
]

With my config  (Mandriva 2007) fonts selector opens behind "user 
interface" window

RebGUI2: Cyphre and I will take a look.

format attributes: Using the DBase approach is IMO good. A lot of 
people still know it and IIRC it was pretty complete.

actions: We have added a RESET-ACTION. With this I can call something 
like my-form-gui/reset and it will reset all contained widgets to 
some default values. IMO a must have and keeps default values etc. 
near the widget, the source of information.

The ON-* convention has been used in a number of frameworks. It should 
be familiar to a lot of people.

Any way to selectively change the row colors on a table ?

for the text and not the highlight

This is to indicate new messages in a forum

fonts selector opens behind 

user interface" window" ... odd, does the same thing happen with 
color selectors from the same window? What happens when using the 
various requestors from %tour.r? What View version are you on? Anyone 
esle ever seen anything like this?

DBase approach is IMO good.

 ... Is there a concise reference somewhere online I can work off?

Any way to selectively change the row colors on a table?
 Not at present.

REBOL/View 1.3.2.4.2 16-Mar-2006 Core 2.6.3
Same problem for color selectors 
Using the requestors from %tour.r is ok.
(with REBOL/View 2.7.5.4.2 18-Mar-2007, i have the same problem)

OK, so the problem is with popups that call popups. When the second 
requestor (font or color) is called does it *initially* appear behind 
the calling requestor, or are you saying that clicking on the calling 
reqestor *allows* the calling requestor to come to the foreground 
and obscure the second popup? (This later behaviour is what occurs 
on Win & Mac).


Secondly, is the second popup modal (i.e. after it appears can you 
still interact with the first popup)? On Win & Mac the popup is truly 
modal (apart from the windowing issue, which I think can be solved 
by use of the 'parent option).

Graham - why don't you use grid? Is it incompatible with current 
rebgui version? It is not as powerfull as Henrik's grid, but surely 
few light years ahead of table. You've got very simple usage help, 
but workable imo ...

Ashley, the second requestor appears between the calling requestor 
("user interface") and the main window ("tour") and i can't interact 
with the calling requestor ("user interface').

Grid ?  Never thought of it.

No examples of grid given ... and Ashley has marked it as needing 
more work.

Frank, could you please test this fix for me. Edit %rebgui.r and 
replace the following:

	either parent

with:

	either any [dialog parent]


This *should* force the popup to appear and remain on top. Thanks.

table/select-row is still missing the no-action refinement.  Is it 
not needed?

In my version I have it. IMO it's required.

I put it back into mine as well.

Ashley, it works fine, thx.  Back on thursday....

IMO it's required
 ... agreed. Added to both table and text-list.

Graham - IIRc I sent you very brief doc, which shows some usage. 
Even with such doc, you are able to have xy times better grid than 
table is. But - I have to check with Cyphre and I already asked him 
for upgrade, as his grid worked with his RebGUI version, and I would 
like to use official beta 2 definitely ....

Build 74 uploaded to SVN. Includes the following additions:

1) New action object used as follows:

	box "" red
		on-click		[
			print "click"

   system/view/focal-face: face	; required to pick up scroll events
			system/view/caret: face/text	; required to pick up key events
		]
		on-alt-click	[print "alt-click"]
		on-dbl-click	[print "dbl-click"]
		on-scroll		[print scroll]
		on-key			[print ["key" event/key]]
		on-over			[print "over"]
		on-away			[print "away"]
	;	on-focus		[print "focus"]
	;	on-unfocus		[print "unfocus"]

2) New layout keywords added as follows:

	text "Test" text-color blue
	text "Test" bold
	text "Test" italic
	text "Test" underline


3) New 'examine function added to provide detailed information about 
a widget:

	>> examine table

Also a number of fixes:

1) Multi-row Shift hilight selection fixed (pekr)
2) Dialog has parent option by default (Frank)
3) Keystrokes on a button no longer passed along (Graham)
4) request-password enhanced to allow following:

		request-password/check [if (length? text) < 6 ["Problem"]]

5) /scroll option removed from display

6) /min-length & /max-length refinements removed from request-password

7) /no-action option added to select-row function of table & text-list


WARNING: These changes are wide-reaching and have not been fully 
tested ... some things may have been broken. Full documentation in 
preparation.