AltME groups: search

- display now returns face

 - clear-widget uses radio-group/select-item and table/text-list select-row
 - table/rows attribute added to complement table/cols
 - text-list/rows attribute added
 - get-input and set-input funcs added


These later functions allow you to easily get and put values into 
a display or tab-panel, even one containing nested grouping widgets 
such as 'group-box or 'tab-panel. Handles the following input widgets: 
area check check-group drop-list edit-list field group-box password 
radio-group slider tab-panel table text-list.


The /type refinement of get-input is usefull in design/debug mode 
to get a formatted list of widget type/value pairs.

Example code to demonstrate the use of these two functions.

d: display "Test" [
	after 3
	area "area"
	check true
	check-group data ["check" true]
	drop-list data ["drop-list"]
	edit-list data ["edit-list"]
	field "field"
	group-box "group-box" data [
		field "field"
	]
	password "password"
	radio-group data [1 "radio-group"]
	slider data .5
	tab-panel data ["A" [field "Tab-panel"] "B" []]
	table options ["col" left 1.0] data ["row1" "row2"]
	text-list data ["line1" "line2"]
	button [a: get-input d b: get-input/type d halt]
	button [

  put-input d ["Text" true [false] "A" "B" "text" ["xx"] "" 1 1 ["Bob"] 
  [1] [2]]
		show d
	]
]

I'm still open on the names, and will probably add a 'clear-input 
type function to round out the set. I chose the word 'input as both 
'form and 'values implies a superset of input [values]. I also considered 
other action words such as read, write, load and save; but to my 
mind they are so well established in REBOL that they already have 
other meanings (e.g. load-form, like load-image, would imply loading 
a form from disk).

'set is OK except that the logical complement is 'unset.

Ashley, please take a look at the xpeers RebGUI stuff. We have added 
a lot and should align the code lines.

Resizing: I have a question how to best implement the following:
- I have three tables from left to right

- I want to make a horizontal resizing in that the middle and right 
table are moved and narrowed.
- The left most tables only uses #X
- The moving should be right aligned to the left side table


I hope you understand what I mean. Using #WX screws up the layout 
as the gaps between the table get to big

Current system does not support more than one resize per axis (i.e. 
you can have one #W per x axis and one #Y per y axis). What you are 
asking for is a form of proportional resizing.

We enhanced a lot of the widgets etc. to much to list here. The problem 
is I don't find the time to document everything and publish it. So, 
if someone want to do it, let me know.

I will need to release grid too :-( I want to have it out 1.12 as 
is - just a bit of further documenting needed

Robert - any screenshots? I do remember some of your older stuff, 
which looked pretty. I wonder if you use default RebGUI look, or 
you tweked it a bit, to something more pleasantly looking?

area remains a big weakness for me.

Graham, I have build a cost-analysing software. With this it's possible 
to identify cost optimizing potential within the complete supply-chain.

Petr, I'm currently the interims purchasing manager for SAP AG region 
Central:-)) So, three days a week I'm in Walldorf.

Styling: I kept it mostly as is, because of lack of time. It's OK 
but a bit more eye candy would be nice.

OT: Just posting from a ICE-3 running at 300km/h

You will do the whole community a flavour.

Good idea, if you email all the changes in a single zip attachment 
I'll probably get around to looking at it a lot faster ;) Any existing 
doco you have would also be nice, saves a lot of time trying to guess 
why certain changes were made.

Hi folks. Is there a way to set a background image for the display. 
IE: Backdrop %image using rebGui?

I have the same problem also with closing windows.  Sometimes the 
button is in a layout with nothing else.  Sometimes I use unview/only 
face/parent-face and sometimes it works, and other times it does 
nothing.

if the spell checker hits a word which is not in the visible part 
of the screen, does the screen scroll to display this text?

Thanks, I'll have a look at this next weekend.

Ashley, feasible to add a scroller to tab panels if the widgets inside 
are too large?

Graham, difficult. Not going to be a high priority for me anytime 
soon.

Would someone please give me an example of how to feed data from 
a sqlite db into a rebgui table?

a: sql/flat "select * from"
insert clear table/data a
table/redraw

Ashley's example is a static one. The data is fetched only once when 
the compose happens. If you add my code to an action block of a button 
for example, the table is updated dynamically.

Guys, it would be great if you could submit this as code for the 
cookbook.

It would take a beginner like me months of part time reading and 
thinkering to come up with this.
Think of the "outside in" approach proposed by B.Meyer.

Ashley, I have a label inside a group-box which is inside three nested 
tab-panels.  Localisation is not changing the labels.

Localization code hasn't changed for a long time, so I doubt it's 
a build# problem.

