World: r3wp

Robert, is your tool-tip implementation based upon different code?

Oldes - you have a better design we can use?

no, I like the BTN style of button which is in Rebol by default

please change tabs - they look ugly :-)

I'm not sure the tabs look ugly.. they certainly are more visual 
than the previous highlighting.

is there any change?

I talk about the "old version" I posted some screenshots for e.g. 
cyphre's tabs. The visual trouble is, that there is not space between 
them.

before there was a thin highlight to show which tab you were on ; 
now the whole tab is highlighted.

only the small corner "triangle" - few pixels - it does not work 
with darker background ...

I'm quite happy with the visuals at the moment.

I would prefer despaced boxed (not "rounded") design ... or just 
make it usable for dark backgrounds. It feels somehow smeared/blurred, 
dunno ... but - maybe just my feelings ...

ok, I will better first try to download new stuff ...

Graham - you use default white bacground, no? Have you tried darker 
one?

lunch ...

default white

tooltip: I don't know what code is in the offical version at the 
moment. IIRC it's our code. So, there seem to be some other sideeffects 
in the merged version.

Just checked #58 again, and tested Control-S .. not working for me.

maybe I haven't got the dictionary set up correctly.

Ok, need to create a english.dat file and place into the dictionary 
folder.

Ashley, how about including a dictionary directory, with english.dat 
in the svn?

American or British? Dictionaries can be found here: http://www.dobeash.com/RebGUI/edit.html#section-4.2

will you guys build downloadable file once you reach merged and kind 
of stable release?

 Last stable build is #46 available via the View desktop and here: 
 http://www.dobeash.com/download.html


Once the current changes "settle down" (i.e. at least a week or so 
passes without a major new issue/problem) I'll update the stable 
set.

161kB.. it's pretty large
 ... 30+ widgets tends to do that! ;)

I like the BTN style of button which is in Rebol by default

 ... Come up with an AGG (not image-based) equivalent or similar and 
 I'll gladly use that.


re: tabs (and button) look. My previous goal was to try and map the 
look as closely as possible to WinXP. This required a combination 
of images and complex draw commands. My goal now is to keep it as 
simple as possible, with a nice clean look that can be implemented 
with as few effects/draw commands as possible. Button is an example 
of that. Instead of using 3 images and changing them based on current 
button state, I now use a simple draw block and change a single value 
based on state. Note that the radius is customizable (via effects/radius). 
Does this produce the best looking button ever? No. But don't fault 
the technique, rather my [limited] AGG compositional skills! Feel 
free to come up with a better button algorithm.


tabs are another example, where yellow lines of varying length were 
drawn to approximate the WinXP tab look, and had to be cleared and 
redrawn based on state changes. The new approach uses a simple effect 
block ( [round color 5] )where all that needs changing on a state 
change is the color. Same deal as button applies. Come up with a 
simple draw block that creates a good looking tab and I'll gladly 
use that.

Ashley, how to stop defaulting highlighting all the text in an area 
widget on select ?

Remove 'area from behaviors/highlight-on-focus.

Check out the other UI options in %tour.r (by pressing the "Make 
UI Changes" button) if you havn't already. It's easier to set and 
save changes here than trying to do it manually.

Thanks.

Guys, do we have some style, to be able to achieve hierarchy? How 
would you do that? We don't have tree-view .... http://www.xidys.com/rebol-view/image38.jpg

Few minutes ago I talked with cyphre, and he told me, there is a 
tree-view widget for rebgui, as he separated it from other widget 
code. IIRC Graham asked about tree-view widget few days ago. So, 
if Robert will agree with release, cyphre will upload it ...

Robert is appearing to agree... reading the above.

I do.

As I haven't required it yet we haven't splitted it out.

But, hey, Cyphre stop the ticker and do it ;-)

Did the default behaviour of radio-groups change recently?  I think 
if you did not specify a number, or none in the data block it used 
not to set the first radio.

It changed slightly with Cyphre's changes in that not specifying 
a number (or none) now defaults to selecting the first item. If you 
want to start with no items selected then you must use none (0 does 
the same thing, but causes problems for picked and selected until 
a "valid" item is selected ... I'll fix that for the next build).

Fix in that reverts to previous behaviour?  Or, do we have to modify 
all our radio-groups now?  ( got hundreds of them deployed :(  )

Has drop-list changed?  I'm now getting this:

make object! [
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: choose/lines/none
    arg2: 'xy
    arg3: [pair!]
    near: [if v: do to-path compose]
    where: 'action
]

when I click on the down arrow.

Scrollbars no longer appear either.

Ok, further investigation, 'middle and 'upward work .. 'downward 
is broken.

radio-group: As discussed once, radio-group used item IDs so that 
you can change the order or wording of itmes and still select the 
new ones from old saved records.

Fix in that reverts to previous behaviour?

 Do you mean where no number (or none) is specified then it should 
 default to no selection? If so, I can revert to that in the next 
 build.


As for radio-group item IDs, I'm not convinced of the utility of 
that. I don't exactly see people clamouring for item IDs on other 
widgets. I don't know, anyone using item IDs care to explain what 
practical (as opposed to theoretical) benefit they offer?

Has drop-list changed?

 That got a big work-over with Cyphre's changes. Many problems were 
 fixed and enhancements made, unfortunately it seems to still have 
 problems in some specific circumstances relating to where the drop-list 
 is located on the display and how many items are to be displayed. 
 I've "cleaned" (i.e. examined every line of code in detail for errors 
 or possible optimizations) a dozen or so of the simpler widgets in 
 the previous build(s), drop-list is a high priority for cleaning 
 in the next.

has Cyphre already released tree-view?

radio-groups: Ok, maybe my english is bad. Let's try with an example:
	radio-group ["Option 1" "Option 2"]


Now I have to save the user selection into a database. So I store 
"Option 1". 

While further developing my app the code becomes:
	radio-group ["Option A" "Option B" "Option C"]

Now:

- How to restore an older data-record with"Option 1" which now becoma 
"Option B"?


If we use IDs I can decouple the texts from the stored values in 
the DB.

since radio-group/selected saves the associated text, that might 
be a better way to store the choice.  Then make a complementary radio-group/select-item 
n [ integer! string!]

Ashley, yes please - revert to previous behaviour where no number 
=> no selection in radio group.

Can we change the font size etc in a table ?

Yes, I know that might defeat your design objectives for the gui 
:(

radio-group - will do, later today.

table font size - you guessed correctly, it uses the global setting. 
I'll see how easy it is to get font [size: 8] working with it (like 
other basic widgets).

Robert, why would anyone store radio-group text when they could store 
the selection number directly? (e.g. radio-group/picked). This makes 
it very easy to save and load radio-group settings and you don't 
have to worry about label text changes. If the position of the option 
changes you just have to update the underlying DB but that applies 
for plenty of other widgets; if you change the order of your table 
columns, or check boxes, or widgets within a display. I don't see 
why this one case (radio-group) is so different from all others. 
It still won't protect you in the case where the number of radio-group 
options is reduced; and you now have to manage ID changes in addition 
to potential label and positional changes ... i.e. it adds another 
level of abstraction and another level of potential error.