World: r3wp

if SHOW was much faster, LIST-VIEW could be insanely fast. you could 
probably easily scroll a 50x50 array in fullscreen 1024x768 at 25-40 
fps. I've noticed that when doing manipulations when not updating, 
such as sorting and moving entries in one go, these things are close 
to instant. The MOVE-ROW-UP/DOWN operations work like that.

I find that having looked at thousands of spreadsheets, most are 
not larger than 50x25, or 25x50.  The exception is when people are 
dumping databases, and those are not using fomulas, but rather are 
for working out data.  This is done by programmers, not by users 
in general.

Reichart - there is problem with capability of show refresh. Cyphre 
told me he has it much faster already on his hd, we just need to 
wait for new View release. The quesiton is, if it will be in 1.3.3, 
or R3 ..

Yeah, since I don't know how slow we are talking here, it is hard 
for me to know where the slow down is felt.

probably somewhere around 2-5 fps with a fullscreen list.

Yeah, that is slow.  8fps is my normal cut off (anime rate).

Petr: IMO you need to decide, do you have all the data in memory 
or not. If it's up to 10.000 lines and 10 columns you shoul be able 
to do this. Than per line one block. Either have the block contain 
only values (that position matters) or use a name/value pair. Than 
it doesn't. Going for name/value pairs with hash! should be pretty 
fast.

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.