World: r3wp

(Just posted table and couple of fixes and enhancments to SVN.)

guys, those of you, working with databases - currently in new grid 
implementation, there are insert column, remove column, swap columns 
functions. Those do physically alter order in block of blocks (data) 
section. Apart from possible speed limitations, do you think it would 
be better to just virtually swap, insert (at the tail), remove (just 
make it invisible), or is it ok?

has it any impact of possible update call to the database? Just thinking 
lound ... hiding columns is ok, but if user changes their order, 
data changes too ....

Short note: Cyphre did, what I call, an input-grid. It's a static 
grid that you can specify which even generates names to access the 
cells. Might be useful in many cases as well.

Hi, I would like to get some feedback on some rebgui-grid decision. 
The thing is, I need to do it till tomorrow, to stabilise a bit and 
go for more final version ....

So - you can look at the latest screenshot here - http://www.xidys.com/rebgui-grid.jpg

The thing is - one one hand, I don't want grid to be as capable (and 
big) as Henrik's grid, otoh it would be good to offer some functionality 
commonly needed for DB apps ....

The issue I am trying to currently adress, is that of (non)modifying 
original data block, and here come some questions ....

currently functions like - swap-columns, insert-column, remove-column, 
work with real data block, whereas sorting column introduces virtual 
adressing. You can still access raw data by going to grid/content/2/2 
or so, but if you want to get sorting reflected, you need to use 
API ....

what I am thinking about is to virtualise even things like insert-columns, 
remove-column (then hide-column becomes redundant), swap-columns, 
so that original data block would not be changed, which can be usefull 
for easy updates to sql directly from data block .... what do you 
think?

I'm doing that in LIST-VIEW and it can easily be done fast enough, 
if you are worried about performance.

you are doing what - virtual access, or raw changes?

although, I can't produce virtual columns

virtual access of both rows and columns

sorry, rephrasing virtual columns: specifically new columns that 
contain new information derived from existing columns

ah .... ok ....

how do you solve possible change to amount of data? My friend working 
with SAP grid suggested to me simply keep index block, and assign 
each record a recno virtually, as with update, in multiuser system, 
there could come some new records, or some may disappear ....

if I have two real columns: height and width, I can't produce an 
area column with the product of the two first columns and show that 
next to the first two columns.

I am not sure I understand :-(

yes, I calculate an index block every time the list is updated with 
new information. I use that index block to display the raw data in 
the sequence I want.

no matter, it's not so important. :-)

in my experience, data manipulation is never a performance issue. 
what is a performance issue, is related to VID and SHOW

that's why I built in options to turn off updating when doing multiple 
operations. by doing that, operations can speed up tremendously.

At what "size" of array do you notice slow downs?  We are about to 
add a simple spreadsheet to Qtask.  We will be facing the same issues. 
 In our case we will be using Javascript on the front end, but the 
issues are similar, we have to decide which parts work on the client 
(virtual as you would say), or when we do a complete refresh.

I think it's depending on view size rather than the number of cells. 
A list with 10x10 entries in a 300x300 configuration can be faster 
to scroll than a 5x5 in an 600x600 configuration. LIST-VIEW uses 
iterated faces to generate the entries, so whenever the list view 
needs to be updated in just one cell, the entire list face is rerendered 
automatically.

also I don't really notice slow downs on very large arrays, because 
I always work from a sorting index, a plain 'pick of the row need 
from the data array. this is pretty fast.

Yeah, that was my expectation.

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 ]