World: r3wp

If you want to scroll through 1.000.000 lines, you need to virtualize 
the data stuff anyway.

And, I find it simpelst to have the data on the screen and in the 
program in sync. Sorting should alter the data block as well. If 
I pick the first line, I want to pick the first record. Of course 
using an API for indirection is OK too. But than do it always and 
for everything. No direct access to the record data.

otherwise you will have side-effects the developer must know about... 
and that's maintenance horror.

I really have to think about it. One of original concerns was, that 
grid should be able to display direct data block return of sql query 
(so block of blocks=rows)

... without the need to adapt block to any other format. However, 
I think I decided to not modify original data block, and one of the 
reasons is easy call to update sql from the row. If I let user change 
order of  fields directly, the update could be a bit tricky, without 
knowing which field is on particular position.

If I let user change order of  fields directly

 ... is this a requirement? I've never met an end user who ever wanted 
 or needed to change order of columns ... good UI design will present 
 only the columns and rows needed, and in the most appropriate order. 
 "Appropriate" could be by order of importance, logical sequence (e.g. 
 street number followed by street name), or tied back to an "external" 
 order/sequence (e.g. another application, paper-based forms, etc).


I think something like grid is far easier to over-engineer than under-engineer! 
;)

Ashley - I don't know how many users you met, or how are particular 
users' habits in various countries, but I can guarantee you, that 
we had pretty powerfull grid even 10 years ago in Clipper (DBase 
era). I should dig some app and make a screen-shot probably :-) Even 
in DOS, our grid allowed to freeze some columns, each user could 
set its own column order, add available column or hide it, set column 
width, and save it - for each DB. It was pretty heavily used.....

I'm constantly reordering my columns when looking at databases

Ashley is making the same point I am, "end user" vs. programmer (or 
tech).  Any time a programmer says "I do X all the time" all I think 
is that if "I can bottle the exact opposite of X I can make a billion 
dollars."


Hence I wrote above "The exception is when people are dumping databases, 
and those are not using formulas, but rather are for working out 
data.  This is done by programmers, not by users in general."


Never-the-less, if the goal here is the goal, which is for technical 
people to do this, we all still need a solve, which is speed to do 
it.


In Qtask we did part on the server, and part on the client.  So, 
we let you sort columns locally, but would send all the data to the 
server.  What we learned is:

The server would send down all the data.  Slow, but needed.
Then JS would arrange everything into a table.  Slow but needed.

Then JS would sort.  And we allowed 4 levels of sort… Slow, slow, 
slow, and turns out, not so needed.


It turns out that with anything more than about 20 lines it was better 
in the long run to just sort form the server side.


This is not to say this is how this will work where with Rebol.  
My point is more to the idea of playing with UI until you strike 
the right balance of speed and convenience.

Just noticed that we don't have a request-text requester

.

One I hadn't seen before ... 
** Script Error: foreach expected data argument of type: series
** Where: next-field

** Near: foreach sibling siblings [if target: any [tabbed? sibling 
into-widget/forwards sibling] [
return target]] all
** Press enter to quit...

Was just tabbing thru my windows on my desktop...

How can I access (further parametrise widget) in terms of display 
code? E.g. simple color change - I miss something like VID's 'with 
directive ...

the only thing I came up with is using 'do [show-color widget value]

text "blah ... " font [ color: red ]

Why does table/selected/n not work?  I have to do .. pick table/selected 
n

Is it because it is a function and not a path?

that could be a reason

A little confusing ...

How does one display a window so that it stays in front?

display/dialog doesn't work for me.

Graham - are you missing a ' or : in your question above?

if "pick table/selected n" works, I think you should try "table/selected/:n"

because "table/selected/n" means "pick table/selected 'n", which 
doesn't seem right  =^_~=

Sorry, it was a math thing ...

I think it doesn't work because it's not a path

Graham - I mean - how do I know, what facets are exposed to 'display 
dialect level? My friend simply asked me, if there is alternative 
to VID's 'with keyword with raw access to widget internals ...

how do I know?

I ask Ashley :)

Lines 308-337 of http://trac.geekisp.com/rebgui/browser/rebgui-layout.r
plus any widget specific attributes from http://trac.geekisp.com/rebgui/wiki/WidgetList

Cyphre and I have continued to fix bugs and enhance RebGUI. We still 
have some bugs to fix but than it's time for a new release. As new 
widgets we have done a CHART widget that lets you do bar, pie, torus 
charts.

The CHART stuff is based on draw.

nice ... I am working on initial doc for grid, however I am more 
than one week late ... hopefully I will be able to release it in 
3 days ...

btw - combo-box - you can still scroll under the horizont - the bug 
that was there with table too ...

some way to ensure a window stays in front would be nice .. ..

Does that by default:

	display "A" [button "A" 40x40 [display "B" [button "B" 20x20]]]


Click button A, then B, then A again ... at least that's the way 
it works under 1.3.2.3.1

display "A" [button "A" 40x40 [display "B" [button "B" 20x20 [ display 
"C" [ button "C" 10x10] ]]]]

It doesn't for me ... button C will not stay infront of button B, 
but will stay infront of button A

ie. both stay infront of A, but C does not stay infront of B.

>> rebol/version
== 1.3.2.3.1

Easy enough to do ... just change line 83 of %rebgui-display.r to 
read:

	... reduce ['parent last ...


Consequence of this change (in the example above) will be that closing 
window B will close C. I'm loath to introduce specific 'parent declarations 
... how about a refinement that overrides the default "parent is 
first" behaviour? e.g:

	display ...	-> the default, parent is first window

 display/parent	-> parent is last (usually previous/calling) window

if C stays in front, then, closing B causing C to close is okay with 
me.

Actually, a refinement would be good having tested the change above 
which does not suit.

Added rev#31 with above refinement change to SVN.

radio-group: I think we need to enhance this widget by introducing 
an ID per selection option, that can be stored to a database. If 
you store the text, problems araise if the text is changed. If you 
store the selection poistion problems araise of the order is changed.

What do you think?

I'm happy with the current behaviour.

I'm not sure what enhancement you are proposing.

radio-group data ["Option 1" "Option2"] while developing your app 
becomes radio-group data ["Feature B" "Feature A"] 

How do you handle old records?

I use the index