AltME groups: search

Latest SVN change (Rev#16) now uses reduce/only to evaluate words 
/ paths without the need for compose. This allows code like:

display "" [
	image i
	bar my-width
	field my-data/field1
	...
]

to be written. It still does not allow inline expressions like:

display "" [
	text my-width - 3 form now/date
	text (my-width - 3) (form now/date)
]


although I'm working on adding support for the later(parenthesized) 
form. As a side note, this is a bit of a shift in my position. I 
used to be of the opinion that explicit declaration via compose was 
more efficient than implicit declaration; but it turns out to be 
less efficient in a number of ways:

	Coding: requires extensive use of compose/deep and parenthesis

 Obviousness: it's not obvious why code like "image my-image" doesn't 
 work

 Complexity: forcing use of compose/deep makes it harder to write 
 action blocks inline [that need themselves to use compose]
	Familiarity: It's not the way VID or other dialects work

 Speed: compose/deep is actually slower than reduce/only and a few 
 subsequent parenthesis reductions


You can thank Graham's comments above as the catalyst to change. 
;)

Ashley, I think it is a bad idea to use reduce/only in this context. 
It was basically designed for the draw dialect, so it disallows function 
and expression evaluations. I would recommend just processing the 
layout dialect similar to the way VID layout does it.

Why? The main dialect parser of RebGUI can now be expressed in one 
simple parse construct:

parse reduce/only spec words [
	any [
		opt [... evaluate () to return a REBOL value...]
		[
			parse rules to handle REBOL values
			...
		]
	]
]


compared to the relatively complex parsing logic in VID (which, to 
be fair, has to handle styles amongst other things).


The main functional difference between what this allows in VID and 
RebGUI is that you don't need to parenthesize your expressions in 
VID (and I kind of like the idea of having to parenthesize them anyway, 
it makes expressions stand out just like they do in compose).


Having said that, if someone can show me a RebGUI parser built along 
the lines of VID that is clean and lean I'll willing to be convinced 
otherwise. ;)

Tree: The code for the tree is mostly complete. Even an API to change 
the tree at runtime exists. The code isn't splitted out into a standalone 
tree-widget yet. It's included in the drop-tree widget.

As we have made several, IMO useful changes to RebGUI, now to submit 
them? Is there something like a development branch in SVN? Or should 
I diff the changes and post here or mail Ashley?

A development branch sounds good .. so we can test before it gets 
committed to main branch.

The project isn't big enough to justify multiple source trees at 
present, so as long as what gets committed works and is functionally 
complete we should be fine (and get-rebgui.r is based on stable snapshots 
so we can handle temporary breakages). Just make sure the committed 
changes include those made in rev#16 and rev#17, and a point form 
summary of changes posted here. Thanks.

Question: If you create several data-forms that can loaded with different 
records, I always need a way to reset those fields/drop-lists etc. 
that are not loaded to default values or empty values.

I think something like a /reset function would be nice. Either the 
reset value is set by using the TEXT/DATA values present at the time 
the layout is created or I can specify a value within the OPTIONS 
block. What do you think?

How about adding a refinement to the display function that does something 
similar to the load-form-data function we discussed a while back. 
We could then populate forms at creation with:

	display/load-data "" [..] block-of-values

and reset them with:

	load-form-data my-form block-of-values


I think it's a lot cleaner to do this on a form basis than trying 
to do it at the widget level.

It must be dynamic, so not only at creation time. And, I only store 
values wehre the user did enter something. Hence it's necessary to 
iterate over every form element and either set a value if available 
or reset to a default value.

show-data: Why does this function doesn't have a /no-show refinement?

How about a clear-data function? For example: I'm using fields in 
that TEXT contains the visual representation of the DATA field. As 
both might be different (1000s seperators etc.)

Why does this function doesn't have a /no-show refinement?
 same could be said for show-color and show-text.

How about a clear-data function?
 Could be useful.


I'm thinking one function could handle all these permutations: a 
set-attribute function like:

	set-attribute: make function! [
		face [object!]
		attribute [word!]
		value [any-type!]
		/no-show
		/focus
	] [
		...
	]


where a value of none! meant clear (which is the case anyway for 
widgets where none! is a legal value).

First cut attempt at set- functions to replace various show- functions:

