World: r3wp

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?

What have we gained by turning buttons into draw blocks, instead 
of using images? I mean - how many kb of memory or what was initial 
intention of the change?

Why panel and group box are rounded, while tab-panel is square?

I think that Rebol community really is in need of getting some graphician 
on-board. Not only for RebGUI, but for future VID too ...

this type of thing is actually subjective...

some love glayout's looks, some like what it could be, some don't 
like the gel type buttons... some people don't like apple's aqua.

Ashley did say that if someone could provide an aesthetically pleasing 
draw block - he would use it.

I haven't checked up on RebGUI lately. Does it look the same?

not, definitely not, Henrik - it looks inconsitent.

Maxim - your glayout looks consistent, as buttons fit the rest. Current 
RebGUI buttons are a bit ... ehm, strange ...

so far, the best Rebol related designs, for me - Henrik's stuff, 
Detective, Cyphre's styles pack - compact designs ....

hmm... aesthetically pleasing draw block, you say? how does that 
work? do you skin RebGUI that way?