AltME groups: search

http://www.lexicon.net/antonr/rebol/gui/iterated/grid-of-toggles.r

James, this example might help:

do http://www.lexicon.net/antonr/rebol/gui/iterated/demo-vid-list-scroller.r

Is there any documentation on how the windowsXP-like buttons in View1.3 
are made? They are bitmapped, right? I remember the community help 
that Carl had for making this over a year ago for the first betas. 
I will need this for some custom buttons for a project that I'm going 
to do; converting a fully graphical HTML GUI to VID while it keeps 
the same look.

Here's an old script of mine you might find useful:
http://www.lexicon.net/anton/rebol/gui/button-design.r

Sorry here is the real URL:
http://www.lexicon.net/antonr/rebol/gui/button-design.r

james_nak, uploaded new version with right-click for drawing black. 
I'll wait with possibility to choose right-click color, until I do 
GUI.

Just wondering how one matches a GUI like VID to an asynchronous 
data source. I am thinking of building a mulit tab panel application 
with an asynchronous backend.  If the user requests some data on 
one screen, and then changes their mind by switching to another screen, 
what does one do with the data when it arrives?  Does one refresh 
the original screen request and move focus from where the user switched 
to ?

This demo shows how time events are handled with an iterated face. 
(Basically, time events don't iterate.)

do load-thru http://www.lexicon.net/antonr/rebol/gui/iterated/iterated-rate-test.r

have you set it prior to do gui, or later? when face/rate is updated, 
iirc 'show is needed, dunno ...

If anyone wants to know how DO EVENT works in WAKE-EVENT, then they 
might find this script interesting:
http://www.lexicon.net/antonr/rebol/gui/mimic-do-event.r

You can see it working here:
do http://www.lexicon.net/antonr/rebol/gui/demo-mimic-do-event.r

Anton, I saw what looked like buggy behaviour in the very bottom 
gui elements in your example, the iterated slider's I guess.   Pressing 
in various slider areas in random sequences I had redraw problems 
and movement of the upper slider when pressing in lower sliders.

do http://www.lexicon.net/antonr/rebol/gui/demo-shell-list.r

site: select load-thru http://www.reboltech.com/index.r[folder "Anton"]
clear find site %index.r
foreach url [
	site/gui/mimic-do-event.r
	site/library/window.r
	site/library/stack.r
	site/gui/shell-list.r
	site/gui/percent-progress.r
][
	read-thru/update url
]

site: select load-thru http://www.reboltech.com/index.r[folder "Anton"]
clear find site %index.r
foreach url [
	site/gui/mimic-do-event.r
	site/library/window.r
	site/library/stack.r
	site/gui/shell-list.r
	site/gui/percent-progress.r
][
	read-thru/update do url
]
do http://www.lexicon.net/antonr/rebol/gui/demo-shell-list.r

This is pretty cool! I added do-events at the end of the scratch 
script.


Now I'm running a GUI program, and I can exit to the console though 
a "halt" button in the GUI. I 'SCRATCH the function I need and CTRL-E 
the changes and I can continue working with the GUI program with 
the new changes without quitting the editor. :-)

load-thru/update http://www.lexicon.net/antonr/rebol/gui/scroll-panel.r

load-thru/update http://www.lexicon.net/antonr/rebol/gui/demo-scroll-panel.r

I could really use a method for slowing down mouse events globally. 
I have a rather complex GUI with about 50 buttons, 2 listviews, fields 
and whatnot. If I accidentally click'n'drag above an empty area of 
the GUI, the interface stops responding for several seconds. I wonder 
how this could be done...

do http://www.lexicon.net/antonr/rebol/gui/iterated/demo-vid-list-scroller.r

If I have:
view main-gui

forever [
 wait 0.1
]


How can I exit the forever loop if a user closes the program by ALT+F4 
or clicking the closing X on the window?

Sorry, Robert. There is something I want to announce. :-)


http://hmkdesign.dk/list-test.png<--- a picture of the list view 
I'm building.


Currently about half done and quite usable at this time: It's resizable. 
Values are stored as blocks of blocks. All columns can be sorted. 
Input columns can be filtered so you can show only some columns. 
Columns can be freely reordered (but not in the GUI yet). One arbitrary 
column can be resized.

