AltME groups: search

Robert, why would anyone store radio-group text when they could store 
the selection number directly? (e.g. radio-group/picked). This makes 
it very easy to save and load radio-group settings and you don't 
have to worry about label text changes. If the position of the option 
changes you just have to update the underlying DB but that applies 
for plenty of other widgets; if you change the order of your table 
columns, or check boxes, or widgets within a display. I don't see 
why this one case (radio-group) is so different from all others. 
It still won't protect you in the case where the number of radio-group 
options is reduced; and you now have to manage ID changes in addition 
to potential label and positional changes ... i.e. it adds another 
level of abstraction and another level of potential error.

Just a suggestion about the spellchecker.  At present the spellchecker 
window pops up for each word. How about the sentence in question 
is displayed in the spellchecker window with the word highlighted 
instead.

Graham: Normally a RADIO-GROUP selection is a mandatory choice. Otherwise 
you should use CHECK-GROUP which explicitly supports "no-selection" 
possibility. Hence a default selection was added.

sometimes a question needs to be left unanswered .. hence nothing 
selected.

hmm, but that is how radio buttons were meant to be - always just 
one answer. If you need something like that, I am not sure it is 
good design to have no radio button in a group having selected, because 
you can't do reverse operation - once you click on either option, 
you can't get back to state, where no radio group is selected. So 
- my opinion is, that in such case you should add another option 
to your group, stating "none" or something like that. Well, just 
my opinion ...

Isn't CHOICE-GROUP intended for selections that are optional? I use 
RADIO-GROUP for a mandatory selection and hence a default selection 
makes sense.

Well, I think that there should be some debate before a long standing 
behaviour is changed.  I have lots of users using a rebgui application 
that depends upon the previous behaviour.

Maxim - your glayout looks consistent, as buttons fit the rest. Current 
RebGUI buttons are a bit ... ehm, strange ...

there's a version of svn for OSX

pity I can't make a screenshot ... will do so at home ...

oh well, a pity I don't know how to use SVN so I can rescue you from 
unesthetical despair. :-)

it would be logical with a "Make Zip archive and download" button 
on the front page of that file list...

well, not complete, anyway. Maxim uses a derivative of that design 
in his system

I like buttons with a realistic look that make you say "oh, that's 
a metallic paint" or other surface treating process

is there a difference between how INIT works in RebGUI and INIT in 
VID?

I can't get my INIT function to work in a rebface

whoops, had the INIT function stuck inside a FEEL. :-)

http://rebol.hmkdesign.dk/rebgui-btns.png<--- well, it's a start.

I am not just proponent of "full colors". If I say - button red, 
I don't really mean "full red" :-) I like a bit more mild coloring 
...

yes. OTOH, you have full control over the button color. VID standard 
BTN does some contrast reduction, so a red button appears pale red.

with a more consistent look, the buttons will appear even better.

pekr, I mean that buttons that look really good in one context may 
look like crap in a diffferent context. The buttons look overall 
rather bland against the cream colored background. A darker gray 
would emphasize the buttons more. It all distracts the balance of 
the look if the colors are disjointed and obscure certain features 
in the buttons.

yes, it's harder to do nice looking buttons against a bright background.

INIT is a little odd here. It seems to be set to NONE after the face 
has been initialized.

this is not a part of the official distribution or the SVN repository.

I'll do one at a time and have you review it

