World: r3wp

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?

Ashley has some code that draws the buttons done in AGG.

is #46 really the latest build? I have no experience with SVN.

#58

there's a version of svn for OSX

pity I can't make a screenshot ... will do so at home ...

maybe Henrik is the right person to help us ;-) Chris is here very 
sporadically ...

oh well, a pity I don't know how to use SVN so I can rescue you from 
unesthetical despair. :-)

isn't there SVN web access?

it's called trac.

http://trac.geekisp.com/rebgui/browser

I am new to SVN, I don't know how to configure it properly, so I 
used "Save as" option on selected files ...

it would be logical with a "Make Zip archive and download" button 
on the front page of that file list...

Ashley, what controls the highlighting of the word in the spellcheck? 
 I note the tour demo keeps the suspect word highlighted, but my 
change somewhere doesn't.  Is it an option in the behaviours in rebgui-ctx? 
 Or coded inside the spellcheck function?

oh wow, yes those buttons in #59 are rather alternative...

have you run tour.r? On main screen, the buttons look more like older 
view capsule buttons (IOS). On some other screens, it is not all 
that bad.

well, they look acceptable here, as in they are antialiased, font 
is readable and such.