AltME groups: search

Anton, the cost of disk reads dwarfs the cost of LOAD/next. And PARSE 
is much slower at loading REBOL data than LOAD. You might consider 
finding out the max size of the value you are loading, rounded up 
to multiples of 4096 (disk blocks), and just READ/part a bit more 
than that from the disk for each file. Then LOAD/next from the resulting 
string. There is no reason to do speculative reads once you have 
an upper bound on the size you will need to read. In a language like 
REBOL, minimizing disk reads sometimes means minimizing the number 
of calls to READ, not just the amount read.

If you are reading from a hard drive there is no point to using a 
chunk size of less than 4096. For floppies, 512 will do.

Steeve, do you mean to say that it's impossible to get the last block 
without loading the complete file?

JoshF, if this script stands alone then I would make these changes:

- Add as locals to EMIT: WORD and LONG.

- Add to CLEAN-SCRIPT's locals: LINES, OUT, EMIT-SPACE, EMIT, BLK-RULE, 
VALUE
- Move into CLEAN-SCRIPT's body:
	1	lines: copy []
	2	The EMIT-SPACE function
	3	The EMIT function
- Change this line:
	out: append clear copy script newline 
to:
	out: copy ""

(There's no point copying the string SCRIPT when the next thing you 
do is CLEAR it.)
- Remove this line:
	remove lines/1

(There seems no point in initializing OUT with a single newline char 
if it is only to be removed ultimately.)


After, that, you should have only one word, CLEAN-SCRIPT, defined 
globally, referring to a function with no side-effects.

I couldn't figure out how to make DO work in Parse.  My answer here 
shows an example that I tried: http://stackoverflow.com/questions/3478589/rebol-parse-problem

Given your example, you wouldn't want to use DO anyhow since you 
would be creating a charset in a loop, creating a new charset for 
each iteration. It is better to create it once ahead of time.

how to set local vars in parse ?

rule: [ "text" (var: "local") ]

var: "global"

f: func [ /local var ] [parse "test" rule  return var ]


f  ; result = none  not "local"

what to do get  result = "local"

Actually, DO is really easy to simulate, both in R2 and R3.
Just construct the rule on the fly.
>> parse [2][(rule: do [1 + 1]) 1 1 rule]
==true

Is there a foundational reason for DO not being available for string 
parsing, or is it just not implemented?

There are a lot of things that you can do in block parsing that you 
can't in string parsing. In this case, the result of DO is compared 
directly as a REBOL value. Strings don't directly contain REBOL values 
the way that blocks do. Even if you tried to limit the result types 
of the expression and trigger an error if they don't match, what 
you are left with isn't useful enough to justify adding it, imo. 
For instance, in your example it was a bad idea to use DO. We'll 
see though.

Micha, there was a direct solution proposed for this in the parse 
proposals, specifically to deal with local variables in recursive 
parse rules. However, it turns out that PARSE isn't really recursive: 
It fakes it. So there was no way to support this feature in a parse 
directive. The best way to do the local variables is to put the PARSE 
call and the rules in a function, and if you have to use recursive 
rules, recursively call that function in an IF (...) operation. It 
really works well, in a roundabout sort of way.

The best way to do the local variables is to put the PARSE call and 
the rules in a function, and if you have to use recursive rules, 
recursively call that function in an IF (...) operation. It really 
works well, in a roundabout sort of way.
 - this is too much of a roundabout for most cases, I have to add

If I wanted to do it just in R2, it could have been simpler, but 
R3 is more picky about what it allows

I am glad you added your notes. I hope you do not mind me using your 
comments to make the code more understandable for others?

Brian, do you think, that a more "seamless" way how to do the above 
in parse shall be considered, or that this approach is good enough 
as it stands now?

ok, as for terminology, how do I refer to following:

start: copy user to "</user>" :end (temp: find blk user)


while the code is not real, I can see three different "variable types":

- start: :end markers
- user parse level variable?
- temp: rebol level word?

Thanks :-)

