World: r3wp

Good stuff, especially the optimization section. I see a lot of potential 
in my code :-))

Is there a way that we can add a RebGUI "verifier" that will check 
the use of VID words, etc.? IMO a good help.

For SDK users; rebface.exe, then:

do %path/gfx-colors.r
do %path/gfx-funcs.r
do %tour.r

So, it's simple to encap. That's good.

Haven't tried it yet.

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.

Depends. You can structure your code so that all the displays are 
in one file and all the business rules / data / action logic in another 
by coding like this:

display "Test" compose/only [
	button (app/labels/save) (app/actions/save)
	drop-list data (app/options/save)
]


and using references to face (and face/parent-face) within your actions. 
This approach achieves a couple of things:

	1) Separation of display from process

 2) code / data reuse (i.e. you can share data / action blocks across 
 multiple displays)

 3) Can reduce the amount of code that is composed as app data / logic 
 can be composed independently of the display
	4) Code is more portable (as face references are generic)
	5) Probably easier to maintain and debug

Problems with this approach are:


 1) "f: field" is easier to reference than "face/parent-face/pane/2" 
 etc
	2) You have to really think about how you structure your code
	3) It's very different from the way we are used to (VID)

a thought: how about adding to vars instead of setting them? i imagine

 bt: context[rebgui: none cgi: none fill: [true] action: [alert value] 
 my-stuff: ..]
 display .. [
  bt: button
 ]
and now display would put its face in bt/rebgui

Sounds interesting.

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.

Ashley, can we please add a way to display to either specify a starting 
size of the window that's not maximized. I want my app started with 
a size of 1024x768

Is there a way to re-use widgets like done with 'style in VID? For 
exampel: I have a drop-list specification, I need at several places 
but I don't want to copy the code. I tried it use a (my-drop-list) 
compose word but this doesn't work.

label-size etc.: If this was set in an outer object, the value should 
be used for group-box as well.

triggers: It seems that a on-unfocus function of a field is called 
even when I only switch tabs in a tab-panel.

triggers: This seems to be problem, if a RebGUI app is closed to 
the command line and than restarted. Seems like the triggers are 
somehow still active than.

Robert: "Using CTRL+A in list doesn't mark all entries." It does 
work, but only in "multi" mode. ;)

Ok, than it might be the help text on screen that has a bug ;-))

Note: 

Single" allows one row at a time to be selected, whilst "Multi" supports 
multi-row selection via Ctrl+click, Shift+click and Ctrl+A keystrokes." 
... how could this be any clearer? ;)

I know... IIRC (haven't cross checked) in tour the text says "try 
CTRL+A to selct all..." but it's a single tabel shown. So, I thought 
it's not working.

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!

Great stuff as always.

oh, I want to play with this, but no time :-(

ashley, LIST-VIEW may soon be at a point where it'll become portable, 
i.e. no big structural changes are coming

Area widget  looking great!

If it passes the "Graham test" then it might just finally be fixed! 
;)  (Who would of thought it could take over 8 hours to get a dozen 
lines or so of scroll and area redraw code correct!!!)

Tough problem - quality is not quantity!

I can make a start now at rolling the new version of RebGUI into 
my EMR finally.

Ashley, just noticed something for the Text-List when in multi mode. 
 Ctrl-clicking shows each element in the list is highlighted as clicked 
and the associated text is displayed in the Month display field. 
  however, selecting CTRL-A does not display all the months in the 
Month display field while it does highlight all the months.

Ctrl-clicking all individually shows all values in the Month display 
area.

selecting a few with Ctrl-click, then selecting all, then Ctrl-clicking 
on one to remove it from the selection then shows all but the un-selected 
item... Seems Ctrl-click should be showing all months.

tour.r uses the text-list as follows:


 ex-text-list: text-list (tab-size - 70x25) #HW data (system/locale/months) 
 [
		show-text ex-text-list-text face/selected
	]


so the action (showing currently selected months) is only fired on 
a left-mouse click (single or double). The interesting design question 
here is whether CTRL-A *should also* fire the widget's action? I'm 
open to suggestions on this one. ;)

I think so. It's a "selection action" rather than a "click action". 
The click is a way to achieve a selection, and so is the ctrl-A.

but if the event depends on what is selected ?

ie. what is appropriate for one select may not be for multiple selects.

The action code can merely examine the current selection.

oh no! the user has to write more code to handle that!

In multi mode, the user code can't avoid having to check face/selected 
to see what is in it.

Fixed in one line:

	if find face/options 'multi [
		clear face/picked
		repeat i face/rows [insert tail face/picked i]
		face/action face ; added
	]


works well, with the face being the row last clicked on. %tour.r 
works without modification.

So far, 0.40 is working well with my EMR.

I would like to see keycode support if possible.

Asley: having done some personnal work on area with scroller, 8 hours 
is not so much to have it working the right way.

Yes, keycode is an important thing to support. I never like apps, 
especially the one I use a lot, that can't be controled by short-cuts. 
The most important one is, how to jump in/out of group-boxes, to 
be able to fill in input-forms.

Keycodes are already supported; try:

display "Test" [
	button #"a" [print "A"]
	button #"b" [print "B"]
]


Full keyboard navigation (e.g. tabing into out of group-box, tab-panel, 
etc) is another issue.

well, even model of View is not still OK .... I think the pop-face 
is not ok. Try list-down style and try to press mouse outside its 
boundaries, it should close, but it does not. It at least reacts 
to ESC, but that is hardly sufficient ...

that was quick Ashley!

keycodes were a part of VID, which the source of 'display seems to 
use....

I added them back in 0.3.2. Note that case does not matter: #"a" 
will match both "a" and "A".


keycodes were a part of VID, which the source of 'display seems to 
use

 ... correct on the first count, but keycodes in VID are implemented 
 via the global events system which is not used in RebGUI (for those 
 who are interested and have the SDK sources; have a look at %view-vid.r 
 - Carl's comments make interesting reading).


RebGUI uses a much simpler (and dare I say more efficient) approach 
whereby the layout function (%rebgui-layout.r) collects keycode / 
face pairs and places them in a keycodes block at the window level 
(%rebgui-display.r). These keycodes are used by the 'process-keystroke 
function in %rebgui-edit.r. All this is very different from the way 
in which VID does this.

That sounds like a good approach Ashley, kind of like Windows accelerator 
tables.

Doing it at the window level has a lot of advantages; namely:


 1) automatically supports / handles duplicate keycodes across multiple 
 windows

 2) scales well (a window without keycodes doesn't carry the same 
 overhead as one with lots)

 3) can have multiple keycodes referring to the same face (for efficiency, 
 RebGUI's layout function only uses the last one specified)

 4) can have a keycode that refers to multiple faces (for sanity's 
 sake, RebGUI only acts upon the first face referred to)

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

Robert: "Is there a way to re-use widgets like done with 'style in 
VID? For example: I have a drop-list specification, I need at several 
places but I don't want to copy the code."

Short answer, no.


If you have a "style" that is sufficiently different from the base 
widget (that is used often) then consider:

1) modify the widget's defaults in %rebgui-widgets.r, or
2) modify them inline, as in:

	ctx-rebgui/widgets/<widget>/<facet>: <value>

3) derive a new widget that works exactly the way you want.