set-attribute: make function! [
	face [object!] "Window dialog face"
	attribute [word!] "Attribute to set"
	value [any-type!]
	/no-show "Don't show"
	/focus
] [
	face/:attribute: case [
		string? value		[
			face/line-list: none

   all [face/type = 'area face/para face/para/scroll: 0x0 face/pane/data: 
   0]
			form value
		]
		series? value		[copy value]
		attribute = 'color	[either word? value [get value] [value]]
		true				[value]
	]
	unless no-show [
		either focus [ctx-rebgui/edit/focus face] [show face]
	]
]

set-attributes: make function! [
	face [object!] "Window dialog face"
	attributes [block!] "Block of attribute/value pairs to set"
	/no-show "Don't show"
] [
	foreach [attribute value] attributes [
		set-attribute/no-show face attribute value
	]
	any [no-show show face]
]

Used like this:

	display "" [
		b: box
		button "A" [set-attribute b 'color red]
		button "B" [set-attributes b [color blue effect arrow]]
		button "Clear" [set-attributes b [color none effect none]]
	]

Just to inform you, we are going to publish all our RebGUI changes 
today. Those will fixe and enhance quite a lot of things. Further 
a new widget "drop-tree" will be published as well.

options expects a block, so "options [multi]" should work fine.

I just tried logging in as robert from XP using FF, works without 
a problem (Opera didn't seem to work correctly). Make sure that after 
clicking the "Login" link and entering your username and password 
that the red "Login" link changes to black text reading "logged in 
as robert". All Wiki pages are then editable.

how long do you think it will last till some testing stuff is being 
made an official version?

 Once SVN changes are in and working I let it sit for a week or two 
 before taking another snapshot for get-rebgui.r.

There are some unexpected behaviours with the area editor when using 
overstrike mode.  If you overtype on a line where there is a cr, 
it follows the carriage return when I was expecting it to keep on 
the same line.  Also, if you hit return inside a line, it produces 
a character

square character rather than moving to the next line.  It correctly 
moves to the next line if at the end of a line of text.

That's a weird one (and it's not specific to OVR mode). I'll see 
if I can work out what's causing it. Odd that no-one else caught 
that yet! ;)

The bug must be in area.r in the slider-action. weird stuff. the 
area-slider is before the area, so the slider is shown when the area 
is shown. and in case of this last return its action is called. and 
there the caret is changed. Maybe all this resize-automatics in 'redraw 
is a bit to magic? Should that bemoved into  explicit calls?

somehow the keep-caret-in-visible-area magic is broken. take tour, 
enter a lot of lines with content. more then fit in window. scroll 
down, set caret and scroll up. when the caret scrolls out of range, 
it moves automatically up. keeps also position in line. but not if 
char is at start of line, then it jumps to second char.

looks weird. look at the sizes/font-height. That is an integer!, 
not a pair. so it is added to x too.

That, plus a check for caret tail in edit.r, seems to have fixed 
it. Any remaining problems with rev#20 now Graham?

is the release expected for tonight?  wondering if I should add a 
note on "rebol week" ...

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.

Can  you set the highlight yet on a table row programmatically?

No.


That's a pretty broad problem statement Robert, sort of like "I click 
on something and something fails". ;)

Robert .... I have seen a similar problem, I run Gabrielle's Clips.r 
from the library , if after having selected a clipboard item the 
tab key is pressed, a blank console is displayed.

The program never writes to the console so should never dispaly the 
console.

I first thought this effect is because some internal states are not 
resetted when a script is just restarted from the console. But as 
said, one user has this problem always.

Ok, I finally made it to publish all our RebGUI changes. I hope this 
helps the rest of the community. We did change a lot:

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

Please give all changes a try, and help to enhance RebGUI even more.

you know, ppl get distracted sometimes by simple things, which complicate 
it a bit ..... - what is the point of new install scheme? what is 
the point of packing it? Those are not my words (althoug I do agree 
with him)

probably not ... I now write longer letter to him, as he thought 
that it is a kind of protecting source code :-)

performance. Once you are used to it, you optimize everything.. a 
single file for installation is good, and while we areat it, why 
not kill all this whitespaces? source is available anyway. (thinking 
loudwith Ashleys voice ;)

or maybe he really tried a new obfuscation-scheme?

imo it is typical example, how we made simple thing a bit more complicated, 
or I would not met with such reaction ...

