World: r3wp

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.

But there are no means to control them. You must provide them yourself 
(1-2 lines of code).

Henrik - looking at your latest screenshots, are those all inkscape 
based? One thing is imo clear, we need gradients for lines, hence 
your request. I would like to ask about so called "default skin" 
- do you have some concrete artistic idea, or do you aproach it by 
trial and error aproach? What I e.g. like about Carl's Autumn skin 
is gradients for backgrounds. So far I like mild blue (Fedora, Vista) 
tones, and I think that the era of "grey" systems is over ...

Pekr, it's trial and error. There's no guarantee that I won't come 
up with something better later. Right now I'm redesigning text field 
to make it work better in more situations.

The symbols, the rounded triangle and the octagon are inkscape based 
and yes, you can see the scaling errors there, which are not apparent 
in the circle. And that is exactly why I want gradients in lines.

The reason the octagon and triangle are inkscape based are also because 
scaling a rounded corner is very hard to do unless you to it correctly. 
It even took some time to get right in Inkscape.

OK, and for your default skin, which will be included, do you plan 
other than grey background? :-) I know it can be probably easily 
changed, but the thing is, that sometimes buttons or other widgets 
might not work with some background types ....

There will be more tests on backgrounds later.

Are we any closer to "more ppl being involved"? :-) It is few more 
weeks from such statement. Not being impatient, just asking .... 
it seems that there is still major design work being ongoing, and 
now it is dialogs ....

dialogs are nice (although I hate them as a concept :-), but the 
most important for ppl will be lists - tex-list, list, grid, tree-list. 
Those are more complicated style, and highly expected ones (looking 
into blog comments). At least one of those styles should be tried 
to proof the concept. So far the most difficult style which was build 
seems to be scroller (area)?

Question to BrianH probably: does current design allow "iterated 
faces", like in VID2?

I think there are a few more problems to solve right now, before 
we can get more people on board, otherwise there would be too much 
noise.

Pekr, I think iterated faces are gone, which is a good thing.

Minimalized faces and the gob model are partly designed to make iterated 
faces less necessary. We haven't needed them yet.

Re-did scrollbar for the third time. It gets easier every time. :-)

the subject that worries me the most is how is managed the caret 
handler

I have not studied that, and I don't think that part is complete 
yet.

I fear that this is not done better than in R2.

so that we can't mix and edit easly draw blocks wich contain text

i hope i'm wrong

all depend of the efficientness of caret-to-offset/offset-to-caret 
functions (or their equivalent).

if the can deal with richtext block or draw blocks, we are daved. 
If they can't it will be ever a mess to build richtext editors.