Sorry if you find it nitpicking, but I wanted to point out, that 
an assumption that "parse variables are safe for recursion rules" 
should be wrong exactly because there are only variables in REBOL, 
which the interpreter does not have any reason to make "recursion 
safe" unless you specifically do something about it.

i would like to use parse to do it

i would like to do => parse mystring [thru "Number :" number: to 
"Name    :" ] but this don't work !!!!]

claude... so, did you try to run it as a script?


one thing I would do... since this is a strange error is to retype 
this:

 " ^-"


in your editor... to make sure its not using the wrong ascii character 
on your os... it should not be a problem... but there is something 
weird going on here.

Ways to identify the problem:

- In AltME, copy Max's entire post which contains the code. You can 
do this with a right click when no text is selected in the message.

  Switch to the rebol console and type:   checksum read clipboard:// 
     and tell us what you get.

- Then you can also type:  print mold read clipboard://    and examine 
what is printed carefully.

- Try to reproduce the problem with shorter code and shorter input. 
Two lines of input should do.

how do you specify an element to be of the type any-type! except 
none! ?

also, Carl's clean-script and script colorizer use parse + load/next 
to do the same thing. my Wetan uses the same method.

in your case I would need to jump at least over each tag start, not 
using thru "<h5". But then there would be problem, that I need to 
stop the doc div only if it's exactly "^/ </div" (to avoid case that 
there would be another inner giv). I know it's not safe, but I can 
see what I do by examining the source I want to parse first. (240kB 
html in my case)

Aha, that "I can see what I do by examining..." looks substantial. 
Nevertheless, there is still a way how to do a similar thing without 
calling Parse again

I didn't say the reference was restored automaticly , you have to 
do it yourself.

Right now it is a stack of integers (position) and a single pointer 
(series reference). To do this it would need to be a stack of series 
references too, and the collector would need to be informed of its 
exdistence so it could scan it for references.

You have to DO an error explicitly to trigger it. Otherwise, you 
can just reference it directly as if it were an object.

I can do it now either way i need to understand the way R3 handle 
things

okay, i will do it then, but i will refer to you as the parent of 
the idea doing this like that ;)

I think the problem is something to do with the slider not being 
initialised correctly.

I ran download.r and it started up tour.r    ...was it supposed to 
do that?

There where to lines outcommented in %rebgui-edit.r . keeps caret 
visible now. (do not know if that has sideeffects.)

How do you get a face to come to the forefront? After I've "displayed" 
it and say, go and click on some other window, how do I get the initial 
face to pop back up. In my case, I have a table of data and when 
the user clicks it, I want to have a more detailed view of that line 
of data.

This is what i am doing to fill a form up from data

display "" [ r: radio-group 30 data [ "M" "F" ] return
button "Value" [ print r/data ]
do [	r/pane/2/feel/engage r/pane/2 'down none ]
] do-events

Only one layout needed as the compose would be within a func (i.e. 
dynamically built as opposed to static). nowrap option? Do you have 
a VID example, havn't used that VID option myself.

Just wondering if it would be useful to allow rebgui and vid to operate 
together.  So, you could do all the easy stuff that rebgui allows 
you to do, and when you needed something it couldn't do, then to 
use Vid instead.

I have not looked into RebGUI styles in detail yet, but what are 
the options to "skin" them? Or to do them (styles) in different colors 
etc.?

I think the interface mockup is outstanding. Was wondering what did 
you use to code it? I havent seen many applications that do not use 
the system scheme and still manage to look that sleek.

Congratulations 
and keep it up.

IMHO ppl are more turned on widgets,  general functionnallity, simplicity 
than on esthetical issues.  Ashley when do you plan to release  new 
widgets (tabpannel with scrollable header, menu, listview) i'm going 
to start working on treeview widget as usual how do you want data 
to be submitted to it  (data block structure fo ex: [ node_label1 
[ leaf1 leaf2 leaf3 subnode_label2[leaft1 leaf2] etc.. ]])?

that some kind of apps do not strictly need to keep OS metrics, as 
OS is then just a medium - irrelevant ...

Some time ago, I read article about icons, toolbars, and what is 
wrong with them. I have to say, I do prefer menus, really. I work 
in various environments, seeing tonnes of icons. Robert answered 
the trouble with icons for himself, maybe he even did not notice 
there is the trouble at all :-) Suggesting tooltips - that is the 
first obstacle with toolbars. Basic operations as printing etc. are 
self-explanatory. But! Go, start few apps, which allow you to hide 
menu - use icons only. You will get in troubles instantly, waiting 
for tooltips (=text representation) to explain you the meaining of 
the icon.