a trick i started to use is to set view-root to the current directory. 
theni have a %public/ there with all the downloaded stuff nicely 
sorted by server, by using *-thru

And show up a requester to let the user choose.

maybe I will even download it as-is now, and change also target location 
.... using cache directory does not work for me, I organise "library 
packages" a bit different way ...

How to get the label from a selected radio-group ?

Thanks .. is there going to be a formal syntax description for the 
rebgui dialect ?

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

yep .. it was not a block before.

Yes, I changed the radio-group behaviour a bit so it works more consistent 
(at least IMO). Ofcourse if this is a backward compatibility problem 
then use the old version. I agree there shoudl be default accesor 
system but AFAIK current RebGUI lacks it so maybe a good improvement 
for future?

VID accessors is good methog, it just stopped half-way, which is 
a pity ... should work in set-face 'attribute 'value mode, and not 
only in set-face 'value one....

Graham, "is there going to be a formal syntax description for the 
rebgui dialect" ... I can certainly get the ball rolling, can you 
point me to a good format we can base it on?

submitted radio-group bugs to trac ... seems a large number of active 
tickets :(

What's the best way to allow a user to define their own forms without 
reimplementing Vid or rebgui parser ?

I just tried rebgui, and I have a few questions ...

is there a reason, that display opens the windows, but does not start 
do-events? This seems a bit strange to me. When testing layouts in 
the console, I mostly end up with inactive windows.

I have tried to create something like a calendar layout:

two TEXTs, and a TEXT-LIST below them, and then 2 rows and 2 columns 
of this. 

The internal resizer was not able to cope with this, either the left 
widgets, or the right widgets were resized. Is it just me, or is 
the resizer not able to cope with this?

the first one you need a #Y for those you want to have a y displacement

I've been looking at how to save a form contents and reload the same 
values when opening the form.

How to reference the layout from within a do block ?

display "Example" compose [
    button "a" [alert "hi"] field "a" return 
    button "b" field "b" return 
    do [
        foreach fac face/pane[
 probe fac/text
]
    ]
]

let me try a smaller example ..

they might name a field rebol: field 100

i would take roberts suggestion but use my own naming. eg have a 
/my-name in your fields and compare with that.

mostly for forms I store the form data as a block in the database

because you might have a hundred different forms

I'm using all of them in a big app (100KB at the moment). Mostly 
not problems found. But feel free to report bugs, as we are going 
to fix them.

if full naming is to much effort, maybe you could store the labels 
together with the data. not to find the right field, but to havea 
check to make sure. just in case. could also make datatypes more 
readable. just to make sure that the right femoral artery does not 
change to a left femoral artery just becaue somebody deleted a line.

this is a potential problem :)

if 'face in the do-block refers to the layout, how to get this inside 
a button action block?

Ingo:


is there a reason, that display opens the windows, but does not start 
do-events?

 ... we can't assume the "first" window automatically needs to start 
 the event loop. Perhaps the display is being assigned to a word and 
 cached for later use? Or the display is done early in the script 
 for lots of subsequent initialization and *then* needs to fire up 
 the event loop. I personally like having to code it explicitly as 
 it then stands out - "We are starting the event loop HERE".

Is it possible to get the window size?
 ... display [button do [ws: face/size]]

Is it possible to set an own resizer function?

 ... No, you'd have to change a lot of code to implement your own.

I would like to have equal sizes for all text-lists.

 The RebGUI resizing model is pretty basic, it supports one resizeable 
 widget in each axis (horizonal and vertical) with any number of offset 
 adjustments (the #XY directives). More advanced schemes (such as 
 proportional or percentage based) are possible, but significantly 
 harder to implement (and require size/state information to be retained).

Graham, I'd thought using () in the template would enable RebGUI 
to evaluate the expressions automatically for you. Do you have a 
small example of what you're trying to do?

Robert: Your rev#21 changes to rebgui-edit.r nuked my rev#19 and 
rev#20 changes ... but the good news is that they collectively constituted 
the following line in the insert-char function:


 unless any [insert? tail? view*/caret newline = first view*/caret] 
 [remove view*/caret]


Should I put that line back in a new rev or do you want to bundle 
that in with any additional changes you are working on?

do %rebgui.r


