World: r3wp

not sure there is separate tree-view, but I would like to vote for 
one. tree-list might be good code base for introduction of separate 
tree-view?

what does drop-tree do then?

not sure. I can imagine, that it is like drop-list, but instead of 
list you have tree to chose itesm from?

No idea ... is Cyphre around?

I can't see him on ICQ, so probably not currently ...

Would you ask him once he surfaces

of course I will do. I am just catching back, I was away for 3 days 
- I visited Iron Maiden concert in Stuttgart and it was really an 
energy taking experience :-))

Now I'm seeing the same problem in my app.  Windows are just flashing 
open and closing immediately :(

Looks like display/dialog is broken somewhere

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.

There is an intermittent condition which causes modal ( dialog ) 
windows to flash and close immediately.

I haven't been able to reproduce this consistently in tour.r.  Although 
it is consistent in my own application.

Ashley, have you investigated this yet?

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?

Plus grid and chart? ;)

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

drop-tree: Example see documentation. It's quit obvious I hope.

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

drop-tree : what documentation??

The widget list at the rebgui trac site.

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).

Any reason yet why modal windows are flaky in #48 ?

Ashley, sounds good to me. Our approach is not the final word on 
those widgets.

this is cool menu system :-) did not know about it till the mention 
on the EFIKA blog link - http://www.rebol.org/library/scripts/menu-system-demo.r

Yep. Christian is really good in doing widgets.

how old is this?

dunno ...

looks modern enough, so it is rather new :-)

heh, Bobik is demotivated to use Rebgui because 1) text-list scroll 
under the horizont 2) area does not auto-scroll, when you hilite 
text by mouse. It is interensting, how various ppl feel about various 
"details"

is tooltip availalbe only to toolbar, or is it system-wide?

hmm, Cyphre reported that menu system demo is not working with 2.7.4 
... I tried that and got even different message "query has no value" 
....

that's the DO/LOAD bug

workaround is do read <url>

hmm, now I have the same error as Cyphre - "Cannot use path on none! 
value Near: demo: copy/part from system/script/header/version 5"

we can move the discussion to RAMBO group, if the bug is possible 
incompatibility or so problem with new version ...

tooltip: system wide

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

When you click in an area field, everything gets highlighted.  How 
about just putting the caret only?

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.

Hopefully the format would be resistent to version changes.

How does one use the 'inside 'outside for the drop-list ?

Previously the drop-list dropped down, but now they are all opening 
upwards .. how does one control the direction?

Try this ... in tour.r click on one of the modal requesters.  The 
click on the main tabs.  The modal requester usually closes down 
for me.  That should not happen.  Then the modal requesters fail 
to open.