World: r3wp

Isn't that just a table then ?

tables only have one line I think.

Sorry, I wasn't referring to the actual RebGUI widget set, but implying 
that a general table widget should be able to handle any number of 
columns and rows. Such a widget would be used to do all the display 
work inside your chat client widget.

that may be outside the scope of what Ashley had in mind.

Ashley, what is your internet update idea ?

It is my thought that a widget named "table" does not implicitly 
communicate how many columns or rows it can support. Therefore it 
should handle any number of columns and rows. A table widget that 
has restrictions on these natural variables (which is perfectly ok 
for optimizing or keeping the implementation simple etc.) should 
be named accordingly, eg:
two-column-table
.

the rebgui table widget is not limited in this way.

You're right, I was just checking that !

1) Internet update: include a get-latest.r script that checks which 
individual scripts have been modified (based on timestamps) and downloads 
newer versions, and also handles script additions and deletions. 
Not very automatic, but I don't want it going to the internet everytime 
rebgui.r is run! ;)


2) A chat client widget is a superset of the table widget requiring 
(among other things):

	- control of individual cell font and background color
	- Support for multiple lines within a cell
	- Top, center, bottom alignment support

 - Cell call-back triggers (so if I click on this cell I can fire 
 that function, etc)
	- Probably a whole bunch of other stuff too


Mind you, reading this list makes me think that a chat widget is 
closer to the [yet to be done] grid widget than a table.

1) Please use checksums to check not timestamps. The later will fail 
to often.

you can look at Detective libraries .... there is whole system to 
do automatic incremental updating, signed  code, etc. - nice ....

3) How close to a working SVG renderer are we? ;) I'd really like 
to incorporate scaleable Icons, especially since the Tango links 
I posted previously have all their icons in dual PNG / SVG formats


So as SVG  master (yet again drunk ???? hum yes but that's last year 
night and first new year one so it's allowed to be hum lets say a 
little joyfull ) The answer is  easy SVG renderer is yet fully working 
as the matrix problem was internal to the VM and not to my code I 
simply need to disable the commented matrix line of code in my rendering 
engine and make the testing with the wonderfull, marvelous, extraordinary, 
free of bug version of REBOL/View 1.3.2 (?) The last issue is the 
gradient formating ...  and then we get a full 1 to 1  WYSIWYG svg 
rendering engine. This needs some testing too and some optimisation. 
You know me I seek first of all the full fonctionnality then i see 
if optimisations can be done to enhance the project (and in lucky 
rare cases my brain pop out a yet optimised solution but inspired 
by previous works like for listview widget wich was designed in an 
optimised way beacause of many inspiration projets were yet available 
 for this topic... )


For caret  system yes .... hum this remark was undirectly adressed 
to Carl we yet talked a lot on this topic on View Group last year 
 but it's good some time to recall previous unsolved discution and 
try to see if we can help Carl to change the design at least apporting 
to him some fresh ideas or only poping out why we found it really 
annoying based on our experiences and intents (like my mini ritch 
text editing widget using AGG to render the typed text  for example 
( see AGG group for code it's not long it's not fully working and 
it perfectly show as hard the handle of the caret position is!) .

For ppl interrested in  SVG rendering engine. My  tonight work  and 
 test on the engine   is resumed in the AGG topic. To resume before 
matrix bug as causing bad scale and bad position.  Now we have good 
position but still bad scale  i post screen cap samples and we can 
see that the evolution is good  betwin View 1.3.1 and 1.3.2

Robert, checksum is not as good as size and date because the file 
has to be downloaded to be sure of the checksum, *or* Ashley has 
to upload an index file containing all the checksums for all the 
distro files every time one of them changes.

I make that statement based on the assumption that it is a regular 
webserver and it doesn't have a way of returning only the checksum 
of a file.

However, it can be a good double check after the decision to download 
has already been made and the file downloaded.

I retract that last statement - it implies you know the checksum 
of the remote file.

Yes, but date/time is a no go. It assumes computer systems are in 
sync, and that time-zones are handled correctly. You know, red-icon 
problem?

anton, what is the problem with checksum? It depends on syncing strategy, 
but you have those files on both side (client, server) anyway. afaik, 
the problem with checksum could be its speed. But since we have open/seek, 
we could do checksumming defined,e.g. 3 parts of files, first xy 
bytes, last xy bytes and defined skip somewhere to the middle of 
the file ... dunno if it would work though :-)