I see your bug and raise you one fix. :-) (I think it's a poker term)

early field.r uploaded. have to go out for a bit...

field.r improved a bit.

field.r updated again. working a bit on password now.

its funny cause through all those years of working on glayout, I 
never really took the time work on the actual aesthetics, that was 
not the point of GLayout... and since its built over VID... well 
we can effectively rework all and reuse most VID styles.


  somehow, I find, with the looks derived from henrik's previous tests, 
  where very close to what I would have done myself (hehe henrik and 
  I have to meet at devcon... I think we'd have much in common) Glayout 
  has found itself a simple yet elegant look.  The latest version have 
  started to work a bit more towards looks, and now the highlight is 
  used throughout, so one can change one line and switch  the default 
  golden color to anyone... I'm trying out grey blue these days.

sorry to cut in... but you where all talking about a subject I like 
so much.  I wish I had more time to make GLayout flashy... alas, 
like Anton, I work more on the the actual featureset and api, allowing 
anyone a vast array of tools he can reuse in his styles...

Henrik - nice, although I don't understand what you are upto with 
fields/password-fields. The thing is a bit tricky. Overall, I started 
to like field with thin borders (not like ugly VID ones with border 
of 2x2, that is just so old-days)

field.r updated with a slightly better defined edge

ok, do you have a bright background? does it look better on a medium 
gray?

I also feel like doing a bitmapped theme. It's easier to do.

yes, overall I like the button. It is just that I agreed with you, 
that it should be probably a bit taller :-)

button is now a bit deeper than before causing visual problems.

I like Henrik's buttons better, maybe just coloring could be a bit 
more "mild"(?), so that blue is not actually so much blue etc. :-)

Pekr, that's a bit of a dilemma, since tour.r just makes example 
buttons. If you want to create esthetically pleasing buttons, don't 
use primary colors. The point is really that you can if you want 
to. I don't personally really like that you are not able to create 
buttons in exactly the color you want with BTN in VID.

not being able to use exactly the color you want, could cause problems 
if you are trying to match a specific color in the background of 
your GUI.

Agree fully with the color argument, if I say red I mean red. If 
I want a lighter red then I can always write code like:

	button (red + 0.0.0.128)

what do you think of Henrik's buttons/fields

 Buttons are a definite improvement over mine. Fields (and related 
 widgets like area, drop-list, password, etc) get interesting. Let 
 me start by saying that button is by definition a "graphically intensive" 
 widget. The basic view facets (text, edge, effect (non-draw)) only 
 let you do so much so to get buttons that look reasonable you have 
 to go down either the bitmap/effect or draw paths. Fine, I accept 
 that.


Field, and it's related widgets, are mostly textual and you can achieve 
reasonable results using standard text, edge, para and maybe a basic 
effect such as gradient. You can do all this in a dozen lines of 
code. Adding fancy draw effects, and ensuring that they scale as 
the widget is resized, adds significantly to code size/complexity 
and adds another feel over and above the basic edit/feel.


Now, you can be in the aesthetic camp on this one or the KISS camp. 
Does the current field look so bad it warrants such as massive structural 
overhaul? I think not. By all means come up with a better color combination, 
and use simple effects such as gradient that don't rely on setting 
and maintaining draw object sizes.


A few comments suggested that making changes with the current WinXP 
backdrop colors is problematic ... don't use them. If major aesthetic 
improvements require that a different default color set be used then 
design to that and if it all hangs together that will become the 
new default. I'm very open on this.


Another thing I have been thinking on is Window color and Widget 
color. Do we need the later? Another way to handle this (having a 
grouping widget such as tab-panel appear with a color different to 
the window it appears on) is to darken a grouping widget relative 
to its parent. This would allow nested grouping widgets (e.g. tab-panel 
within a tab-panel) to have visually distinctive colors, something 
the current implementation does not handle.

I haven't delved to deep.  The last cut of RebGUI I pulled out of 
svn causes a segmentation fault on my Debian Etch RC1 system.

>> do %tour.r
Script: "RebGUI widget tour" (16-Feb-2007)
Script: "RebGUI system" (18-Feb-2007)
>> q
Segmentation fault
[blue-:-dev]:~/gui/rebgui$

Note I did nothing other than start tour, and close it

REBOL/View 1.3.2.4.2 16-Mar-2006 Core 2.6.3

[blue-:-dev]:~$ uname -a

Linux dev 2.6.18-4-686 #1 SMP Wed Feb 21 16:06:54 UTC 2007 i686 GNU/Linux

Just so ya know.

Try:

	do %rebgui-ctx.r

then a simple display:

	display "test" [text "Here"]
	do-events

build#60 committed to SVN. Added Henrik's button widget with 2 minor 
modifications:

	1) Over color defaults to colors/over
	2) All of init inlined into the effect facet