MichaelB: thanks for your thoughs, you think along the same lines 
as I do. Could you please show me an example of  "circle menus"? 
I am not sure I get the idea of how it is supposed to work ...

there is a master thesis or something about this I once read, I try 
to find it ... other than that there was one Rebol guy who tried 
to do it, but it was slow

what do you mean ? I don't understand. I almost forgot how I like 
these things. :-) Actually the fastest zooming I have seen - I know 
the piccolo toolkit a little bit, and I don't remember it to be that 
fast with so much text

and I would like to have a Rebol UI done the zooming way, but after 
my little tests I found it to be too slow for larger amount of data, 
especially text - but I thought about something similar but with 
steps, so no smooth zooming, this should be possible with Rebol

I guess so, Second LIfe has also pie menus. 

Graham: this didn't mean that there are other ways to use menus and 
of course depending on the input device there are better ways. If 
you have keyboard shortcuts for everything you can even be faster 
in doing things. If you have a scroll wheel zooming into is pretty 
natural as is paning with a extra button - but didn't anybody feel 
that in this zoomit demo one could surpisingly well use the interface 
and especially with what speed ? (just compared to putting the same 
functions to a traditional context menu)

Also one should just try to use mouse-gestures in Opera - after using 
them you always want to use them - even though I often out of habit 
do the same in IE or somewhere else and it doesn't work - the most 
important thing to note for me is that it's worth having an interface 
one can form habits in using it - only then usage will be very fast. 
If one puts the one or other stumbling block into it, it will never 
flow, you always have to concentrate on what you're actually doing. 
Just imagine driving a car and having always to think about how to 
steer or shift (for many of the european people :).

What I just wanted to point out is - those styles do look nice. However, 
they don't seem to reflect mouse-over effect. My question is, if 
we give-up on that. IIRC Chris pointed out, that you have to count 
with such things prior to starting your design. Also - what about 
reflecting in-focus styles? As we know, OS does count with it and 
reflects it visually, what about our Rebol UIs?

Is there a way to do menus in RebGUI?

How do I use the offset for a widget? Where to put it? I want to 
do the following:
wid1 50x50
return
wid2 50x50
return
wid3 50x50


and now I want to place the next widget right to wid1 and inline 
with wid1.

focus would look for a face/focus function while unfocus would look 
for a face/unfocus function. So the code might look like:

	...
	field unfocus-action [do-validation face/text]


the validation, if it failed, might shift focus back into the field 
the user tried to leave. Something like that I guess.

maybe that have somthing to do with the way  widget is updated

events: IMO a very, very important thing to add to RebGUI. Think 
about your apps. I always need this feature and most frameworks etc. 
don't support it well. The problem is, that if you have to add it 
yourself, the code becomes hughe and complicated for maintenance.

Adding a focus / unfocus action sounds like a good way to do it.

Hi. Just looking through rebgui. A question and a comment. (1) In 
the readme.txt file there is a reference to Opera icons but no reference 
to the licensing of those icons. Where can I find the icon licensing 
information please?

(2) I like the table widget with it's sortable columns. But at first 
had problems with trying to sort in the reverse direction because 
I was targetting the sort indicator triangle which does not do anything.

The close event of DISPLAY's default view-face/feel/detect assumes, 
after   face/alt-action face   has been done, that there is still 
a face in system/view/screen-face/pane.

This is a problem when I wanted the window close button to return 
me to the console, like so:
display/close "" [box 10x10][unview] do-events

rebol says it from begining  edge is not a good path  why  ?  /edge 
doesn"t exist ? where does it supose to exist ?  -> colors ...  yea 
colors/edge that match with what  rebol says  !!!  do i have colors 
 set  as a block of value in my  code  ?  yes  to able ppl to choose 
