World: r3wp

The first step to getting the collaborative documentation up is to 
migrate the widget specific documentation across; and this gives 
us the opportunity to reformat and expand upon the content. But what 
template to use? If you have an opinion on this then cruise along 
to http://trac.geekisp.com/rebgui/wiki/WidgetList#areaand click 
"Edit this page" to play around with the content and formating of 
this single entry (area). Once we are happy with the format I'll 
use it as a template to bring across all the other widget descriptions.

Can you make it so that each widget drills down to the source for 
that widget?

In the works. I've already restructured the source by removing each 
widget (from %rebgui-widgets.r) to its own <widget>.r file under 
a new %widgets/ directory. Next step is to create a link to each 
source file under its matching WidgetsList Wiki entry.


I've also created a monolithic script (striped output from prebol.r) 
which resides at: http://www.dobeash.com/RebGUI/rebgui.zip


The intention at this stage is to have multiple source files that 
can be collaboratively worked on, with a "build" every so often to 
merge them into a single script for easy access / deployment (not 
everyone will want to grab the source from SVN). The fact that each 
widget resides in its own source file now makes it very easy to "plugin" 
additional widgets.

I guess this means that other widgets that have not been "approved" 
can be uploaded .. but not included in the final distribution until 
finalised.

svn can also be setup to allow alternate distributions ...

Yes to the first question, with six widgets not making the cut (I'll 
upload them later):

	area2 (area plus horizontal scroll ... does not work correctly)
	auto-fill (needs to be reworked)
	list-view (code needs a bit more work)
	spinner (not completed)
	icon (awaiting SVG renderer code)
	svg-tool-bar (awaiting SVG renderer code)

Alternate distributions: let's keep it simple for the moment ...

How to clear the text in a title group?


title-group/text: copy "" show title-group doesn't work as junk is 
still left on the screen, and there's no title-group/text/line-list 
attribute to set.

also, tried title-group/pane/text: copy ""

Added a reproducible defect into the trac ...

this is a temporary "fix" for line 549 in rebgui-edit.r

if none? caret: caret-to-offset face view*/caret [ return ]

title-group: show-text works with the body, while you can do a:

	insert clear tg/pane/text "New title"
	show tg


to change the title. Note that this will not cater for a change in 
number of lines.

Hmm.  I'll still getting garbage characters in the main text area.

Can you reproduce the problem with the title-group in %tour.r?

Yes.

I named the title-group tg, and I have a button "clear" [ set-text 
tg "" show tg ]
It does not clear the text cleanly.

That's odd. Changing "" to " " works fine (I tried copy "" but no 
luck). At least it's easy to reproduce! ;) I'll take a look at it 
over the weekend when I get some time.

I've made a trac defect entry for this issue.

I put up some preliminary changes to the modal popup handling for 
RebGUI. By manually replacing the original files (but keep them in 
a safe place!) with


 http://www.diefettenjahresindvorbei.de/www/rebgui/rebgui-widgets.r

 http://www.diefettenjahresindvorbei.de/www/rebgui/rebgui-dialog.r


you should be able to try them. You'll notice a different and more 
common behaviour of drop- and edit-lists. For the existing styles 
as can be found in the tour script, I haven't experienced unexpected 
results so far. But I'm curious to hear if incompatibilities arise 
in more complex applications that need to be addressed.

Oh, what silly bugs I left in my code! So, don't take it too serious 
for now ...

Graham - not sure if the problem with the clearng of text area but 
most often I almost always set line-list to 0 each time I clear a 
field  so that might be the issue your seeing.

In this case, there is no line-list attribute :(

huh? every face has a line-list attribute.

line-list is the culprit. Replace the 'show-text and 'clear-text 
functions in %rebgui.r with the following:

show-text: make function! [
	"Sets a widget's text attribute."
	face [object!] "Widget"
	text [any-type!] "Text"
	/focus
][
	face/line-list: none
	insert clear face/text form text

 all [face/type = 'area face/para face/para/scroll: 0x0 face/pane/data: 
 0]
	either focus [ctx-rebgui/edit/focus face] [show face]
]

clear-text: make function! [
	"Clears a widget's text attribute."
	face [object!]
	/no-show "Don't show"
	/focus
][
	face/line-list: none
	clear face/text

 all [face/type = 'area face/para face/para/scroll: 0x0 face/pane/data: 
 0]
	unless no-show [
		either focus [ctx-rebgui/edit/focus face] [show face]
	]
]

ashley, are you still interested in list-view?

Yes, but it's still evolving isn't it?

I want to get SCROLLER out very soon, so it will be rid of VID dependencies

it's still evolving. I wanted to see if the interest had faded.

Small question.  I try to insert a list from a select in Rebdb into 
the data block  of a rebgui table.  It does give me an error in RebGui 
: invalid data block.  I did try to call the variable (''do'' does 
not fit the bill here, is it?).  The same example from the rebgui 
tour would be a: [1 "One" a] and ex-table: table (tab-size - 48x18) 
#WH options ["ID" right .3 "Number" left .4 "Char" center .3] data 
:a.   From start I would like to populate the table from RebDB, and 
from there my block is valid.  I am trying to make an example of 
a small phone book using rebDB and RebGui, it could be usefull as 
an example working app.  But it has been some month I did not touch 
the keyboard.  I do get rusty.  Thanks for any help on this.

oups! The answer is trivial () as in a: [1 "One" a] and ex-table: 
table (tab-size - 48x18) #WH options ["ID" right .3 "Number" left 
.4 "Char" center .3] data (a).

You can even take it a step further and replace (a) with the database 
call itself; e.g. (sql [select * from t]) ... just make sure you 
either use compose/only to keep the result set as a block or compose/deep 
with embedded block; e.g. [(sql [select * from t)]

Is there a reason why if you use vid and rebgui together, and when 
you have windows from both open, if you open a rebgui window from 
a vid screen, it opens infront of the existing rebgui screen and 
not the screen that called it?

eh? confusing.. "screen" or "window" ?

screen = window

Is there a reason ...
 not by design! ;)

Can it be fixed if you can confirm it?

tab-panel: Autosizing doesn't seem to work. Using -1x-1 gives a small 
tab-panel, showing only the first tab.

And a small piece from the second tab.

Graham, that's because all RebGUI windows displayed became children 
of the first RebGUI window opened after the splash screen automatically. 
Currently, there is no /PARENT refinement for DISPLAY, but that should 
be easy to add.

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.

Do you imagine a lot of names? Or is there a more systematic way 
to do it?

contexts? panels?

overlooked its rebgui. but works there too?

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

Even if you bind them somewhere else?

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.

layout [
	name: field
	surname: field
	... hundred more ...
]

my-layout[
 part1[ name: field surname: field]
 second-hundred[ name: field .. ]
]

->

 part1: context[name: surname: none lay: [name: field surname: field]
append lay part1/lay
..
?

Hmm... This will than need some path notation to get there. This 
leads to database column names like: part1_name etc.

I thin I will go for an abstract solution and just use:
g001
g002
...
g100

and keep the mapping somewhere else.