date stamp is completly unreliable, especially with rebol. Red-icons 
problem was in detail described, it is in rambo, I tried several 
times to push for someone to at least look into it, but nothing happened 
....

some kind of checksum plus versioning should do the stuff. But maybe 
we should open Syncing channel for such talks ...

Decided to go with a simple manifest / checksum approach. Long term 
we really need something like Anton outlined previously (multi-level 
caching with the option to control it on an app by app basis). Anyway, 
have a try of this:

	do http://www.dobeash.com/files/rebgui/get-rebgui.r


but be aware that it writes its files to the *current* directory 
(as determined by 'what-dir) and replaces any "base" files with a 
differing checksum (so make a copy of any local changes you have 
made and want to keep).


I've also updated the issues log at: http://www.dobeash.com/it/rebgui/issues.html

lotsa opened issues still there :-)

I do not properly understand the need for auto-updating facility, 
unless provided as general rebgui facility = functionality available 
to custom apps too using rebgui ...

I hope it is so ... otoh do you find Gabriele's update script complicated? 
It has anything programmer needs imo in that regard (judging according 
to my first look, no direct experience though ...)

otoh I prefer the get-rebgui, instead of having separate 0.3.0 plus 
the need to copy over newer stuff :-)

Gabriele's update script ... link?

wait a bit - gabriele put all sorts of his utils here linked few 
days ago ...

http://www.colellachiara.com/soft/Libs

autoupdate.r IIRC ...

there is do-thru and launch-thru, to run things in the right folder.

And a do %tour.r on the end would be perfect :)

A mix could be a self-extracting script for base-distro, and then 
downloading the updates. only a single server-lookup and only a few 
bytes more.

Ashley, great that you have made get-rebgui.r. I'm working on it 
to get it to use the public cache and show progress.

I'd like if you could use checksum/secure to generate the checksums 
in manifest.txt, which is compatible with read-thru, load-thru etc.

Also, if your compressed files begin with the 8 characters "rebpress" 
followed by the compressed data, then we can use the /expand refinement 
of read-thru to auto decompress the data for us.

I've come against a strange problem. When I do this
	read http://www.dobeash.com/files/rebgui/dictionary/American.dat

it stops and gives a network timeout after reading 23% of the file.
bytes: 68432 of total: 293605 = 23.31 %

This is repeatable. I tried with read-thru/progress and a simple 
read.
Bizarre

Seems to be pushing through now. Improved my error reporting on the 
way.

Ashley, totally reworked your get-rebgui.r to use public cache:
http://www.lexicon.net/antonr/rebol/rebgui/get-rebgui.r

Excellent work, implementing all your suggestions now ...

Done.

Works well (do http://www.dobeash.com/files/rebgui/get-rebgui.r) 
except that all the files retain their rebpress prefix! ;) What's 
the best/easiest way to correct that?

already fixed?

Or i am in the wrong folder? looks clean here.

Check the contents of public/www.dobeash.com/files/rebgui

i see. messes the filenames

Maybe a misunderstanding. "rebpress" must be the first part of the 
file-content. not the filename

in read-thru:
        if all [expand find/match data "rebpress"] [

            if error? try [data: decompress skip data 8] [return none]
        ]

Doh! Just reread Anton's message above; 'if your compressed files 
begin with the 8 characters "rebpress" followed by the compressed 
data. Fixing now ...

Is the big spellcheck-data needed?

I found this www.as-u-type.com spell checker works with area fields.