World: r3wp

I could emagine parsing the xorg.conf and look for the font paths...

fonts.cache ?

but thats only for X11

fonts.cache?.. Mmmm..checking..

Yes then you have indeed a font map...

And what about the system fonts for rebol? Will these be ttf one 
day...or is that moved to R3 finaly?

Graham... Is your Synapse-char project still active?

The chat?  No, that has died.

For reasons I don't understand .. it stopped working and I didn't 
have time to debug it.

The source is still downloadable if anyone wants to figure out why 
it no longer works.

aa pitty.. because there is quiet some code in there.. but i still 
have it here..for examples ;-)

I'm sure it will run again with a new database ...

Maybe the amount of data it was transferring was killing Beer .. 
not sure.

because its a nice competitor for altme..(its code is open and adjustable 
;-)

All it needs is to work!

Since it uses the LNS syntax, it should be possible to port it to 
LNS.

But LNS at present can't act as client and server whereas some of 
the things I was doing was using exactly that .. acting as both client 
and server.

For peer to peer file transfer.

Can you tell me how to get to the R2 beta world as I am currently 
spending more time in 276 than I do in the alpha ?

there's no activity now on the R2 beta world

But I thought there was (somewhere) for View quirks under 2.7.6

there are preparations going there for 2.7.7. I can get you in.

I'm trying to use Cypher's drop-down style but it seems to conflict 
with list-view widget. I keep getting: "dragger does not exist"

Anyone know a quick fix to drop-down so that it does not conflict?

skin-slider.r used by drop-down seems to redefine "dragger". I tried 
to rename all references but that did not work.

sorry the actual error is:

** Script Error: dragger has no value
** Where: init-code
** Near: make dragger [
    edge: make edge []
    feel: make svvf/drag bind [
        engage: func [face action event] [
      ...

If there is no easy fix can anyone suggest an editable drop-down-like 
widget? not REBGUI...this project is vid

hmm... it might be a bug in my code.

I'll carry this on in LIST-VIEW.

Hello... I have a general question about the relationship between 
REBOL/View and the ever-evolving-and-ubiquitous HTML-browser...

shoot ...

REBOL/View targets the native widget set of the host and tries to 
provide a platform-independent experience, based on a more abstract 
definition of interface.  This seems to be somewhat redundant with 
efforts like Firefox, Opera, etc.  I curious if REBOL/View would 
be better implemented by targeting an Ajax-like browser that already 
lives on the machine... or if there is a compelling reason not to 
do it that way.

I haven't programmed in REBOL/View but I had experience with Tcl's 
"Tk" back in the day

And they seem analogous.

First - REBOL does NOT link to native OS widget set. We have general 
gfx objects (faces in R2, gob! in R3), and their events. View builds 
complete gfx engine upon it. Kind of XUL for Mozilla, before they 
gave up and linked to native widgetset?

Ok, when I say widget set I mean to say... er... "GDI"

It sounds like you are saying that REBOL, like the Qt library, abstracts 
the widgets and goes to more of a "give me a window and a graphics 
surface and I'll do all my own drawing and event management"

My friend told me - I work with Python, and I can use Tk, Wxwidgets, 
Qt, etc. bindings, while View (VID2) still has many deficiencies. 
And he is right, although partly. We are trapped in our own cave 
- we liked VID/View, for its simplicity. But we were not able to 
provide complete styleset for all those years, because VID2 would 
require complete rewrite (non OS compatible focusinga layer, missing 
rich-text, etc.)

yes, View is yet-another-low-level-gfx-engine-out-there :-)

Yes, I have my own opinions of how to do this right and of course 
I don't think W3C is doing a terribly profound job of it.  :)

Later on, guys improved situation a bit - including cool AGG vector 
library into View ... (www.antigrain.com ). This is really cool and 
puts Cairo into trashcan (which is what they should do in the very 
beginning, except the Mozilla politics)

However, I'm the sort who kind of starts to accept certain inevitabilities. 
 It is inevitable that everyone will have a web browser on their 
desktop, that they are already running, that can do Ajax-like stuff... 
a la Gmail.

so, in fact, REBOL is language like any other out there - we could 
create bindings for Qt etc. too. That is why I said we have two sides 
of one coin here. If View would not exist, we would probably today 
use other gui engine ...

But - that is not full story ....

Seems REBOL could get smaller by embracing that, and becoming a web 
server on the local machine... plus this would put web server capability 
and web forms native to REBOL...

ajax suxx, remember :-)

Inevitability... :)

Next move on our part was supposed to be browser plug-in. And it 
was partly done. You can probably find it via rebol.net and install 
- both IE, NS type plug-in, Windows.

And I still think, View can be used for the good. You can still replace 
it, but maybe we've got some advantages here:

More important than plugging REBOL into browser is probably plugging 
browser into REBOL/View

a la Webkit

View including rebol is still under 1MB - what other language provides 
that? Flash, Silverlight (which needs .Net)? We are "third to the 
game" here.