The first change is self-explanatory, the second follows the principle 
that init should do as little as possible (facet code is evaluated 
once while init code is evaluated every time the widget is used). 
This change has one subtle side-effect, the "Refresh Display" button 
of %tour.r no longer works for all widgets (button in particular). 
This will be fixed in a future build.


One thing to note about the new button widget is its default size: 
15x6 instead of 15x5 units. This should not be a problem for most 
buttons, but may have spacing/alignment issues for inline buttons.


Note that the button change necessitated a small change to request-date 
which is now working again.

They'll be fixed when the RAMBO detect face bug referred to previously 
is fixed. In lieu of that I made two changes:


 1) Optimized tooltip checking (saves about 5-10% CPU in the case 
 of tour.r)
	2) Tooltips now default to off


I'd like to know how they seem to work for Robert as the code was 
a 100% cut & paste job from his. I suspect the key is to run it under 
windows and ensure that not only is Task Manager up but that the 
RebGUI app (tour.r in this case) is in the foreground. I noticed 
that clicking between a running tour.r and Task Manager (with tooltips 
on) makes a big difference between the reported CPU usage. Perhaps 
Robert is only seeing the later (or is running it on hardware that 
obscures the problem ... I'm on an old Pentium M 1.1GHz here).

can you provide a small demo of your rebgui with tooltips like this?

Simplest way is, log into XPEER and take a look at D:\rebol\link\xpeers\users\cyphre\tooltip-test

To use our latest RebGUI version, just create a distirbution from 
projects/rebgui and use this rebgui.r file instead of the one included 
in the test directory.

Could you please run %tour.r against your version of rebgui.r and 
report the CPU usage? I suspect the problem relates to the number 
and depth of widgets within a display. %tour.r is an extremely complex 
single display app in that regards.

Furthermore, don't make me click on the little tiny arrow to the 
right of the edit box before you pop up the combo: let me click anywhere 
on the combo box. This expands the click target about tenfold and 
makes it that much easier to acquire the target with the mouse pointer.

http://www.joelonsoftware.com/uibook/fog0000000249.html

Is this a reasonable thing to try ?

Anyone have an example of how the drop-tree works?  This brings up 
a drop tree but can't figure out how it is supposed to work yet


display "drop tree test" [ drop-tree data [ "root" [ "item1" [ 1 
2 3 ] "item2" [ 4 5 6 ] "item3" [ 7 8 9 ] ]] [ pri
nt face/text ] box 40x60 ] do-events

What's the "standard" keystoke(s) to make a drop-list appear? Down 
arrow?

on a Windows OS I thought it was the Alt-Down Arrow

radio-group: Ok, we are going to give our version a new name. As 
I still think, our approach is much more advanced WRT code maintenance 
and flexiblity. So, we have the choice.

Gregg: drop-tree works like a menu system.

display "drop tree test" [
	drop-tree data [
		"root" [
			"item1" [ item-1-action-code]
			"item2" [ item-2-action-code]
			"item3" [ ]
		 ][root-action-code]
	]
]

That's it.

Robert, did you get a chance to do the tool-tip test with tour.r 
against your version of rebgui.r? If so, what was the CPU reading 
and what value did you have for tool-tip-delay? As I mentioned before, 
I think tool-tips are dying on 'find-face when the display is sufficiently 
"complex".

I think we drift to far away

 ... depends on the extent to which you have changed/enhanced core 
 RebGUI functionality (e.g. rebgui-*.r scripts). If most of your changes 
 are isolated to new/enhanced widgets then there is really no drift; 
 you can plug your widgets into the standard RebGUI engine and it 
 will all work. If you want to keep your changes in sync then I suggest 
 2 simple practices:


 1) If you need a version of a standard widget (e.g. radio-group) 
 to do things that are app or design philosophy specific then create 
 your own widget instance and suffix it with an identifier, say XP 
 for XPeers in your case (e.g. radio-groupXP). Suffixes are preferred 
 over prefixes as the alphabetical sort order of the widgets determines 
 their load order which may affect dependencies ... see text.r and 
 label.r for examples of this.


 2) Only keep and maintain a divergent Widgets directory ensuring 
 that your widgets continue to work with the standard RebGUI engine 
 (i.e. rebgui-*.r scripts). If you need the base engine enhanced (e.g. 
 to support tool-tips or proportional resizing) then let's isolate 
 those changes and get them into the base distribution.