It has the normal range of series manipulation functions available 
in REBOL. There is also possibility for inline editing, by doubleclicking 
a line. Changed values are automatically stored in the list. All 
such operations are "bundled" in the list view VID code and you only 
need to provide whatever functions needed to store the list data 
in an external place. If a text entry is too wide, it'll be neatly 
cut with ellipsis (...).

Filtering function, to filter input by rows. Also has a scroll-to-selected-line 
function.

It's about as fast as the current LIST in VID, since it really is 
LIST with just a whole bunch of extra functions to make general list 
views easy. There are functions possible for clicking and double 
clicking and functions for retrieving rows and columns.


Current limitations: No mouse over indication (can't make it fast 
enough). Only one resizable column. No keyboard navigation. No horizontal 
scrolling. No scroll-wheel support. It doesn't integrate 100% with 
VID yet. I'm using some of my own widgets and bitmap graphics from 
a pretty big GUI library. Stripe look, font and coloring is locked. 
No standard settings yet for the list view.

All code is about 250 lines.


Planning: Reordering columns via drag'n'drop. Column resizing, if 
I can figure it out. Format the font object conditionally from list 
input (make this line bold if the age column is > 45 years, etc.). 
Grid drawing. Images in list rows. And if I can get around to it: 
Single cell in-line editing ala spreadsheets. :-)

Henrik - auto function - you will add small icon to the header (like 
there is for sorting). It will be drop-down (combo?) style. You will 
fill-it-in with unique values for particular columns .... (in your 
example Gui tools, bug database, HVIT ...., selecting one will show 
only those related items) ...imo that is what Robert means here ....

At this point, I'm not sure it's worth documenting more. Perhaps 
2-3 years ago. 90% of work is currently directed toward VID for REBOL 
3 which is an entirely and far superior GUI system.

there are actually two sets of GUI documentation. The right one is 
located here: http://rebol.net/wiki/R3_GUI

I make newbie errors every once in a while too, and there are some 
areas where I am a newbie full time (like GUI and networking).

I had a really usefull walk-through of Parse with Maxim a few weeks 
ago here.  I wouldn't say Parse has been any harder for me to learn 
about than any other aspect I have delved into so far, in fact I 
found the GUI stuff the most confusing to get ahead with.

new GUI should be much better to understand ...

I started looking at the R3 Gui too.  I am mostly intrested in drawing 
my own graphics on screen, controled by a bit of maths & trig, but 
with real-time interaction from sliders etc.  I suspect this is not 
the sort of thing that newbies are expected to do, but writing text 
in different fonts on coloured buttons dosn't do anything for me.. 

I am finding that using any part of Rebol makes it easier to understand 
the discussion here & get more in tune with what behaviour to expect.

I'm no rebgui user, but I can tell you there is a rebgui group here. 
  maybe you can find your answer there  :-)  the best way to search 
for stuff is to use the altme web archive on rebol.org, cause it 
includes even the old posts.  Altme limits back log to make the GUI 
more responsive.


the rebgui Atlme archive on rebol.org:  http://www.rebol.org/aga-display-posts.r?post=r3wp303x1

the time invested in learning R2 is not lost when you switch to R3.

Just avoid to pass to much time on GUI aspects and Ports handling, 
they are/will-be completly redisigned.

i'm not sure it's easy. The flow of GUI events is drived very differently. 
It's could be a burden to simulate the R2 behavior.

I think it would be great if the feel of the graphics on the site, 
and the logo, could match the feel of the GUI. I know GUis will have 
skins and themes, but a consistent message could go a long way. Is 
REBOL mainly a server scripting tool, or is it a slick-UI tool? And 
if View has a different target than REBOL/Command SDK, their icons 
can be themed as such.

I take the csv files, convert to RebDB, and then run reports in SQL. 
I am working on an R2 GUI version now. I really hope that R3 GUI 
is going to be functional soon. I could not tell if it was since 
no activity for a while on it. I tried the demo in R3 console and 
it does not work.

Hmm.. I think the gui is only working for Windows ....

