World: r3wp

As for the GUI issues, I am confident that Ashley and contributors 
will fix those issues and so I have released it as is.  I don't resize 
anyway.

I am primarily interested in functionality at present.

Ashley - I know, that is why I posted reply in this group, to actually 
see the reaction of when next RebGUI release is planned, and what 
it will address :-)

Ashley, View 1.3.2? We are already at 1.3.61 or am I missing something?

Seems I have lost track of all the version numbering... just wondering.

erg  .... treeview – data structure should be simple & consistent 
with other widgets ... sub-blocks are the obvious way to go but I'll 
leave the implementation choices to you ;)

we discussed this point  at the treview begining  ...  we have  [[ 
widgets desc ] [  datas to apply to widgets ]] this struct allows 
dynamic datas changes and sortings with low cpu use. treeeview is 
over  code is tiny and all is there to add more dynamic widgets  
but as  we  want to make a grid widget i don't see the meaning of 
adding to treeview the capability to get edit fields  -> note: actual 
fields can be turned as editable on a certain  key + mouse shortcut 
instead of have a special editable widget. Last source are on  http://www.rebolfrance.info/articles/regui-cooking-widgs

Ashley my ask to see those widgets implemented in REbGUI retail as 
it is not to bother you on the contrary the return i get on those 
widget was pretty low... So i think adding them to  retail RebGUI 
 will allow all REGUI fans to see the code to learn some tricks and 
to propose some new things  or bug correcting  ^^ So my ask is more 
 to dynamise and  relaunch the RebGUI process than to be bad with 
you ^^

actually i'm fulltime dedicated to get a job so i'm not a lot around 
there anymore  but i stay tunned time to times and if you get major 
problems you can yeld me by mail etc...

shadwolf, it's easier for us to see them integrated into the rebgui 
distro to try them out.

Perhaps Ashley could include them and mark those not fully complete 
as such?

shadwolf, I'm having a bit of trouble integrating listview52. Copying 
the code and removing all "ctx-rebgui/widgets/" paths gives the following 
error:

** Script Error: Invalid path value: edge
** Where: view
** Near: show face/pane/1/pane


which is odd as your code never explicitly refers to edge. As you 
are more familiar with the code, could you have a quick look at merging 
it into your copy of %rebgui-widgets.r (v 0.3.7) and upload the working 
result.

How do I use the offset for a widget? Where to put it? I want to 
do the following:
wid1 50x50
return
wid2 50x50
return
wid3 50x50


and now I want to place the next widget right to wid1 and inline 
with wid1.

And wid4 has the heigth from wid1 to wid3.

tab-panel: Is it possible to specify a color for the tab text?

label / field: How to create labels and fields that are all the same 
size, automatically? I want all labels to have the width of the widest 
label and all fields to aligan left. For creating pretty input-forms.

Something like guide but more intuitive to use.

How is the default size for a group-box determined? IMO it should 
default to the min-size to include all contained widgets.

there's some config settings in rebgui.r I think

I don't think there's a guide

to get all the field sizes the same, use compose

eg compose [ label "First Name" field (fieldsize) ]

And for the labels? Is there a trick too?

Robert, in answer to your first question:

display "" [
	field 50x50
	return
	field 50x50
	return
	field 50x50
	at 52x0
	field 50x154
]

display "" [
	field 50x50
	field 50x154
	at 0x52
	field 50x50
	return
	field 50x50
]


(the later does not work correctly under 0.3.7 - adding a simple 
"max-height: 0" to the 'at rule in rebgui-layout.r fixes this under 
0.3.8).

same "trick" can be applied to labels

docs: tab-panel and action word isn't very clear to understand. Better 
to provide an example:
	tab-panel data [
		action []
		...
	]

tab-panel: Is there a way to add an action block that's executed 
before switching to a new tab? IMO this would be very handy. For 
example I want to show/hide screen elementes depending on which tab 
the user clicked.

tab-panel data [
action [ print "displaying tab1" ] [ label "Tab 1" ]
]

if you want to change the layout of a tab in the action block .. 
you can.

action [ hide [ btn1 btn2 bttn .. ] show [ btn3 btn4 btnn+1 ] [ ...layout 
... ]

Yes, but this makes a bit complicated. I need to show two tables 
if the user clicks two specific tabs. And hide them if the user clicks 
ANY other tab. And I want to avoid adding an action [hide tab1 hide 
tab2] to all other tabs.

Because if I have a change, I need to touch a lot of code to keep 
this in sync.

I know, I can write a function and just add action [hide-tab] but 
even this needs to be added to all tabs.

that's how I am doing it in my app

I also have a common set of buttons that are shared by all tabs. 
 I detect which tab is visible, and perform the relevant action

I originally had only one action for a common button, and the action 
for that button was revectored on clicking the tab .. but that got 
too complicated too quickly

So the buttons are displayed outside the tab and have a context sensitive 
action block?

yes

Ok, good idea.

Is there a way to specify an input-pattern that is only allowed for 
fields? Like number etc.?

Robert - IIRC not. We just help one longer talk about field masking 
etc., but dunno if anything was implemented ...

Ok, next one: I need to start an action as soon as a field looses 
the focus. Is this possible? I need to trigger a re-calculation.

Hmm... no luck.

field (size) action [...] doesn't work
field (size) [...] doesn't work
field (size) data [ action [...]] doesn't work

How adding this is a generic pattern of function calls? IMO very 
useful:
	inbound-action
	widget-action
	outbound-action

at present actions only fire on enter .. not on tab or any other 
event

I think this should be changed to allow tabs etc.

BTW is this edit-bug with downkey fixed by Ashley?

That plus a lot of other problems with area have been fixed in 0.3.8.

ANd now you release it, sdk is out? :)

I'm just running some last minute tests to see what issues have been 
corrected now that View supports the parent option [again].