modify  the background colors ...

The idea with the on-* naming is to clearly indicate an event. I 
toyed with using just focus / unfocus but these verbs could be confused 
with the functions of the same name. Likewise, 'enter could be confused 
with the 'return keyword and 'exit has the same issue with regards 
to both 'exit and 'quit. 'on-enter and 'on-exit are possibilities 
though.


on-focus and on-unfocus return true or false so as you can handle 
failure. This scenario is more likely with on-unfocus where you would 
want to trap and handle a field validation failure for example.


The difference between on-unfocus and the usual action (both may 
be triggered by pressing enter for instance) is that on-unfocus enables 
you to interrupt the normal work-flow by aborting the unfocus and 
subsequent focus operation - something you could not [easily] do 
normally. Also, for many widgets the usual action and on-* actions 
may be different (e.g. pressing enter to initiate the default action 
may be quite different to pressing tab and leaving the field).


For those familiar with Oracle*Forms, and similar products, these 
new actions are like the pre-field and post-field triggers (with 
the app-level ones mapping to pre-form and post-form).

Good questions all, keep them coming.

>> change-dir %../
== %/D/rebol/rebgui/

>> do http://www.lexicon.net/antonr/rebol/rebgui/add-remove-tab-panels.r
connecting to: www.lexicon.net
Script: "add/remove tab-panels" (8-Dec-2005)

** Access Error: Cannot open /D/rebol/rebgui/programs/rebgui/rebgui.r
** Near: do view-root/../programs/rebgui/rebgui.r
relayout: has [fenetre-cannibalisee]

Tango: Very interesting stuff, and looks like these guys thought 
a lot about doing it right. I vote for using it for RebGUI. Frees 
us to do invent the wheel again.

I think Tango is nice, but I really much would appreciate or like 
to sea some standard way to add a textual description to icons, like 
often used nowadays. I know almost nobody will want to give up icons 
or graphical objects, but in order to make RebGUI as good as possible 
I think to add such a textual description by design would be very 
very good.

I think of something like another parameter to a button in which 
the label is placed. The UI could then offer a simple way to activate 
or deactivate the labels, the icons or have both, side by side or 
on top or below. 

This way we get the best of two worlds (only some space needed) - 
people can choose for themself and with the text it will be almost 
always clear what a button means.

Of course the could be done externally by adding a second row or 
column to every button, but this would separate what belongs together.
What do you guys - especially Ashley think ?

Anton you have to set do %rebgui.r instead of  do  /D/rebol/rebgui/programs/rebgui/rebgui.r

That file you can do in your application. rebservice-lib seems to 
use that, + compression.

You have luck, you are wrong :) (afaik). Releases use a global directory. 
only betas do not, you would not want to mix release-code and alphas, 
for example loading rebcode in the release-cache.

SAmple rebol code to check and get for script official plugins:
REBOL [

 "a project that use rebGUI"

]


check-plugin rebgui ; do a test if the rebgui package is installed 
on the rebol/view local install -> if not download it and install 
it

VID editing system is all not not natural ... the caret system is 
the most awfull thing i saw this far on rebol and that 's a pitty 
because it limitate so mutch inventivity (well in fact ... yes and 
not ...  i played a lot with caret sytem when i as working on MDP-GUI 
Some  hard things are relatively easy to make like flags insertion 
to born a sleected piece of text and some easy things are hard to 
do like keeping the selection on the selected text and not on the 
begin inserted flag ...)

VID editing system is all not not natural ... the caret system is 
the most awfull thing i saw this far on rebol and that 's a pitty 
because it limitate so mutch inventivity (well in fact ... yes and 
not ...  i played a lot with caret sytem when i as working on MDP-GUI 
Some  hard things are relatively easy to make like flags insertion 
to  enclose a sleected piece of text and some easy things are hard 
to do like keeping the selection on the selected text and not on 
the begin inserted flag ...)