ok, good to know. For now, I will use R2 for some GUI work I need 
to do.

And the r3 gui is about to be changed ... so it's a moving target 
as far as I understand.

I was happy that that the R2 GUI works pretty well on Mac now.

someone messed up the GUI documentation in the wiki.

BrianH said: "But you can create a new object without the field,...."

Sorry to be especially dense, but do you mean create the new object 
from scratch, or based on the old object?  I've seen the examples 
to create new from old and also adding fields, or resetting the value 
of an existing field, but never excluding old fields.


I look forward to more documentation on "map!"; maybe I should move 
to R3.  Last I checked, there was no GUI in R3, even the Windows 
version, despite what the download page says?


One last newbie question for the day - will there be a 64-bit REBOL? 
 I'm thinking my data could get rather large before too long.  Thanks 
to all of you!

Last I checked, there was no GUI in R3, even the Windows version, 
despite what the download page says?

 there is R3-GUI, which can be downloaded. check the announcements, 
 etc. A new version will be published this week

Hello Ladislav!  That is great news regarding R3-GUI!


Re. BrianH's examples, I read those as specific to the R3 TRIM function, 
so I assumed his other comment referred to some alternative approach. 
 Obviously I have much to learn.  Thank you!

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

I'm going to move this over to the licensing group, since I think 
this is more about that than RebGUI.  Simply will be using Reb GUI 
as test subject.

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.

Is there a simple way how we could seperate GUI code from application 
code, so that the application code can be used by a web-frontend 
as well? I just want to avoid to code things two-times.

My idea is to decouple it with one indirection. I have one GUI-action 
block, that collects all data from the GUI objects, creates a block/object 
and passes this further for processing. The CGI part, would collect 
all data from the CGI object and passes this further for processing. 
To the same function as the GUI.

Robert: "... a way to specify a starting size of the window that's 
not maximized. I want my app started with a size of 1024x768" Is 
that inclusive or exclusive of:


1) OS Window title bar and borders (which varies not only between 
OS, but also OS version and what DPI settings are in force)

2) Taskbar size and position (Windows) or Dock size and position 
(Mac) or ... (Linux)

Also, what happens if:

1) My display is 800x600, or the more common 1280x1024
2) I use a TabletPC or have an LCD in 768x1024 portrait mode?
3) Someone wants to use my app on a small PDA (300x200)


These are hard issues for a GUI designer to address in a generic 
manner. RebGUI provides some generalized approaches:


1) margin, gap, slider width, cell and font sizes - so you can choose 
sizes appropriates for the target display device
2) colors - so you can cater for 256-color (or lower) devices

3) Auto-resize directives (#HWXY) combined with /maximize - so your 
displays can use all available space without having to know the resolution 
in advance

4) /position refinements that are generic (top, bottom, first, second) 
- so you can design layouts in terms of, "I want this display on 
the left and this one on the right"


So the long answer to this question is, wanting to set an explicit 
display size is the wrong approach unless you are targeting a specific 
resolution device - and in that case just design your displays to 
use /maximise and be done with it. ;)

group-box: Today an other idea striked me for group-box. How about 
a way to collapse the group-box like a sub-tree in a tree control? 
With this a GUI could be make very dense and only those parts expanded 
that are currently worked on.

This approach is good for top-down approaches in applications.

The interface should be compatible with SQLite, so that no block 
transformation is required. Getting data from SQLite directly to 
the GUI and back.

Because those issues are important to IT folks and totally irrelevant 
to most real world users? ;) Most users don't even know they *can* 
drive a GUI via the keyboard, and if they click on a drop-list they 
*will* pick an item, even it's a blank "no selection" choice (I always 
have the first item of my pick lists as an empty string so users 
can easily click their way out instead of having to press ESC).


  As an aside, what most of my customers were complaining about, until 
  recently fixed, was the fact that drop-lists didn't scale to fit 
  the most items possible ... something no-one here even noticed! ;)

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

If the mouse is a waste of time for your users, then they don't need 
a GUI. Just deliver data entry functionality via a console type application. 
My users [medical] make extensive use of TabletPCs so no mouse / 
pen is a bit of a deal-breaker for me. ;)

