World: r3wp

This is something that potentially affects many list-type gadgets/widgets.

You want to be able to connect the widget to your original data, 
without expecting it in any format, but also provide the widget with 
a function which maps the desired cells from each row into the form 
the widget likes (for its "view" of the data).

(As possible with the original VID list style.)

But I think you're right, the fastest thing to do is derive your 
own drop-list widget.

Can the data change while the drop-list is open ? ie. you click the 
down arrow to open the list, then some other asynchronous event in 
your program changes the data and asks the drop-down to refresh itself. 
(This is pretty extreme, but, just in case.)

Ok, so DROP-LIST calls CHOOSE, passing it DATA.
Then CHOOSE makes a popup FACE-ITERATOR, linking it to DATA.

The FACE-ITERATOR's PANE function just assumes the data is one item 
per row. (Or shows each complete row of the data.)

Robert, I have it working. I derived 
	drop-list.r -> drop-list-Anton.r     3 lines changed and 1 added
and 
	choose.r -> choose-Anton.r     1 line changed

Official CHOOSE probably doesn't want to be modified, but you could 
just add the modified CHOOSE function into the drop-list.

I will post it privately to you unless anyone else is interested.

Another way of achieving the same effect is to simply populate %locale.dat 
with the required language/domain specific substitutions and let 
layout do its thing. e.g.:

	words: [
		"AAA" "My-AAA"
		"BBB" "My-BBB"
	]

then:

	drop-list data ["AAA" "BBB"]


I just don't see how changing radio-group and drop-list [only] solves 
anything. What about text-list, table, drop-list or any other widget 
that display's a value or values?

Well, it would solve Robert's immediate need from real life.
But it does beg for a more general solution.
Maybe each iterating face can have an optional map function.

Ashley, for tables I have always a hidden column with a record ID. 
This ID is used through all the program.


For drop-lists I "store" the text of drop-list/picked at the moment. 
Hence if you have several languages, at one time you store the DE 
version at an other one the EN version. So, one solution is, I have 
to translate to the "master" language that's used in the database.


But what if syntex changes? Than I have to update all old entries. 
Using IDs frees me from this but adds an other level of indirection. 
The common way would be to normalize my database model and use other 
tables to get IDs, and than store those etc. IMO that's the way to 
make apps complex and slow.

We have added a more "spophisticated" I18N system to RebGUI, that 
can handle not only strings in layout but at all places in the program.

If that's the case, then aren't ID's a moot point? (i.e. the issue 
you seem to have is internationalization, not ID's).

It's two things: position and text independend (which solve I18N 
as well) storage.

Fonts: I want to get some text / labels in "Arial Narrow" on the 
screen. How do I do this? I tried but don't know what I need to do.

Robert - what is your level of multilang apps? Only data, or also 
UI?

I am not e.g. sure I would use native RebGUI localisation, because 
it goes from messages, UI elements, to of course data. And as for 
data, you have to establish the concept yourself.

e.g. you have a list-box for fruits: ["apples" "bananas" "cherries"] 
.... that can't be sufficient in any way - it could be, if those 
"texts" could serve you as index to some localisation table:

langs: [cz "Cesky" us "English" de "German"]
fruits: ["apples" "bananas" "cherries"]

trans: [ ;table-id (name), lang, key, translation
fruits  [
    cz  [
       "apples" "jablka"
       "bananas" "banany"
       "cherries"  "tresne"
    ]
 ]
] 

select trans/fruits/cz "apples"

just an example (not practical one :-)

but above would mean, that every translation for all tables would 
be in one 'trans table - not sure it is practical. Another model 
- simply have langs table, as in above example:

langs: [cz "Cesky" us "English" de "German"]
fruits: [
1 uk "apples"
1 cz "apples"
2 uk "bananas"
2 cz "banany"
3 uk "cherries"
3 cz "tresne"
]

select * from fruits where language = 'cz'


That is more practical - simply use one more key - that of your default 
or selected (preferred) language ...


In some sense, you don't need IDs, but I prefer to have one- it depends 
what kind of databases you use. But - it is surely nearly INSANE 
to use text, which can eventually change, as a key value (e.g. because 
of typo and later need to change that text)

want to get some text / labels in 
Arial Narrow""

	text "Some Narrow Text" font [name: "Arial Narrow"]

assuming you're on WIndows and that font is available of course.

I18N: We have written an own I18N system, that can handle all UI 
aspects dynamically. Table columns, drop-list data etc. Works very 
well. And it can be used not only inside GUI stuff but through the 
whole code.

For example you just specify the "master-language" drop-list data, 
provide a translation and it will change on the fly.

what is that cryptic l18N word?

If I need to translate UI, drop-list elemetns plus whole data, I 
refuse to use external system for it - it belongs into tables with 
other data, at least if it concerns data itself. UI elements can 
be in catalogues, no problem here. But - whatever works for particular 
usage case is ok ...

I18N = internationalization

There are screenshots of a RebGUI and RebDB app posted at
http://peoplecards.ca/rebol/vidpics

Nice work, Brian.

Thanks.  This is posted more to support Ashley, and show off RebGUI. 
 I'm a big fan of
RebGUI.  :)

that's just cause you never tried glayout  ;-)

<joke>

brian: looks like a large app!

About 600k of sources, 5 meg total with satelite maps.

I've started playing with Glayout.  In prep for usage docs... :)

600k sources!

with SDK code? or rebgui and other public includes?

public includes...A few REBOL games etc...

All with DO.  Didn't have the SDK when I wrote it.

games?

Links to rebsites...planetary defender, etc, that ended up in the 
cache...

I didn't show the spreadsheet screen shot.  I noticed it had some 
real $ amounts shown.

not sure I grasp what you mean by the cache... you mean the rebol 
sandbox is 600k ?

No from DO-THRU

yes exactly.

thru, stores stuff in the "sandbox" which is the cache... same thing... 
just wanted to be sure we meant the same thing.

Ok.  Learned a new term today.  :)  Thanks.

Very cool Brian.

I posted that for Ashley's sake.  RebGUI RebDB is a nice little app 
building combo.

I kinda wish we could Print with REBOL.  Posting through the browser 
is kinda...I don't
know.  Not quite right.  :)

Thanks for the link, I've updated the RebGUI home page with a new 
"SItes using RebGUI" section (and removed the long-dead link to this 
AltME group as we don't seem to be broadcasting anymore ;(  )