Sorry, I wasn't referring to the actual RebGUI widget set, but implying 
that a general table widget should be able to handle any number of 
columns and rows. Such a widget would be used to do all the display 
work inside your chat client widget.

you can look at Detective libraries .... there is whole system to 
do automatic incremental updating, signed  code, etc. - nice ....

anton, what is the problem with checksum? It depends on syncing strategy, 
but you have those files on both side (client, server) anyway. afaik, 
the problem with checksum could be its speed. But since we have open/seek, 
we could do checksumming defined,e.g. 3 parts of files, first xy 
bytes, last xy bytes and defined skip somewhere to the middle of 
the file ... dunno if it would work though :-)

Decided to go with a simple manifest / checksum approach. Long term 
we really need something like Anton outlined previously (multi-level 
caching with the option to control it on an app by app basis). Anyway, 
have a try of this:

	do http://www.dobeash.com/files/rebgui/get-rebgui.r


but be aware that it writes its files to the *current* directory 
(as determined by 'what-dir) and replaces any "base" files with a 
differing checksum (so make a copy of any local changes you have 
made and want to keep).


I've also updated the issues log at: http://www.dobeash.com/it/rebgui/issues.html

I do not properly understand the need for auto-updating facility, 
unless provided as general rebgui facility = functionality available 
to custom apps too using rebgui ...

I hope it is so ... otoh do you find Gabriele's update script complicated? 
It has anything programmer needs imo in that regard (judging according 
to my first look, no direct experience though ...)

there is do-thru and launch-thru, to run things in the right folder.

Works well (do http://www.dobeash.com/files/rebgui/get-rebgui.r) 
except that all the files retain their rebpress prefix! ;) What's 
the best/easiest way to correct that?

How do I easily change a 'view-facet in RebGUI while creating a widget 
?

E.g. I want to change the font size of a few 'labels to 16pt, so 
I have to copy the font object. But the using do [] only the last 
do seams to get evaluated - actually nothing else is written in the 
doc - but how to do this without handstands ?

Why does the following not work ? Anamonitor shows that the engage 
got into place, but the rate doesn't work. I seam to forget something,
 
with rebgui:

do %rebgui.r
display "test" [
    text "hello"
    do [
        face/rate: 5
        face/feel: context [
            engage: func [f a e][
                print 'bla
            ]
            redraw: detect: over: none
        ]
    ]
]
do-events


with vid:

x: layout [button "hallo"]

x/rate: 5
x/feel: context [
    engage: func [f a e][
        print 'bla
    ]
    redraw: detect: over: none
]

view x
do-events

???any help :-)

I've seen this problem before as well, has something to do with the 
way 'rate is handled I think. Note that for the RebGUI example the 
'detect function is assigned by 'display, and if you want to debug 
the final result just add the following to the do block:

	do [a: face ...]

then you can examine the face post layout.

Remember it's just do http://www.dobeash.com/files/rebgui/get-rebgui.r
now, with the files going to public/dobeash/files/rebgui.

Minor website changes:

Licencing / Development


RebGUI is a community project that is free for both commercial and 
non-commercial use. Submissions, in particular widgets, will be accepted 
and credited to the author under the condition that they carry these 
same licence conditions.


Download

Enter the following command from the REBOL console:

	do http://www.dobeash.com/files/rebgui/get-rebgui.r


To see all the widgets in action type the following from a REBOL/View 
1.3.1 (or later) console:

	do view-root/public/www.dobeash.com/files/rebgui/tour.r

You're not alone:

REBOL/View 1.3.2.3.1 5-Dec-2005 Core 2.6.3
Copyright 2000-2005 REBOL Technologies.  All rights reserved.
REBOL is a trademark of REBOL Technologies. WWW.REBOL.COM


Licensed to: Ashley Truter (commercial) <[atruter-:-netspace-:-net-:-au]>
License ID: 5-00170-1

Type desktop to start the Viewtop.
>> change-dir %public/www.dobeash.com/files/rebgui
== %/C/rebol/view/public/www.dobeash.com/files/rebgui/
>> do %rebgui.r
Script: "RebGUI system" (6-Dec-2005)