the mouse is waste of time, totally

 ... so you don't use a mouse for file management (File Explorer) 
 or browsing? And of course you don't need one for Paint type operations? 
 Not everyone who uses a computer is doing pure keyed data entry. 
 Different strokes for different folks.


Anyway, I'm gradually adding keyboard support to RebGUI as time and 
REBOL fixes permit; but it's not high on my list of priorities.

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

Question: How do you handle the case if you have an application that 
has hundreds of fields and you need to reference those in the GUI 
code to get values in and out.

IIRC the used words for reference of GUI widgets are global words.

But than I need to write a special bind block too. That's double 
work. Once in the GUI code, once in the bind block.

I have the following problem: I need to provide a drop-list with 
two columns. And one of the columns has long texts in it, so that 
you can't read it if the drop-list isn't made extremly wide. Has 
anybody an idea how to best create the GUI for such a selection?

It's rare to come across a GUI (WinXP, Mac) where widgets have arbitrary 
sizes. The intended use of the font attribute is to change things 
other than size (alignment, style, color mostly) ... but even then 
I like to remind myself that in UI design consistency is king.

So, I'll be looking for a non GUi client.

How can I use the RebGUI LAYOUT function? I just need to get back 
the face that I can append to a PANE. I get the following error:

>> ctx-rebgui/layout material/gui
** Script Error: color needs a value
** Where: append-widget
** Near: color: any [attribute-color color] image: any

Do you have published the build-script that creates rebgui.r?

REBOL []

;	combine source scripts
do/args %prerebol.r [%rebgui-ctx.r %tmp.r]
;	remove header
save/header %tmp.r load %tmp.r []
;	remove indentation
do/args %prerebol.r [%tmp.r %rebgui.r]
delete %tmp.r
;	remove newlines and surplus spaces
gui: trim/lines read %rebgui.r
;	compact block delimiters
replace/all gui "[ " "["
replace/all gui " ]" "]"
replace/all gui " [" "["
replace/all gui "] " "]"
;	compact expression delimiters
replace/all gui "( " "("
replace/all gui " )" ")"
;	final write
write %rebgui.r gui

Had a look at porting Henrik's list-view over to RebGUI. Main challenge 
would be to convert / merge 4 styles (list-icon, list-field, list-text 
and list-view) into a single rebface. This would require quite a 
bit of code restructing. The actual internals don't need too much 
work (functions and feel code are pretty VID/RebGUI neutral), but 
a lot of references to RebGUI 'standards' need to be added; such 
as:

	default-* objects instead of system objects
	ctx-rebgui/sizes
	ctx-rebgui/colors


And the span facet needs to be added (and support logic added) to 
enable dynamic resize / rescale. Given the amount of code that needs 
to be changed, I don't believe a VID and RebGUI version can be [easily] 
built from the same code-base (i.e. the port will in effect create 
a fork).


Also, from a code complexity POV, the list-view widget is almost 
as large as *all other widgets combined* ... and it includes functionality 
that could probably otherwise go into a grid / spreadsheet type widget 
(list-view is almost a GUI framework in its own right now! ;)). If 
anyone's in doubt, I think Henrik's work rocks and fills a much needed 
gap in VID functionality. ;)

Might not be a RebGUI related problem, but let's start here: I have 
the following problem from time to time on my system and always on 
the system of one of my testers.


On my system: I start my app, the gui comes up and I click the first 
widget and the app falls back to the console. Without an error. This 
happens as do-events returns.


The same problem is on the other system, but here I only can do one 
click on a widget.

ATTENTION: rebgui-edit.r was not yet merged. Latest revision doesn't 
include older changes. We will do this ASAP. But rebgui-edit.r is 
required in this version otherwise all other changes done by us might 
not work.



FIXED *rebgui/pad: Now only works for horizontal padding. Padding 
should happen depending on the layout direction left-to-right or 
top-to-down.
	Cyphre: now PAD works according to the AFTER settigns. Example:
	display "Test" [
		after 3
	    field
		pad 5
	    field
	    pad 5
	    field
	    pad 5
	    field
	    pad 5
	    field
	    pad 5
	    field
	]
	Robert,let me know if it works like you wanted.