You should be able to create and maintain your own widgets without 
worrying about divergence as most of the design effort should be 
going into the functionality of the widget(s) themselves. If your 
widget needs specific changes/enhancements to the base engine then 
we need to sync those changes at the point you need them. Trying 
to retrofit these after the event, and after multiple divergent engine 
changes, is going to cause problems as you've discovered.


From my end, the 3 major changes you should probably try and work 
back into your fork are:

	1) UI settings: mostly confined to rebgui-ctx.r

 2) rebind func added to all widgets prior to init and rebgui-widgets.r 
 enhanced

 3) tab-panel rewritten to operate significantly more efficiently 
 (tab-panel.r and associated rebgui-edit.r changes)

A word on my design philosophy, which might help determine whether 
you can live with the standard widgets or not.


I like widgets that are small, efficient and satisfy the majority 
usage case. I want to be able to look at a widget I or someone-else 
wrote and "grok" it quickly. When I rewrite a widget I'd like to 
make it simpler and more efficient. Let's look at tab-panel as a 
case in point. It now does everything I'd reasonably expect it to 
do:

	1) Multiple tabs
	2) Auto label size determination
	3) Automatic widget size and resize
	4) Supports Tab actions

 5) Options to start with another tab selected and fire the initial 
 action


The code is simple, clean, efficient and weighs in at just over a 
hundred lines. I can look at it and "grok" it in a couple of seconds. 
But there are many additional things it could do:

	1) Ability to add/remove tabs at runtime
	2) Ability to rename/reorder tabs
	3) Handle case where tabs > available display width


But you get diminishing returns when you implement functionality 
to support these operations as they don't constitute the major usage 
case, and you can code most of them at the app layer by treating 
the tab-panel data block as a block of data that you can manipulate 
and display (via an unview/redisplay sequence).


But what about the third point, where the tabs don't fit? Isn't that 
a problem? No, that's an app design issue. It's no different from:

	display "Test" [
		text 10 "Some long text that doesn't fit"
		radio-group 20x5 data ["Option 1" "Option 2"]
		drop-list 15 data ["Some long text that doesn't fit"]
	] 


You have to allocate sufficient space for your widgets to render 
correctly. If you need to render volumes of data that won't fit then 
use area or a list type widget (e.g. text-list, drop-list, table, 
grid, etc).


My aim is to progressively review and rewrite each widget to conform 
to the above design philosophy, starting with the simpler widgets 
and leaving the more complex ones till last. I'm about half way through 
at present.

Tour: Sorry guys for being late with this test. After making some 
minor modifications to get tour.r to run with our version and adding 
a TOOLTIP to the password page "Some Text" field I can say that I 
don't see any CPU usage.

forking: Ok, adding specific version of widgets is OK for me. Even 
we really should avoid this. But anyway, I seem to be the only one 
seeing a problem with the standard radio-group thing.

We take a look at the three major changes you have mentioned.

And my philosophi lies between Ashley and Petr. I'm in more favour 
to spend time designing simple widgets that have a hughe feature 
set. Because than, my app development times are reduced radically. 
Hence, thinking once at the widget level, saves you factors of time 
on the  application level.

Still having problems with tooltips. I've cut & paste your tool-tip 
code from XPeers and I still get 60%+ CPU use with tour.r. Where 
can I grab a copy of your rebgui.r that you tested with?

Is there a suitable widget that can simulate the messages list here? 
 I built one before for Vid based upon DideC's code ...

Isn't Ashley making a Chat widget?

I've got a few scripts that live in the several hundred kbs... in 
fact GLayout now weights in at 180k (far too much of that being comments 
and history ;-)

Ashely, Gabriele and Romano did a RTF style

problems with tooltips

 ... note that since 11-Mar these and other problems have been solved 
 in the latest RebGUI Beta 2 builds.