>> view layout [text form system/version button "RebGUI" [display 
"" [text "RebGUI
from VID"]]]

fails for me too!

btw if i vidify rebgui, is there a chance to get it accepted? or 
do you insist on the api-clashes?

BTW, good spot Volker. As for your two questions:

1) If i vidify rebgui, is there a chance to get it accepted?


I'll except anything that makes writing a REBOL GUI (View, VID, RebGUI, 
whatever) easier. ;)

2) Do you insist on the api-clashes?

Not sure what the issue is here, please elaborate.

means i have to patch nearly everywhere a little bit, although close 
to find/replace. Can do that.

Isn't it possible to implement 'join? You once said that you will 
wait once RT adds RIF, but that will probably come who knows when 
- it is year and half late already. Do you think it would not be 
possible to proceed without RIF and switching to on-disk storage?

'join is really badly missing with rebdb and I am thinking switching 
to sqlite only because of that one feature. Once you have your data 
spread across many tables, it is difficult to work without it. Or 
how you do it?

0.3.9 is out and it has a lot of fixes / enhancements. From a REBOL/View 
console:

	do http://www.dobeash.com/get-rebgui.r
	do view-root/public/www.dobeash.com/RebGUI/tour.r


The dictionary file has been removed from the distribution and the 
download path has been changed from:

	www.dobeash.com/files/rebgui -> www.dobeash.com/RebGUI


so you may want to delete view-root/public/www.dobeash.com in its 
entirety first to clean things up.


In addition to the large number of fixes ( http://www.dobeash.com/it/rebgui/issues.html#section-2.2
), a number of enhancements are documented here:

	http://www.dobeash.com/it/rebgui/display.html#section-2.1.7
	http://www.dobeash.com/it/rebgui/display.html#section-3.2.4
	http://www.dobeash.com/it/rebgui/display.html#section-3.2.5
	http://www.dobeash.com/it/rebgui/display.html#section-5.20

Also note the following:

	view-face is now activate-on-show by default

 Added a request-password requestor (its password widget problems 
 are known issues)
	group-box and tab-panel now auto-size

 Table column headings are now always left aligned and clicking the 
 arrow works

 Added an 'effects context (only window is present, but others like 
 'button, 'check, etc may be added in future)


And lastly, you will notice that %tour.r has a new "Appearance" tab 
where you can dynamically alter RebGUI's metrics, colors and effects. 
Note that some colors are still "hard-bound" at context creation 
and won't change - these will be made dynamic (via a set-colors func?) 
in the future. Apart from showing off RebGUI's dynamic scaling and 
display abilities, this lets you more easily prototype a unique look 
for your own apps if you want, and if you come up with a set of options 
that is truly fantastic then share it here and it may just become 
the new RebGUI default.

Enjoy!

RebGUI goes Beta! With the fixing of some long running area / scroll 
/ slider bugs I've finally reached a stable enough release candidate 
for 0.4.0 Beta; so, from a REBOL/View console:

	do http://www.dobeash.com/get-rebgui.r
	do view-root/public/www.dobeash.com/RebGUI/tour.r


Also note that the demo directory includes a nifty new pie-chart 
widget demo (thanks Robert).


I've also separated the 0.3.x and 0.4.x issues into separate sections: 
http://www.dobeash.com/it/rebgui/issues.html#section-2.3

Changes in this release include:


 Scrolling fixed (all area scroll / slider problems should be fixed, 
 and a couple of minor field scrolling issues were also fixed)

 set-locale function to dynamically change locale files / dictionaries
	pie-chart widget added

 slider width reduced by 1/5 for area, table, text-list, drop-list, 
 edit-list (looks better)

 table column arrows made smaller and darkened, plus right-most arrow 
 moved to table boundary (more space for column heading text)


and an important one from 0.3.9 that I omitted to mention last release:


 drop-list / edit-list now size to the smaller of number of items 
 or available space in the bounding parent face (so no more lists 
 that disappear off the edge of a face / window)

Enjoy!

ESC can be fixed by changing the last few lines of 'process-keystroke 
(in %rebgui-edit.r) to read as follows:

;			#"^[" [
;				;	ESC
;				hide-popup
;			]
		][
			either all [
				event/key = #"^["
				find view*/pop-list view*/pop-face
			][
				hide-popup
			][
				;	if key is assigned to an action do it
				if any [
					not view*/focal-face
					find [button] view*/focal-face/type
				][
					if f: select face/keycodes event/key [f/action f exit]
				]
			]
		]


Only the last of multiple keystrokes provided is used; but note that 
SPC is already mapped to button (so specifying #"^M" would give it 
two mappings ... a keystroke mapping and it's base "SPC activated 
on focus" default).

So the question remains; do you want to specify "size" inclusive 
or exclusive of OS title-bar and window border(s)? If min-size was 
enforced on opening the window (if that's even possible) would that 
suffice?

Yes, that's great work! IMO it makes sense to get to a state where 
the widget is mostly feature-complete and than we do a peer review 
to get it optimized and RebGUI compliant.

What I do is, that I check the input of a field with on-unfocus and 
change TEXT and DATA to default values "0.0" and 0.0 and stay in 
the field. The error happens if I than enter a text longer then 3 
chars (the length of TEXT). If I just enter 3 or less chars it works.

My standard approach is to write collect and display routines, which 
isn't so bad if we have a form framework that can do it intelligently, 
or generate the code for us.

well, drop list is not good example of how to use gui via keyboard, 
I do agree :-) our users are not typical users maybe, as they come 
from terminal SAP R2historically, where there was no mouse :-)

my complaint to drop-list is, that it is kind of menu ... and in 
rebol it is driven via show-popup? And that is broken .... I am used 
to close menu by clicking somewhere else .... it happens occassionally, 
when I unintentionally press right mouse button etc., and I really 
don't want any option to be selected ..... so I just move mouse out 
of the menu, and do a left mouse press ... not so with rebol ....

File management? Ah no, you Windows users :-) I would really like 
to see a video, how one can work effectively using such sh*t like 
windows explorer :-) No, I do use Total commander, totally without 
single mouse press ....

and don't try to suggest type of application for my users :-) With 
our past system (now they use SAP R3 and they do complain), they 
used GUI Visual Objects based app - no keyboard, maybe unless they 
wanted something from menu - all forms plus grid were keyboard driven 
- they complained, if some form contained something requiring them 
to touch mouse ....

we can't - what you do to switch between tabs, where os uses ctrl 
+ tab, = combination, which rebol does not catch under the hood?

Ashley, do you think this is possible or will it be to complex?

0.4.1 is out and is predominantly a maintenance release. From a REBOL/View 
console:

	do http://www.dobeash.com/get-rebgui.r
	do view-root/public/www.dobeash.com/RebGUI/tour.r

Main changes include:

	- set-sizes, set-colors, set-fonts added to global context
	- CTRL-A fires action in text-list / table 'multi mode
	- radio-group, led-group, check-group now auto-size vertically
	- layout now handles false (logic!) correctly

 - effects, sizes and colors can be loaded at startup via like-named 
 dat files (simple skinning system)
	- Minor documentation updates to reflect above changes

Pekr, I promise I have this on my list; I'd like to do so, too! But 
the problem with events is that you'll have to deal with problems 
in any event ;-)

Finally, Pekr, since I know you're really concerned because of the 
current pop-up menu behaviour, you may happen to have an oppinion 
on how over events for e.g. buttons are to be handled while a menu 
is currently open, too. I think I don't like them to change their 
look by simple hovering, because that would suggest that one click 
will be enough to trigger a button's action. 


But do you think that it shouldn't work this way, too? Or do you 
like the first click next to a menu should make the menu go away 
AND trigger the button instead of getting eaten? I haven't really 
made up my mind on this, and I think that even some well know user 
interfaces are inconsistent in handling this (even though I've never 
studied that systematically, just writing from memory).

ChristianE - just don't complicate things and do it the way other 
OS compliant apps do it - there is no need to come up what we think 
would be the best, because the next guy may not like it anyway ...