FIXED *group-box: When setting a new title group-box/text: "new-title" 
the surounding frame needs to be adjusted to the new text-width.

FIXED *drop-tree: When selecting different quick-access buttons directly 
one after the other, the drop-tree shouldn't close

FIXED *drop-tree: Highlighting the pressed quick-access button with 
green, the hovered one as is in orange. To give user visial feedback.

FIXED *general: a way to sepcify "align ['left]" for all further 
widgets to avoide repeation. Idea: Add disaply keywords: left, right, 
center
	Cyphre: added keyword TEXT-ALIGN left/right/center. Example:
	display "Test" [
		text-align right
		after 3
	    t: text 20 "test 1"
	    field "test 2"
	    field "test 3"
	    text-align left
	    field "test 4"
	    field "test 5"
	    field "test 6"
	]

FIXED *drop-list: an option that will show the list layered above 
everything (like the tree list of drop-tree).
	Cyphre: added drop-list/popup-mode: 'inside(default) or 'outside
	note: the same works for drop-tree

FIXED *drop-tree: changing state of the drop-tree (a new entry was 
selected) should only be done if the ACTION code returns TRUE. Otherwise 
the old state is kept, the drop-tree is closed and nothing happens. 
This allows the code to check for some pre-conditions before changing 
the state, and give some feedback to the user. Much like the on-unfocus 
functionality of RebGUI.

FIXED *drop-tree: pressing the quick-access numbers doesn't work 
any more as the drop-tree closes now if the mouse is clicked outside 
the drop-tree

FIXED *table: table/selected returns NONE if the table is empty and 
no record is selected. If there was one recrod selected at any time, 
than table/selected returns [none none <repeated for number of columns>]. 
If not row is selected at any time, table/selected should just return 
NONE.

FIXED *table: If a table is re-used in that the table is reused with 
code like:
	insert clear table/data [...]
	people/redraw

and there was a row selected before, than the internal state is still 
in "row selected" but the new row isn't highlighted. Here internal 
state and GUI don't match.

FIXED *drop-tree: clicking a "+/-" in the tree only open/closes the 
tree without calling the action for the node

FIXED *drop-tree: Re-add whole line selection and hovering functionality 
(so that mouse does not have to be over text)

FIXED *drop-tree: Add an option to get big fast-selction keys aligned 
left-to-right
	Cyphre: added drop-tree/expander-mode: 'big(default) or 'small

FIXED *button: Add an option to disable a button my-button/active: 
true/false, if disabled the button is drawn greyed-out
	Cyphre: usage is my-button/active: true/false show my-button

FIXED *field: Support number datatypes for TEXT so that things like 
field-a/text + field-b/text can be used

 Cyphre: you need to set field/edit-mode: 'numbers to activate this 
 behaviour for field(othervise it works like a normal field)
	2nd implementation uses own styel: number-field

FIXED *radio-group: Add an API that allows to provide a new DATA 
specification block at runtime or a way to alter the text of the 
radio fields at runtime.

 Cyphre: now you can just change the data content and do show on the 
 radio-group like:
		my-radio-group/data: ["item1" "item2" "item3" "item4"]
		show my-radio-group

 Note that it won't react on change of number of items. Just change 
 of texts.

FIXED *radio-group: Add a way to select one radio field at run-time
	added accesor select-item item [integer!] usage:
		my-radio-group/select-item 2
		show my-radio-group

 note: you can get the selected item using my-radio-group/picked, 
 you can get the text of selected item using my-radio-group/selected

FIXED *drop-tree/grey-out: Can it be done in that we only show the 
text in a light grey instead of black? Like Windows does it.
	Cyphre: now the masked text is light grey

FIXED *on-focus / on-unfocus: If FALSE is return from the ACTION 
and the user clicked somewhere on the screen, the focus is still 
in the "field" but no cursor bar is visible

FIXED *drop-list: IIRC in your widgets it was possible to start typing 
and the selection list was filtered. A mandatory feature for the 
drop-list :-))

 Cyphre: added drop-list/editable? flag to enable/disable editing 
 of the drop-list field

 also added drop-list/auto-fill? flag which enables automatic text 
 filterin from the selection list

