World: r3wp

I wonder if anything is going to be done to support the windows tablet 
os

with inking support

I don't think RT will do that on their own. That would be a third 
party project.

as long as there hooks to make this possible

I think that as long as a driver can be written for a device, R3 
can support it.

and simple things like right click on a text box brings up copy/paste 
support

being different has its drawbacks when writing application software

when you don't support standard system widget functionality

Henrik: Is your VID-LIST  going to be built into VID3?

when the menu style has been implemented, then it will be possible 
to use popup menus.

daveC, no, it's too complex and not very well written, but Gabriele 
and I will take the features one by one and reimplement the most 
important ones. LIST-VIEW takes up almost as much source code as 
the entire of VID3.

LIST-VIEW doesn't follow the 80% rule.

Ok. nice to know that it's going to be there in short form.

but won't v3 be so efficient that you can rewrist list-view in one 
page of code??

:)

it will be essential, so yes, it will be made. there is a simple 
text list now that has multiple resizable columns, very small (and 
ugly in appearance) and fairly fast.

graham, I wouldn't be surprised if it could be reduced to 20-25 kb 
of code, even with all features.

That it good to hear. For DB work we need that type of function.

LIST-VIEW is also very monolithic. the filtering and search functions 
don't really belong there. we need to separate that to make it more 
flexible for cases where you only need filtering or searching but 
not display.

and then R3 LIST-VIEW would just display whatever is fed to it. that's 
a smarter way to do it.

Hmm

which means 2 copies of the data

well, you can't avoid that

and it won't matter much when GOBs are so much more memory efficient.

sorting is different then?

I imagine we'd use a sort index like now and just point to the different 
lines in the data block as the list view is rendered.

but nothing is written yet. Gabriele probably has much better ideas 
than me on how to do it fast and efficiently. :-)

2 copies of data? That definitely sucks.

I think that you guys should be inspired by cyphre's grid for rebgui, 
which he was paid for, but sadly it did not get utilised :-) Grid 
has to be able to display data right away from the result of SQL 
query, period.

I pushed Cyphre to give me virtual columns, so I was able to hide, 
insert columns, have columns with other functionality, but those 
were kept outside the main data block.

But I refuse to obtain long data list from SQL query and to reorder 
it just to get it displayed.

We need data composition dialect upon the basic grid engine :-) You 
would create virtual table for grid, which in fact could be composed 
from multiple tables :-) All operations, as moving columns, rows, 
etc., has to take care of indices at those particular target places.

I don't remember correctly, but when we were presented IBM Business 
Warehouse (BW) system, it did exactly that. It created kind of virtual 
SQL server, you could have views, queries, etc., and underlying engine 
had connectors to other dbs. From the BW user pov, the user talked 
to just one SQL server, the virtual one ...

2 copies of data: 1 block to manage, the other is the GOB arrangement 
for display. how will you avoid that?

Gob arrangement? Dunno. But you try to suggest, that when you have 
1000 rows as a recordset, you have 1000 rows od another data for 
the display? :-)

never said that. I just wouldn't want to manipulate the data directly 
from the gobs.

besides, the discussion is invalid until Gabriele decides how it 
will be done.

there should be two styles anyway - text-list, and grid ....

There was a grid cotrol for VB, TrueGrid from Apex Software; it had 
a callback mode, where it requested data dynamically (like LIST) 
and fired update events if the user edited something. The only data 
it need to duplicate, IIRC, was for the set of displayed rows.

I should say "currently displayed rows".

the one we used, did dynamic caching. I mean - only the visible window 
was drawn, nothing which was supposed to be clipped. So in some way, 
it was dynamic too. It kind of kept "virtual data window" upon your 
data-set, and according where you moved, it moved too. This aproach 
allowed to display million of records. Of course, that was DBF era, 
not SQL one. But even SQL has cursors ...

regarding Henrik's blog, i should note, that being semantic is what 
i was suggesting with my old notes about how r3's gui should be. 
that would give us a great power... but many people are against it, 
so it won't happen soon.

Gabriele, the Fleecy Moss part?

Do you mean that a button will now just be a button ?

i mean, that the app programmers only specifies what he *means*, 
not what the UI should look like. "I want to get a string from the 
user". "I want to get the name and birth date from the user, and 
show the age". how this looks depends on 1) the look defined by the 
gfx designer (which can be the programmer himself, if he is able 
to do that too) 2) user preferences, to the point that an advanced 
user should be able to edit the UI.

Gabriele - what you describe is nearly possible with VID3, although 
I remember there is more to the concept you are describing. But, 
so far, how 'look is specified - it is not only look. It is so rebol 
related, that hardly any gfx designer will be able to define look 
of the styles.

I don't ge this - here's what I'd do:

Use CSS 2.1 styles on widgets. Create widgets ("classes") in VID-the-sequel 
and render them to Rebol or XHTML + Javascript. That way you can 
mobilize the entire web community to get a UI that renders both to 
a RIA and to the web.

Maarten - but does CSS allow you to define how your style behaves? 
Or is it plain and ordinary - hilite here, hilite there?

How you do such thing as drag & drop of an icon, where icon look 
during the drag period, if it animates, screams at you, whatever 
:-), is dependant upon VID stylesheet?