Isn't Ashley making a Chat widget?

 ... chat, icon (SVG) and a simple tree widget (suitable for request-dir) 
 are in development.

RTF Style ... possible to use it in Rebgui

 ... RebGUI had this initially, but it was more trouble than it was 
 worth IMHO as (a year and a half ago) TMD (Text Markup Dialect) was 
 going to make it redundant. I believe R3 includes rich-text support.

http: ...

 ... I based my %render-rich-text2.r on this code but improved upon 
 it dramatically as we (shadwolf and I) were trying to use it to render 
 MD2 and MDP documents. Remember all the MDViewer and MDP-VIewer stuff 
 that was floating around a while back? ;)

Ashley, you will find it in the RebGUI directory on xpeers. That's 
the code base we use. Just log in, and take a look at projects/rebgui. 
That's our distribution.

I was on xpeers recently .. didn't see a rebgui directory.

Now I have hundreds of these requesters coming up 


The file framework/libraries/gui.r was modified locally and a new 
version from the server is available. Do you want to create a backup-copy 
of the local file?

Just say no, normally it's stopping after a couple of files. Or disable 
the requester in the options (IIRC it can be configured).

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

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.

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

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.

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.

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?

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

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

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.

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 
 :)

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 ?

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.

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.

As RebGUI is aproaching 1.0 release, I would like to know your opinion 
on following - how do you construct and optimise your GUI? So far, 
if you look at tour.r, it reminds me of one big dialog configuration 
box. Not sure what to do about it, maybe it is a given, as widgets 
we have do suggest such layouting. This debate could open discussion 
about eventual addition of potentially missing widgets. My questions 
are:


- are you missing kind of MDI application scheme? Parent window, 
containing one or more child windows, which are not able to being 
moved away from its parent. We used that design much, but I am not 
sure anymore it is vital, as with latest system, we use two monitor 
set-up, and by simple accelerator key we can navigate window being 
moved between displays. Having MDI available, we would probably need 
rebol/view native windowing system. So - is anyone missing something 
like that?


- do you somehow optimise your display? Isn't it like following? 
- with using tabs, everything is in memory, whereas it eventually 
is not needed? How do you divide your application, if you would like 
to have kind of load-on-demand aproach?


What styles do we miss, to further help us have more complete GUIs? 
I created screenshot of potentially two usefull widgets:

http://www.xidys.com/widget-drop-tab.jpg
http://www.xidys.com/widget-vertical-tab.jpg


Especially with the second one, I think it could be usefull. It is 
used by many applications. It is kind of mixture of tab and tree, 
but not necessarily with multi-level aproach, just one level of nesting, 
mostly represented by icons, text, or icons plus text. I would like 
to know your opinion.

Pekr; If this is an open question, and not just to Ashley,


I use what I'm given.  In that I build apps (not many so far) using 
the toolkits I see in front of me.  I'll definitely retrofit my existing 
Fire and Rescue Management app with a Menu once the flurry of RebGUI 
development slows down a bit (and please don't slow down, love the 
flurry).


Unless my systems crash, I spend zero time optimizing, wait I take 
that back, I try and follow my own style guides while I'm writing. 
 There is the odd backtrack to get a tab panel to line up nicely 
inside another.  Other than fixing glaring visual ugliness, no optimizing.


I design with a 'small town business model'.  I hand deliver applications.


If I go and snag a feature that goes quirky during my initial testing, 
I dump the widget and look for another.  My 0.4.0 build of RebGUI 
had sticky persistent drop-list's so I used labels and a special 
requestor.  I'm not sure I'll retrofit these.


The easier things are out of the box for me, the happier.  Give me 
the tool, describe how it works and I'm satisfied (when it's as elegant 
as REBOL, RebGUI and RebDB).

Understand, I like the "real estate handling" part of such a widget.
Is it http://trac.geekisp.com/rebgui/?

Build 75 uploaded to SVN. Fixes some problems introduced in build#74 
and improves widget documentation. See here for a complete list: 
http://www.dobeash.com/RebGUI/widgets.htmland also the updated %tour.r 
Widget and Function Ref tabs.