The test I ran here was a single label in a group-box within a tab-panel 
within a tab-panel within a tab-panel.

Probably because you don't have a space between "Occupation:" and 
 "Occ:"

Reproduced it, very odd. Looking at it now ...


re dynamic translations. Reading Gabriele's comments in the chat 
group on his TRANSLATE func got me to thinking we could do something 
similar, as in:

	display "Test" [
		button "Old Text" [face/text: translate "New Text" show face]
	]


'translate would return a string translation if passed a string, 
otherwise a block of translated strings if passed a block.

Yep, that's how it works The important point in the example I posted 
was not that it didn't use show-text, but that it is a func that 
is called to explicitly translate string(s) used by other function(s).

hmm ... retract my being able to reproduce the problem. Change your 
locale.dat file to have the following:

words: [
	"AA:"	"A:"
	"BB:"	"B:"
]

and verify labels "AA:" and "BB:" are translated correctly.

Really? Even with code as simple as:

	display "Test" [label "AA:"]


The code that does the translations is nothing more than a simple 
select, which you can run manually by adding a halt to your code 
and doing the following from the console:

	select ctx-rebgui/locale*/words "AA:"

I get "A:"

In the above example it is vey important that the label was "AA:" 
not "A:" (which would explain a "BB:" result returned by select)

Build#48 committed to SVN, incorporating Robert's/Cyphre's extensive 
changes ((including new chart, drop-tree, grid, input-grid & panel 
widgets). Panel & Input-Grid added to %tour.r.


These new widgets (apart from panel) have an impressive range of 
options/features ... but scant documentation or usage examples. If 
Robert/Cyphre could post a few examples here that would help. If 
anyone reads the source code and figures something out then an entry 
or two here would be appreciated: http://trac.geekisp.com/rebgui/wiki/WidgetList

could there be a package produced from #48?

I just added documenation for:
- drop-list (we added a lot of functionality)
- drop-tree
- input-grid

Big ones still open are CHART and TABLE (added a lot of stuff as 
well). Other changes we did effect: group-box, field, radio-group

We have reworked radio-group to support/return positional IDs. Hence 
the specification syntax in our version changed.  I never had the 
bug your reported. Give it a try.

Robert, is there a tree widget now?

did you incorporated all changes or are there some left out?

 I left out the number-field widget and all references to it (as per 
 Cyphre's note in the widget source). Your button changes, especially 
 the addition of a click? word, were incompatible with mine so I left 
 them out as well. The rest of the changes were merged in pretty much 
 as they are; I have not had time to review/optimize the code in depth 
 ... although I fixed a few incompatibilities that prevented tour.r 
 from working. For your reference these were the minor changes I made::


 - instead of drop-list generating an error if it doesn't get a block 
 of strings, I changed it so it forms values within a block
	- radio-group does a reduce on the data block

 - rewrote panel widget so it works consistently and doesn't require 
 /origin changes to layout

 - the detect up feel in rebgui-display was failing with requestors 
 and an invalid mouse-down-offset so I added it as an extra condition 
 of the all block

 - tool-tip-time was incorrectly initialized to now, changed to now/time/precide 
 so it works on Mac/Linux

 - renamed tooltip-bkg to tooltip-fill and made tool-bar widget use 
 these new tooltip color settings (3 in total)
	- updated tour.r radio-group labels to strings
	- added panel and input-grid examples to tour.r
	- added place-holder entries in Trac WidgetList


My primary objective was to merge these changes ASAP before the code 
had diverged too much more. I'm happy with the merged result (it 
works and there are 5 new widgets), but it's probably not well tested 
or stable enough for a bundle yet.

I synced to a new repository again .. and am seeing the same problem 
still.

Ashley, thanks for the feedback. WRTstability and quality. I'm using 
this code for several month now in a very big and complex application. 
It works very good.


We take a look at your modifications and merge them back to our stream, 
so we are back in sync.

drop-tree: It's a menu system, that uses a tree in a drop-down list. 
It's very compact, easy to understand. The idea is, instread of having 
10 menus horizontally and you have to remember where funciton XYZ 
is located in, you get a hierarchical overview and just choose it.

tree: Well, drop-tree has a complete tree widget inside. So, I think 
we should extract it and provide it as a seperate widget as well. 
Anyone going to do it?

Got a short example of the drop tree in action?

build#49 committed to SVN. Adds a fully functional spinner widget.

Chart: Will come next. That's a bit more complicate as it allows 
a lot customization.

One thing I'd like changed with input-grid (and potentially grid 
and chart) is to separate the specification dialect into the options 
block and leave data as a block "of text values for all cells in 
the grid". It's difficult to do this for widgets like drop-tree and 
tab-panel where data and specification are merged, but where the 
separation is clean, as for table and input-grid, it makes it easier 
to conceptualize by having options/specification in one block (options) 
and values in another (data).

