r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

Graham
11-Oct-2007
[4990]
I wonder how the different styles will be implemented .. perhaps 
as they do in web browsers?
Henrik
11-Oct-2007
[4991]
probably something like that
PeterWood
11-Oct-2007
[4992]
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.
Henrik
11-Oct-2007
[4993]
which ones? :-)
PeterWood
11-Oct-2007
[4994]
How sttyles will be implemented.
Henrik
11-Oct-2007
[4995]
do you think that it will be impossible to make such a design decision?
Graham
11-Oct-2007
[4996x2]
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
Henrik
11-Oct-2007
[4998x2]
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.
Graham
11-Oct-2007
[5000]
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
Henrik
11-Oct-2007
[5001]
yes, that would be nice.
Graham
11-Oct-2007
[5002]
I'm surprised how often this actually works with web apps
DaveC
11-Oct-2007
[5003]
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.
Graham
11-Oct-2007
[5004x2]
I wonder if anything is going to be done to support the windows tablet 
os
with inking support
Henrik
11-Oct-2007
[5006]
I don't think RT will do that on their own. That would be a third 
party project.
Graham
11-Oct-2007
[5007]
as long as there hooks to make this possible
Henrik
11-Oct-2007
[5008]
I think that as long as a driver can be written for a device, R3 
can support it.
Graham
11-Oct-2007
[5009x3]
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
DaveC
11-Oct-2007
[5012]
Henrik: Is your VID-LIST  going to be built into VID3?
Henrik
11-Oct-2007
[5013x3]
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.
DaveC
11-Oct-2007
[5016]
Ok. nice to know that it's going to be there in short form.
Graham
11-Oct-2007
[5017x2]
but won't v3 be so efficient that you can rewrist list-view in one 
page of code??
:)
Henrik
11-Oct-2007
[5019x2]
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.
DaveC
11-Oct-2007
[5021]
That it good to hear. For DB work we need that type of function.
Henrik
11-Oct-2007
[5022x2]
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.
Graham
11-Oct-2007
[5024x2]
Hmm
which means 2 copies of the data
Henrik
11-Oct-2007
[5026x2]
well, you can't avoid that
and it won't matter much when GOBs are so much more memory efficient.
Graham
11-Oct-2007
[5028]
sorting is different then?
Henrik
11-Oct-2007
[5029x2]
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. :-)
Pekr
11-Oct-2007
[5031x6]
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 ...
Henrik
11-Oct-2007
[5037]
2 copies of data: 1 block to manage, the other is the GOB arrangement 
for display. how will you avoid that?
Pekr
11-Oct-2007
[5038]
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? :-)
Henrik
11-Oct-2007
[5039]
never said that. I just wouldn't want to manipulate the data directly 
from the gobs.