World: r3wp

Our internal demo program (as shown in my first video) has slots 
for these parts, but they are not in use yet.

amacleod - services are in rebol in general (rebservices, aka LNS), 
and they will be supported by R3 too. But - as for "rebol browser", 
so far I can once again see only business graphics being a target. 
      More casual design should be possible though.

Pekr, I understand Services will be there in R3 but Carl blogged 
about this concept of a button linking to the www...It was a little 
vague and Henrik did try to clear it up buy the new GUI seeems void 
of this..

I thought it was to be tightly intergrated into the gui and a major 
reason for the delay of vid 3.4. I thought it was a bold new step 
in the concept of GUI's but it does not seem to be a part of what 
we have been privy to.

Henrik, I'll have another look at that video but I do not recall 
what you are refering to.

Is that "Triggers"

It would be "Document"

amacleod - I can see no problem with what you describe and with what 
is currently finished. Look - the concept of top level (VID) "reactors" 
is already there, is extensible imo, and that is all that is needed. 
Rebservices are imo underneath, and are going to be called by reactors 
like 'submit for e.g.

What I can't imagine right now is the browser concept. Well, it is 
a layout window, it can be for e.g. a panel. But when you look at 
various web sites, e.g. news portals, you can see that their design 
is more "free form", or casual, dunno how to express it precisely. 
So - what would you need to mimick for e.g. www.OSNews.com ? Define 
few styles, decide upon the columns design (group, panel), prepare 
styles for particular sections/zones (portlets - IBM, web parts - 
Microsoft, iViews - SAP terminology) and fill them with information 
....

The questions is probably whether you would want to accurately mimic 
websites. I think that misses the point of the rebol browser. It 
doesn't mean we shouldn't be able to mimic websites, however.

What I hate about many websites is that they have very inefficient 
layouts. This is particularly so for forums and certain newssites, 
where perhaps 10 or 20% of the information on the page is relevant 
to you. Now imagine AltME's GUI inside a webpage. It's very efficient.

One of the saddest tricks nowadays is to divide a small 2-300 word 
article on a news site into several pages, so they get more ad-visits.

yes, you describe some bad aspects of web trend. But the layout is 
there. The problem with my understanding of what will be needed to 
be done in VID is, that nowadays web is not only about laying out 
some images, links, texts, but e.g. even simple menu is JS nowadays, 
not to mention AJAX junk ....

Other differences are - content is separate from presentation with 
html/css combo. Loading of website content is async, whereas VID 
(at least VID2) displays page only once all stuff is downloaded. 
It has to change ....

Pekr, you are still thinking in terms of ordinary webpages. That's 
shortsighted. :-)

OK, so what concept do you actually envision for so called REBOL 
browser? :-)

Kind of Flash, Silverlight? Rich, media apps?

Pekr, let's say you want to read a blog post on a "rebpage". Would 
you want to download a rebpage, formatted as a webpage from that 
location or would you want to get a custom fullscreen reader that 
downloads only the compressed plaintext as makedoc format, compiles 
it on the fly and displays it?

and updated through services???

of course

You can work like this now already with R2. Just 'do a script from 
some webserver. Works the same way.

Doc style now exists:

http://rebol.hmkdesign.dk/files/r3/gui/083.png

so, it's a form of make-doc?

ie. not wisiwyg?

Well it says at the top "Simple document markup mehtod that uses 
MakeDoc format." Hardly what I was expecting for "RichText".

Me neither.

But - rich-text is in there. It is all about making an icon to change 
parameters of text. But - imo rich-text is not designed to be 100% 
functioning ...

It's a nicely ironic touch to have a document widget in a system 
without built-in printing though.

We can go with layout-to-pdf or layout-to-html translators at first 
run. Well guys, I wonder what you will say, once sources are released? 
Then it will be fully upon us. Printing is imo not a priority - it 
first needs to be studies, then implemented - how to do it in cross-platform 
manner?

Hardly what I was expecting for 
RichText"."


The style is not meant to be used for directly editing rich text. 
It is a method to just display rich text efficiently using an existing 
document format.

I think Cyphre already has demonstrated editable rich text back in 
2005, before Carl began working on R3.

The parser for this is 54 lines of code including empty lines and 
comments. The style itself is 20 lines including empty lines and 
comments.

It's a nicely ironic touch to have a document widget in a system 
without built-in printing though.


You already know that printing is much harder to get done than it 
is to render for screen. How would the community react if Carl decided 
to focus on printing right now?

Source code for the style:

doc: text-area [


 about: "A tiny document markup method for embedded docs, notes, messages."

	options: [
		text-edit: [string! block!]
	]

	actors: [
		on-make: [
			; See text-area style for details.

   face/state/value: face/facets/text-edit: parse-doc face/facets/text-edit
			init-text-caret face ; (call before make-text)

   append face/gob gob: make-text-gob face face/facets/size - 2 "empty"
			face/gob/size: gob/size ; estimate to start (may get resized)
			do-style face 'on-update none
		]
	]
]

Cyphre's editable what? If we want to call that a rich-text attempt, 
we are really doomed. It was not really usable for real work.

You have a block of strings and words which represents the rich text, 
a caret position, some caret movement handling code, and a style 
that displays rich text. The biggest amount of work sounds to me 
like the code to set/get the caret position as well as movement. 
Manipulating the rich text block itself is trivial.

(Which makes me ask whether you have seen the rich text dialect. 
at all..)

Then we are not referring to the same thing. All I remember was attempt 
of several ppl to rich-text using R2, and it really was not something 
you would like to use as your editor.

I tried to find Carl' doc about text markup, but I only found REBOL 
TMD blog, where he announced such doc, but it was not probably released?

Pekr: http://rebol.net/wiki/Richtext

I know, but that is not original proposal ...

Henrik, I just checked out your latest movie (#3).  Very nice. I 
was wondering (as I always am) about the lists - There's a note that 
mentions that there will be tables. Will that in essence be like 
list-view?

james, for now lists are one-column tables. the code seems to support 
multiple tables, but I've not seen them used that way. I think the 
list-box style needs more code to handle multiple columns properly.

multiple tables
 => "multiple columns"

Thanks.

What is happening in VID3.4 landscape these days? Dialogs/pop-ups?

Modal dialogs are working now. Carl says it works correctly, compared 
to R2. I haven't done any tests.

Multiple draw blocks are now supported inside the style and a function 
has been added to help switching between them. This should simplify 
making horizontal and vertical versions of the same style.

Carl wants some icons, so I'm trying to build some for him now, hence 
all the SVG stuff.

multiple draw blocks? kind of frames principle which was removed 
earlier?

You could call it that. Building SCROLLER and SLIDER became way too 
difficult with a single DRAW block.