FIXED *general: add hover tooltip help option to every widget (global 
patch)

 Cyphre: added TOOL-TIP facet to rebface object. If TOOL-TIP is set 
 to string! value a tooltip is shown when mouseover such widget.
	example:
		display "test" [
			button "press me" tool-tip "press this button to continue"
		]

FIXED*drop-list: proivde a much better selection-list opening algorithm 
especially for long lists. Open upward, downward, middle like so 
that as much entries are shown for the given screen space. And an 
option that will show the list layered above everything (like the 
tree list of drop-tree).
	Cyphre:

 -added droplist/lines - can be 'auto (default) or integer! to force 
 number of shown lines in droplist

 -added droplist/droplist-mode - can be 'auto (default) 'upward, 'downward 
 or 'middle to force way how the list is popped up
	you can use various combination of those settings.
FIXED*table: Add an API that allows to select a row at run-time.
	Cyphre: Usage is for example:
		my-table/select-row 5
		show my-table

FIXED*table: Add an API to table that allows to change the columns 
layout at runtime: my-table/reset ["Column 1" left 0.25 "Column2" 
center 0.75]

 Cyphre: I added the functionality byt the API call is my-table/set-columns 
 ["Column 1" left 0.25 "Column2" center 0.75]

FIXED*drop-list: fire action only if selection was made/changed, 
at the moment action fires if clicked on field too

FIXED*general: on-un/focus should be fired if user clicks an other 
widget, not only if carets leaves the widget when TAB is pressed

FIXED*table: moving bar up/down with keyboard should fire click-action, 
alternativ: pressing RETURN can fire click action

FIXED*table: align header text like data (left, center, right) at 
the moment always left
FIXED*table: TRAC #21

FiXED*TRAC #5 Cyphre: should be fixed but please test it and let 
me know.
FIXED*TRAC #6

label "Gui Size" 20 guisizerg: radio-group 30x5 data [2 3 4 5] [ 
           
            ] return

I am asking the user to set the gui size at start up.

I know that you do that - with a gui layout editor.

Thank-you, it works.  It is not clear in my head, as to why 'insert 
clear' is better than 'TheObject/Data: "NewListOfValues"', but Ill 
try to remember it by hart.  I am nearing completion of a small example 
of RebGui+RebDB app.  Last glitches are show-focus and display/close.

As for the option in display to capture the close event, how do I 
state it?  As this does not work.
Contact: compose/deep/only [
; Gui definition
]
do show-contact: does [
	display/min-size "ContactDB" Contact 680x650
	do[show-first-rowid]
	display/close [] [shutdown] ; <-- Culprit
	]
do-events

Referencing Henriks message in Ann-Reply "I need a way to show a 
sub-layout" and my own from 26-jun-2006


This is another point that the way 'display works is sub-optimal: 

When building a gui we need 3 actions: layout, display, event-handling.
Having these 3 as distinct actions works well.

Having 1 action for layout and 1 other for display and start of event-handling 
works.

BUT having 1 action for layout AND display doesn't make sense. Because 
you can't build sub-layouts, and you are stuck with a displayed but 
non-functional window after this step.

And I gather Windows Vista is going to bring a whole new heap of 
problems trying to match their new GUI

Graham: "For me, function is beauty"


As it is for me.  But your statement here implies that this issue 
is superfluous in light of deeper issues, which mischaracterizes 
the problem.   Form and function go hand in hand.  In a GUI (which 
literally implies both form and function) subtle information is transmitted 
in the cross roads of the form and the function.


Links, buttons, rounded buttons mean different things in different 
places.  To marginalize it may be myopic.


Anton: "I think that can't be good for people with vision problems. 
I say stick to the simple old ways."


We are actually going to offer both, we are actively working on this. 
 


.

I have another question also. I need a button that set a switch and 
display different text on the button to show how the switch is set. 
Does reb-gui have such a button?

IIRC Gnome had coold doc towards gui, can't find it now ...