Run tour.r and let your mouse hover over the logo, a tooltip should 
appear. ;)

I just noticed that in earlier builds you could use integers as values 
in a radio group.  Now you can't.  They have to be strings.

re: area hilight. Refer rebgui-edit.r

	;added AREA too according to Robert's request -Cyphre
	hilight-on-focus: [area edit-list field spinner]

 caret-on-focus: [area drop-list edit-list field grid password spinner]
	action-on-enter: [drop-list edit-list field password spinner]


All of these can be modified at runtime by reference to ctx-rebgui/edit/<block>/<word> 
... the bigger question is what constitutes a reasonable set of default 
values.


re: radio-group. Robert's changes forced labels to be strings. I'm 
pretty comfortable with this change as label expects a string argument 
and a radio-group is a collection of labels. On the other hand, the 
reason I changed drop-list (to form all values) is that it is not 
reasonable to expect an arbitrary list of values to all be strings 
(e.g. a list of postcodes), and/or to expect the developer to maintain 
their string state. I'm open to counter arguments on this one though.

It would be really neat if you could turn your tour.r configuration 
window into a runtime reusable config screen.

I had someone else email me with that exact same thought today! They 
wanted the ability to load and save RebGUI preference settings. Something 
I need to think about if we want to support a basic level of "skinning".

I would just create a rebol object which can be loaded back in again.

Confirmed with a new checkout from #49

otherwise, I have to set the mode inside a do block.

That's what the options block is for. drop-list and a few other widgets 
need to be enhanced to fully implement this.

Robert, you wrote: 

a: sql/flat "select * from"
insert clear table/data a
table/redraw


I still can't get this to work. Would you please put it into Ashley's 
example program in the right places so I can see how to use it?

I've been thinking about Jean-Francois' comment. A simple but complete 
working example of a RebGUI + SQLite database would really help us 
those of us that are not professionals. If I start a new group for 
this, and reduce my program to just a few fields to make it as simple 
as possible, would you guys help me get it working? and we will just 
leave it in the public domain.

My preferred approach, which I'm working on, is to write an "official" 
document on interfacing RebGUI with SQLite (or any other database 
that returns its results as a flat block of values (i.e. does not 
store rows in sub-blocks)). I've had quite a few people email me 
with such questions recently.

Added a RebGUI cookbook with sections on SQLite integration and SDK 
app creation: http://www.dobeash.com/RebGUI/cookbook.html

Graham: Do you take a look at the Trac documentation? There it's 
written how to use 'outside.
	my-drop-list/popup-mode: 'outside

The other feature is missing in the docs:

drop-list/droplist-mode - can be 'auto (default) 'upward, 'downward 
or 'middle to force way how the list is popped up

radio-group: The DATA block format has changed in our version. You 
now use:
	data [1 "text-1" 1 "text-2" 2 "text-3" 3]


The first INTEGER specifies the default value. All labels get IDs. 
This has the advantage, that you can resort the labels but the ID 
is still valid. And this feature you need if you store the selection 
of a radio-group in a database.

on frech  scene we are actually discussing  on the  best  way to 
do a  RTM (Ritch Text Mark) widget.

so as i'm  actually  stuck with the  text cursor full handling concept 
 Coccinelle use this  time to build a widget  based to view algorithm 
 and exploiting VID  cursor concept (T___T CRAPPY  cursor selection 
way  if that could be changed in rebol 3.0  i would be the happier 
man in the world ...)

Just a precision, TDM Style use FACE capability to calculate the 
offset and the size of each items and also to for the caret <> offset 
mapping, but it use DRAW/AGG to display the result. Vectorial text 
is not supported. For this, we realy need the cursor managed by DRAW/AGG.

Impressive effort guys, and while it can enable things like WYSIWYG 
editors and HTML renderers it's not a priority for RebGUI inclusion 
at present. I'm comfortable waiting for an "official" solution in 
R3, but if folks need rich text *now* then they have at least two 
alternatives! ;)

Is there a way to visually select a row in the table widget *without* 
triggering the associated action?

I've added this to rebgui-edit.r feel -> engage -> switch

				alt-down [
					if face/type = 'area [
						face/action face
					]
				]

to allow me to bring up a context menu on the area widget.

Probably a font issue. Try changing font to Arial (set-fonts/name 
"Arial").

No difference .. is Arial a standard Linux font?

Hmm, labels are Arial 12 in VID so the following should work in RebGUI:

	set-fonts/name "arial"
	set-fonts/size 12
	display "test" [label "Text"]

