World: r3wp

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.

Graham, radio-group fix is up on SVN. To clarify, no initial selection 
is displayed in these three cases:

	data ["Opt 1" "Opt 2"]
	data [none "Opt 1" "Opt 2"]
	data [0 "Opt 1" "Opt 2"]

Great.

Just a suggestion about the spellchecker.  At present the spellchecker 
window pops up for each word. How about the sentence in question 
is displayed in the spellchecker window with the word highlighted 
instead.

Ashley: I don't change the DB layout in this case. I change my code 
and this fixes the positioning change. Same with table columns, I 
just retrieve them in other order.


And we have added SELECT-ITEM to the widget. With this it's possible 
to use the ID not the position because otherwise I have to change 
my code.


Overall, we did it to reduce maintenance hassles and make the app 
more flexible. Maybe only I have this problem... Anyway, I think 
the benefits are much bigger than to stay with the current version.

Graham: Normally a RADIO-GROUP selection is a mandatory choice. Otherwise 
you should use CHECK-GROUP which explicitly supports "no-selection" 
possibility. Hence a default selection was added.

check groups aren't mutually exclusive.

sometimes a question needs to be left unanswered .. hence nothing 
selected.

hmm, but that is how radio buttons were meant to be - always just 
one answer. If you need something like that, I am not sure it is 
good design to have no radio button in a group having selected, because 
you can't do reverse operation - once you click on either option, 
you can't get back to state, where no radio group is selected. So 
- my opinion is, that in such case you should add another option 
to your group, stating "none" or something like that. Well, just 
my opinion ...

Isn't CHOICE-GROUP intended for selections that are optional? I use 
RADIO-GROUP for a mandatory selection and hence a default selection 
makes sense.

choice group??

Sorry, I meant CHECK-GROUP.

Well, I think that there should be some debate before a long standing 
behaviour is changed.  I have lots of users using a rebgui application 
that depends upon the previous behaviour.

just manually downloaded latest SVN changes - gee, the design is 
getting worse and worse. Those rounded buttons are so bad it is not 
really funny or question of ones aestethic feel. RebGUI was initially 
not pretty, but at least nearly XP look. Now it is what?