test: {label "This is a label" (width) radio-group data [ "-" "+" 
] return label "Another label" (width - 5)}

go: func [ template [string!] 
	/local width
][
	width: 20
	template: compose bind to-block template 'width
?? template 
	display "testing ..." [
		(template)
	]
]


go test

do-events

it comes a cropper on the "-" ... ** Script Error: - word has no 
context
** Where: go
** Near: width - 5

test: {label "This is a label" (width) radio-group 24x4 data [ "-" 
"+" ] return label "Another label" (width - 5)}

go: func [ template [string!] 
	/local width
][
	width: 30
	template: compose bind to-block template 'width
	display "testing ..." compose/deep [
		(template)
	]
]

go test
do-events

Always a problem when working with string representations of a dialect. 
Try:

go: func [ template [string!]][
	width: 30
	display "testing ..." load template
]


Although this depends on width being global. But since you're working 
with strings anyway, why not forget binding and go with simple variable 
substitution as in:

	...
	replace/all template "%width%" 30
	...


with appropriate markers to prevent accidental partial replacements.

Safest way is to put a front-end on that precludes free-form string 
entry! ;)

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

seems a lot of hardwork though!

this is a function to reset some of the widgets inside a group-box 
.. doesn't work though

this function is an action for a button inside the same layout

this code though works if included as is inside the button action 
.. but not when used as a function

radio-group/select-item 0 doesn't work ... doesn't allow you to set 
the radio-group to a state where none is selected

in a way like to-block with hooks.

Is there a way to control the sort display for a table?

Take a look at the source. I think it's a flag and if you than do 
a /redraw it should be sorted.

I had a very quick glance at RebGUI widgets. Would it be possible/easier 
to implement LIST-VIEW as a widget?

also, I don't think it's any easier to create a list style using 
VID or REBGUI - the same basic issues are there, but porting to rebgui 
is fairly straightforward. Just keep the rebgui source handy as you 
will need to dip into it a few times.

It's mostly done (90%) as there is a complete tree in the drop-tree 
widget. We just didn't extract the code into a stand-alone widget 
as I don't need it at the moment. Feel free to go for it.

Ashley ...

[me] "is there a reason, that display opens the windows, but does 
not start do-events?" [ashley] ... we can't assume the "first" window 
automatically needs to start the event loop. Perhaps the display 
is being assigned to a word and cached for later use? Or the display 
is done early in the script for lots of subsequent initialization 
and *then* needs to fire up the event loop.

Right, that's it! 


As I see it, there are 3 distinct actions: layout, display, handle 
the events.


With view I can do the layout independently from display and event-handling. 
With rebgui I can't, because display does the layout _and_ display, 
and then I'm stuck with a dysfunctional window. So I can't do a layout 
to assign it to a subpane somewhere, it's instantly displayed as 
it's own window.

display was supposed to return a layout and not display as an refinement. 
 It does not.  But it can be changed to do this.

I have to add a 'halt' in order to see any of the examples but then 
the examples don't work!

Thanks.  I'll give it a try

I know - but if you want to have all in one exe file as a result? 
You have to somehow "include" your code, no? 'do is not enough, is 
it? (as it would expect it being placed in external .r file ...

Gordon, the demo directory and scripts (bubble-menu, list-view & 
triggers) were part of earlier releases. The directory was removed 
when the source was migrated to SVN, and all non-stable widgets (including 
list-view, bubble-menu and a few others) were removed. There is no 
need to "do %rebgui-widgets.r" as this is included directly in the 
new merged %rebgui.r script (and invoked from %rebgui-ctx.r if you 
run from the SVN source direct). LIST-VIEW is an important widget 
which we are hoping Henrik will be able to port to RebGUI from the 
excellent work he has done on this already.

I'm trying my way of creating templates, but have come across a problem 
with the check-group.  This takes, none, true and false as values, 
these are in the global context.  If I define more local words with 
the same names as these, how I can set them to the values in the 
global context?

give that a go

Is this a rebgui error ?  There is an error in your template: make 
object! [
    code: 400
    type: 'math
    id: 'zero-divide
    arg1: none
    arg2: none
    arg3: none
    near: [visible / total]
    where: 'view
]

maybe some face has a 0-size?

make a subfolder first.

Committed a new version of area.r which checks for zero-divide.

check-repository, you get a change-list.