World: r3wp

well, so we have altme, even with file-sharing, and we are moving 
to clumsy web methods? :-)

Pekr, I presume you have lots of experience with this tool to make 
this comment.

Ashley (and others): As RebGUI is designed to stay short and clean, 
chances are, that users want to do own custom styles which aren't 
subject to become part of the standard distro but rather be added 
on a per project basis. With the latest change to e.g. SET-SIZES, 
I for now don't see how to do that in a compatible manner:


In case a user likes to have his widgets respond to unit- and font-size 
changes as the standard widgets do it looks like one has to patch 
SET-SIZES, or am I missing something? You reset all standard  widgets 
there in one central location, which is very elegant, but it looks 
as you have no chance of knowing about styles added later with 

        CTX-REBGUI/WIDGETS: MAKE CTX-REBGUI/WIDGETS [... new widgets here 
        ...] BIND IN CTX-REBGUI 'SELF


May I suggest some mechanism in the widgets FEEL, something like 
RESET or RESIZE, which simply get's triggered from within SET-SIZES 
for all widgets. A RESIZE feel function would have the benefit of 
keeping simply size-changing-related calculations out of the usual 
REDRAW which I'd prefer to be reserved for rapid state changes thru 
user interactions and content changes.


Then, in SET-SIZES you'd simply do some FOREACH WIDGET/WIDGETS [WIDGET/FEEL/RESIZE 
WDIGET NEW-SIZE WIDGET/FEEL/REFONT WIDGET NEW-FONT] 


On the other hand, I'm sure you had good arguments on why not to 
feature an explicit resize and refont mechanism. But me I never understood 
why e.g. RESIZE wasn't in VIEW/VIDs shared FEEL contexts, too, and 
now I'm facing kind of a deja vu with RebGUI ... ;-)

Currently, every widget has to be prepared for window-, unit- and 
font-size changes at any time when redrawing. I'd expect them to 
be handled easier and even faster if they'd be slightly more explicit. 
But, as I've said, I may be missing the point here. Eventually you'd 
simply suggest to do 

	redraw: func [face action event] [
		if face/size <> face/old-size [face/feel/resize face]
		if face/old-sizes <> sizes [face/feel/rescale face]
		if any [
			face/font/old-font <> face/font
			face/font <> face/old-font
		][
			face/feel/rewrite font
		]
		:
	]

But it would be kind of boring to so in every single widget.

(Just thinking out loud)

Yet again a suggestion I agree with 100%. ;) By way of explanation, 
the current system evolved from being completely static (all metrics 
/ colors known at object creation) to one that included dynamic offset 
/ size changes (#HWXY directives) and only just recently dynamic 
control over metrics / colors (and as indicated with the previous 
discussion on centralized / shared draw blocks - it still has some 
way to evolve).

Graham - first- I was just making fun without even looking into the 
site, watch the smiley (altough I noticed I am overusing them). OTOH 
I really don't like wiki systems, because most of the time, they 
are not UI clean for me ... it exposes its interface all around. 
The site provided though seems to have nice design ...

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?