World: r3wp

you will find it in the RebGUI directory on xpeers

 ... got it the first time, just making sure I was looking at the 
 most current version. FYI, tooltips had me baffled for a long time 
 (they worked for you, consumed tons of CPU for me) until I realized 
 they were only a problem with the new tab-panel implementation ... 
 which now stores all tabs in a pane and uses the show? attribute 
 to work out which one is visible or not (the original stored hidden 
 tabs in a data block). The fix was simple, change the tooltip code 
 to ignore faces with show?: false.

strip tree widget from drop-tree

 ... the tree widget I'm working on is similar to text-list but with 
 leading triangles (indented by level) that toggle between sideways 
 (close leaf) and down (open leaf). Not sure whether Cyphre's one 
 is based on the same [simple] concept.

Can we somehow align while you do RebGUI 2?

 ... as discussed previously (see post from 10-Mar), with the key 
 points being:


 1) Use (and possible extension) of global UI settings (colors, sizes, 
 effects, behaviors) in %rebgui-ctx.r

 2) Widgets should define a 'rebind func if they need to change a 
 statically bound UI setting (e.g. color)
	3) Use the new tab-panel widget

and a fourth:


 4) Layout uses 'tip (not 'tooltip) to specify the widget's tip string!


Note that the current build has had most widget-specific exceptions 
removed, especially from %rebgui-edit.r; and that /dialog (hence 
popup) code has been rewritten to support true modal dialogs (that 
can in turn call additional modal dialogs). The later improvements 
are courtesy of recent REBOL/VIew popup changes.

I'm looking at adding a simple format mask attribute to RebGUI for 
editable widgets such as field, area, edit-list and drop-list. Basic 
idea is that if a bitset! exists in the spec it is assigned to a 
new 'mask attribute which is checked prior to every keystroke that 
would insert a char into the text attribute. This would allow specifications 
such as:

	display "Test" [
		field (charset [#"0" - #"9"])
		field digits
		area no-special-chars
		field phone-chars
	]


and has the advantage that the code resides within the RebGUI edit 
feel and can be used by any editable widget. Specification, as above, 
is also natural as bitset! is not mapped to any other attribute and 
is a natural mapping for character edit masks.


If an invalid char is encountered then the keystroke will be discarded 
and perhaps the field can blink or flash as a visual cue?


I'm also toying with adding a datatype! attribute to the spec which 
would be used like:

	display "Test" [
		field digits integer!
		field digits-and-seperators date!
	]


and create an on-unfocus trigger that tries to "set-text self form 
to-datatype" and blanks or blinks the field on failure (and prevents 
leaving the field).


Need to nut out exactly how this would work, but the question is, 
is this useful for folks; or is it more trouble than it's worth (given 
that it is not a fully fledged edit mask solution).

ashley, maybe you can find some inspiration in this: http://www.hmkdesign.dk/rebol/vid/docs/vid-field.html

spelling: "sep*a*rators"

It's a good idea - except the flashing and blinking should not be 
default. I think that is only necessary for specific cases.

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.