if not, check the font name and size used by VID;

	layout [a: label]
	help a/font

Arial I recall is a windows only font that was supposed to substitute 
for helvetica

I would like to see tab also activate the face action.  I've asked 
this before, and take it that I have to do it myself.

I see a block called action-on-enter, so presumably I create my own 
little list of widgets, and then trap the tab key, and fire the action.

for a block called action-on-tab

Sounds like a good change, feel free to commit it.

I am using the RebGui along with requests to a Rugby server. I am 
able to access functions on my Rugby server when calling from the 
action event of a button. Pretty straight forward. What I would like 
to do is call my rugby function async while on one of my RebGui tab-panels. 
I want to add the call to an event loop somewhere, but I don't know 
where to add it. Can you point me in the right direcion?

Have a look at the 'ex-status text widget in %tour.r and its use 
of rate and feel.

Volker posted a solution to how to insert text into an area widget 
where the cursor had been before it lost focus.  I don't think I 
got it to work properly.  Will there be a way to support this?

problem may be, 'focus makes sure the face/text  and  carfet are 
a string. So when you set caret to  none and  focus, both are strings 
again. Maybe  focus  should  be patched in that case.

Came across this when I clicked too quickly into a field

Means I have to click twice sometimes into a field, but at least 
it doesn't crash on me anymore.

Ashley, I'm allowing users to create their templates by loading in 
their own rebgui display code ( I don't have a fancy layout editor 
like you do!).  This works, but I can't tab between the widgets though. 
 Is there some way I can get the focus system to work on user templates?

Should work, how are you loading and "executing" the templates? Do 
you have a small pseudo-code example?

Sorry for the interruption. Is there a way to link fields in RebGUI? 
I've got an app for volunteer fire departments that needs quite a 
few tabs.  I want certain fields replicated across multiple screens. 
 Right now it is all manual, with code like  set-text i-incharge 
newname  set-text ins-incharge newname etc peppered all over the 
app when I have common fields across screen.

Graham, following code works for me:

	display "A" [
		t: area
		button [display "B" to block! t/text]
	]

so it's not a problem specific to the focus system.

Is there a way to link fields

 Short answer is no, but you can structure your data into objects 
 so multiple widgets refer to the same word or path.

Ashley; I thought through that, but I'm not sure how that would work.

f1: field
f2: field


How could the f1, f2 widgets refer to the same text?  (Text eventually 
destined for a RebDB database)

Again, sorry for the interruption.

Love your stuff by the way.  Thanks muchly.

My next problem is, I want to be able to create a calculation field 
based upon the contents of my custom fields.

For instance, this formula DAS28 = 0.56 * sqrt(tender28) + 0.28 * 
sqrt(swollen28) + 0.70 * ln(ESR) + 0.014 * GH calculates a disease 
activity score in arthritis.

I looked at the nano-sheets but they use 'do which is not going to 
be safe.  Since this is not a Rebgui issue, I'll move this to the 
core group.

re Custom widgets and tabbing. You may want to have a look at the 
following blocks in the edit object:

	tabbed
	hilight-on-focus
	caret-on-focus
	action-on-enter

You can reference these within your init code as follows:

	insert tail ctx-rebgui/edit/tabbed 'my-widget

btiffin, feel free to interrupt, that's what this group is for. ;)

A simple example of sharing the same word is:

	v: "Hello World!"
	display "Test" [
		f1: field v
		f2: field v
	]


but once the display is substantiated then f1/text and f2/text contain 
their own copies of v. Tying them back is a manual process.


If you are copying values between a database and RebGUI "forms" then 
you may want to take a look at the get-input and put-input functions, 
they were added to make forms management easier (it saves you from 
having to assign widgets to words).

This is pretty cool now, I have it working so that a user can assign 
a calculation to a templated field ...

build#51 committed to SVN. Adds a persistent global UI settings system 
with a new request-ui requestor. UI settings are saved in %ui.dat. 
Also modified spinner (replaced two buttons with single left/right 
click button) and slider (allow arrow grouping to be set globally). 
Next build will be a bug fix build (I've hit similar problems to 
Graham with area and drop-list). If anyone wants to create some %ui.dat 
files for WinXP, OSX and Linux (even if the resemblance is only passing), 
feel free to drop me a copy and I'll include them in the next build.

Ashley, I again would like to send you our enhanced version. We have 
extended the RESIZING to include proportional resizing, enhanced 
the widgets, made a new one graph-widget (for graph layouting) and 
so on.

Sure, but manually merging enhancements is a real pain compared to 
SVN development ... hint, hint. ;)