World: r3wp

I wonder how the different styles will be implemented .. perhaps 
as they do in web browsers?

probably something like that

I hope you are just trying to keep a secret from us all Henrik because 
it would be worrying to think such design decisions haven't been 
made yet.

which ones? :-)

How sttyles will be implemented.

do you think that it will be impossible to make such a design decision?

I was meaning how to enter the different styles inside a text box 
.. would it need a menu bar to pick the different styles

drop downs for emoticons etc

it probably would. there would be great value in a single text editor 
style with toolbar and things.

view [rich-text-editor]

looks nice :-) I think we should do that.

of course it would be nice to be able to cut and paste some rich 
text html and have it come out the same in a rich text box

yes, that would be nice.

I'm surprised how often this actually works with web apps

Pekr


Hi. To answer your question, I was thinking about the WxWidget/Gtk/Tk 
toolkits. They have a basic HTML control. Given the web-rich nature 
of Rebol, this would be a great feature. Not Python per se, but the 
wrappers around those toolkits.

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.