I tried to explain that about Apple GUI here once, and no one seemed 
to understand my point.  Which is the same point you are making. 
 I think the general solution is "hinting" like they do with fonts, 
but do it at the GUI level.  So you have one set for the 640x480 
all the way to 2Kx1K group, then a supper small set for cell phones.

of course unlike our  previous rendering projects  (MD-Viewer, MDP-GUI, 
MDP-BRowser) this little challenge and brain storming intent to treat 
input as well as output rendering.

keyboard navigation is however the only way to drive a gui at full 
speed .. by ignoring the gui!

Rebolek: I meant "was it a good alternative to VID ?". The only thing 
I miss in every Rebol GUI I've seen is font antialiasing.

right, you figure that part out and make a nice GUI for us! :-)

Try this:
REBOL []
; Assignments ------------------------------------
k-prefix:	[http://www.]
k-suffix:	[.com]
txt-site:	[hulu]
url-site:	to-url ajoin [k-prefix txt-site k-suffix]

; Main-procedure ---------------------------------
load-gui
view [
    title "WebSite Selector" 
    text "Please choose a website you would like to open" 
    panel 2 [
        label "URL:" 
        txt-site: field "Hulu"
        label "WebSites:" 
        area 
    ] 
    group [
        button "Open"	browse url-site 
        button "Reset" 	reset 
        button "Cancel"	close 
]	]

I get a ***GUI Error: Cannot parse the GUI dialect

But if I type browse eval-url-site at the console, it works -- What 
am I missing?

Is it possible to draw something (lines, arrows, curves, etc) on 
top of buttons in a GUI app ?

Also, most code doesn't need to use SAME?. I use it very rarely. 
If you're writing frameworks, or GUI stuff where you want to track 
references it's important. Other than that, simple value comparisons 
are all you need.

Is it possible to draw something inside an over function  (in a GUI 
app) ?

Geomol: sorry for the delay, it was lunch time for me.

It's the first langage where i see no operator priority (maybe with 
Lisp, but it's because of its notation).

Thanks, and that may explain why I wasn't able to draw something 
correctly in a GUI app.

How's responsible of Rebol wiki contents ?

The docs on R3 GUI (written by Kr bacon) are really pleasant to read.

It's similar I suppose to prototyping with a GUI, designing the front-end 
first and building the application to drive it.  I prefer working 
that way...

Designing gui in rebol is quite simple, with rebgui even more....
So one aproach would be:
1. Make interface look like it shoud be
2. attach code to be executed on events

So what I got from this small discussion (in no particullar order)::
1. Create gui, create data, add supporting code...
2. Create rebol code with rebol...
3. Create a dialect or two (or more :)) specific to the task...

4. Create small code files and put them together using preprocessor...
5. Figure out a "reasonable" way to do it :)

What I have found working with asynchronous functions that return 
data from database calls ... one should create some type of gui at 
the start of the call, and then replace that in the callback.

What I initially did was only create the GUI on completion of the 
call which was fine when testing on the LAN, but as soon as you got 
internet latencies ... it was not so good.

off putting: some parts that can be off putting for me are parts 
in REBOL 2 that are not completed, such as the GUI system (for which 
several replacements exist) and some lack of tools for debugging, 
but REBOL 3 will solve most of these problems. The rest is a joy 
to use.

It's so different and so 'free form'. I'm not interested in the GUI 
part right now - I just want to learn something new.

It's a good approach to want to design a first REBOL GUI program 
in MVC parts, but I think you'll find when you fit them together, 
that the resulting code would blend together. We don't really talk 
in MVC terms about View code

Model and controller would be functions, that you can then connect 
to the View GUI

The GUI dialect has places for actions. That's where your model and 
controller functions would go

For simple programs, that code is often so small that we tend to 
write it out directly in the GUI dialect

No, as I say, we don't usually use MVC as such. Any View example 
shows how to specify some GUI with some actions

Perhaps, but an alert usually has its own little dialog GUI

Actions within the GUI dialect are regular REBOL code, so they can 
be anything

What I mean is that, if I read the file and end my read at a particular 
location before closing the GUI, does REBOL allow you to presist 
your state across executions of the program?