AltME groups: search

Keep in mind that is the layout dialect that shouldn't have colors. 
Styles are specified with a different dialect, and they can have 
colors in their draw blocks.

Anton, you are free to do that, but it will break the philosophy 
of how styles work together. I think this point is not properly understood, 
but it will move the GUI to the next level, where you spend zero 
time thinking about colors or theme, can properly divide UI design 
between a graphical designer and one producing programs.

For the other 0.1% you can write your own styles, or your own themes. 
Of course, when you are doing that you are being a style developer 
or a theme designer, not an app developer. The app developer (possibly 
you) will use the style developer's styles.

You jumped on me for making a statement you misinterpreted completely, 
so I take no offence :)

he pragmatic, and I suppose he sees it as pragmatic when he wants 
to use colors to decide button emphasis. if you are doing something 
quick and dirty that works, but when you are building very large 
apps, that's a no-no.

that's not yet implemented. colors in Carl's version are hard coded. 
notice also that a lot of values are hardcoded in his styles, and 
he told me this was for speed.

That way a theme designer can come up with a well-balanced color 
scheme that could be used by many applications, as long as the corresponding 
concepts had assigned colors in the theme.

I expect there will be a lot of abstractions between the hard values 
and the styles. The material system will also help with that.

With a meterials system you could bake a whole theme in at app init 
time, then have the styles bake the applicable colors into the styles 
at style init time.

the materials system borrows many terms from 3D modeling. "baking" 
is another one and a good one for providing an explanation of what 
should occur during style init.

One of the other original motivations for strong theming support 
was to get the theming sites around the internet involved. Challenge 
them to come up with good themes. Their efforts would market REBOL 
as well. But disabilities, other form factors and other situations 
are a factor as well.

it's not just looks. deep semantics that are used to make the GUI 
function properly relies on functional styles rather than appearance 
of styles. if you have a red button, the GUI won't know of its importance. 
but if you have an OK-BUTTON, you can tell how important it is, when 
it should be focused and what you are allowed to do with it. automating 
this can cut off hundreds of hours of development and testing time, 
because you don't have to pay attention to those details. the UI 
system does that for you.

that is why I utterly hate when a UI system does nothing to offer 
these features and the focus is on how pretty your buttons are or 
if the UI uses hardware acceleration.

sure, have you ever written a very large document in Word and then 
wanted to generate a table of contents using its built in TOC generator?

and that's why you never see in a word processor a function like: 
"collect all red text for use in TOC". it says: "use headline level 
1 for TOC".

On naming, I think PANEL is too general and doesn't describe the 
layout behavior. I could live with it though. 


I agree that TABLE should be saved as that is the common term for 
the spreadsheet model. GRID was used for that for a long time, and 
still is sometimes, but GRID could also be good when thought of as 
a canonical grid layout. GRID-LAY, CANON-LAY, or TABLET aren't too 
inspiring either.

Gregg, one thing that became clear in discussions of function doc 
strings recently in Curecode is that it is impossible to fully describe 
the behavior of some programming functions and objects using just 
one name, one sentence, whatever. No matter how long you allow the 
description to be, any sufficiently complex thing won't be describable 
in that limit. And you *want* limits because people have to read 
and write these terms, even more so for fundamental stuff that will 
be used a lot. The use of small, preferably non-compound words will 
speed up the process of humans reading and writing layouts. Java 
failed this pop quiz, btw.


This is why we have names for stuff (and people too: Does "Gregg" 
describe you?). A name serves as a placeholder for the knowlege you 
already have about the object in your head (preferably) or in the 
documentation. As long as we have good documentation, any small, 
easily distinguishable name will do. You will never fully describe 
the term, but by reading the documentation, or source, or through 
experience, the programmer will know what is meant.


In this specific case, "panel" is a general term, but many GUIs have 
traditionally used the word "panel" to describe the corresponding 
concept in their systems. That term never fully describes the behavior 
of that object, but it makes a good, easy to remember name for a 
complex concept that the developer is expected to have to learn. 
By using PANEL, at least experienced developers will know that they 
will have to look things up, and inexperienced developers will have 
to look things up no matter what name we choose. You don't get the 
same benefit from the term BOARD, for instance, because while the 
English terms are similar, "board" doesn't have the historical connotations 
that "panel" does in the computing world, so it doesn't gain the 
benefit of them.

Yes, I realize ithe irony in using such a long post to argue for 
short words, but in some ways it illustrates my point :)

small status update:


Not much happening on the release/testing side. Bolek found a nasty 
bug in MAKE-FACE, causing FACETS to be lost. Cyphre and Ladislav 
continue to work on resizing and Bolek is working on styles. When 
the styles are properly adapted to the new resizng scheme, I can 
test the new dialogs properly.

the R3 GUI does something like that already with a RELAY option, 
but it's cumbersome to use and less flexible.

Isn't LINK a better word?

attach: [

 "Set state of a face to our face's value and performs its main function."
	name [word!] field [word! none!] our-field [word! none!]
] [

 set-face/field get name get-face/field face field our-field ; (none 
 is allowed)
	do-face get name
]

how it looks now.

a reference to the face itself

Or is it defined at a higher level?

each reactor is converted to a function, where the first argument 
is the face and the remaining arguments are as shown in the argument 
list above

>> source guie/actions/attach
guie/actions/attach: make function! [[face value

    {Set state of a face to our face's value and performs its main function.}
    name [word!] field [word! none!] our-field [word! none!]
    /local
][
    set-face/field get name get-face/field face field our-field
    do-face get name
]]

; also VALUE is in there.

I think I would reword the doc string a bit for grammatical consistency.

It looks like it should be either "Set" and "perform", or "Sets" 
and "performs".

Does it actually set the "state" of a face, or is it really the "value" 
of a face ?

I changed the text, as that was inaccurate:


Set a field of a face to a field of this face and perform its main 
function.

Perhaps, to eliminate some ambiguity, it should be:

Set a field of a named face to a field of this face, then perform 
the named face's main function.

there is no longer a single "action". what you do is state a reactor 
or a set of reactors and it's this set of reactors that would be 
equivalent to R2's action, in that DO-FACE performs that set of reactors 
in sequence.

and by main function, the idea is that faces can be accessed on multiple 
levels, i.e. you can also just run a single reactor in the face.

Although I've implement 5 complete GUI frameworks, so far I've stayed 
relatively silent on the R3 GUI front cause I'm building my own framework 
and I don't want to interfere with the R3 system.


but I will pitch in here and say that what Henrik proposes is a good 
idea (I use the same name for a relatively similar feature), though 
it needs one thing if it is to be usable by newbies.


a way for do-face NOT to call attach.  the reason is that if you 
want several cooperating controls, they must not create feedback.

for an imperatively driven system like the R3 system, you might want 
to look at how Amiga OS's BOOPSI system managed this.  its relatively 
easy to code and allows for a much more robust data interchange between 
controls.

BOOPSI used an intermediate structure which acted as a controler 
to which you connect everything that has dependencies. then you call 
do on IT.

my old VALVE liquid system was similar to this and I could easily 
have 30 interconnected controls in realtime, all refreshing, some 
even generating data which where used in other parts of the gui (like 
backgrounds).  so you'd have a control control and the whole "stylesheet" 
would updated interactively.

an other simpler way, is to have a refinement on do-face,  /REACT 
 which indicates that its being driven from another control.  so 
then, you make sure that this face's do-face doesn't follow up on 
its own.

Petr, the app logic shoudl just get a trigger from the GUI (subscriber 
pattern) and than do what ever makes sense.

We have a VFSM (virtaul finite state machine) imeplementation for 
this.

Robert, I'm not sure how much theory there is in it. It seems more 
to be a feature that needs to be added to the reactor evaluation 
part.

I also think that this is the kind of thing which should be kept 
simple to a minimum.  this above simple procedure covers the majority 
of cases.

if users need something much more complex, then they are fully able 
to implement their own within the reactors.


IMHO, this is a generalized "helper" for those little things which 
aren't fun to code manually and for which a simple API does the job.

its best to make the actuall API non cyclic directly.   


so if the various event/data handling systems can identify that they 
are being only required to RECEIVE data, then they know that they 
shouldn't cause any reactions of their own.


if your reactors are all basically derived from a single or few functions, 
then its not a big deal to implement.


but if each field has its own implementation then it can be quite 
a tedious effort, since you must revise all of them so they are non 
propagating.

graph: As Gregg said, if we can link stuff, dataflow is not far away. 
And this will result in a constraint solver a la Excel. Which would 
be very cool to have anyway.

The dialect is low level, i.e. not a mezzanine, so I guess some conversion 
work needs to be done.

I t hink within the next 1-2 weeks a major milestone will be reached. 
host-kit with fully externalized graphics, resizing system mostly 
working and a couple of styles using it available.

IMO this can be a next host-kit release.

is it possible to know who work on what in the GUI topic and have 
a slight idea of the steps done and the steps to be done ....

ok so then does ritch text is a really something to be set as default 
inside the VID extension or isn't it wiser to let that as a side 
project to make research about the perfect way it could be done... 
and we let in draw a set of basic commands related to draw (a revamped 
set ofcourse) for instance I think that a ritch text engine is too 
much for the syntaxe colored editor we made ... it's like taking 
a nuke bomb to kill a single little fly .... but such an engine by 
default can anyway open new perspectives. but what annoys me in the 
process is to do this  raw script -> conversion to ritch text dialect 
-> conversion to draw by the rich text engine ...  instead of doing 
this raw script text from file.r -> conversion to draw using parse. 
But maybe i'm wrong ... anyway one way or another i will do a port 
of area-tc. and i assume that if the rich text engine seems too much 
for me then i could still do my proper engine relying on the draw 
for text lower level instructions.... (not to mention i like the 
idea of learning parse through  experiements)

and if the rich text engine doesn't handle clickable link display 
how can we add that to the rendering engine ? for example during 
a moment Steeve planed to add to area-tc the hability to render url 
in the rebol header block in a special way  in order to have them 
click and open the navigator with tthe url you clicked over. in an 
open engine like area-tc adding this isn't difficult  but adding 
this to a black box called rich text rendering engine seems to me 
to be harder... but i'm certainly wrong ...

with rich text come a lot of  troubles like handling paragraphs resizing 
things etc... how and where images are inserted withing the text 
paragraphs etc ... Can at some point the image inserted within text 
can be a draw set instruction rendering (for graphics or SVG image 
rendering ) etc... how will that engine grow ?

if it's just a cheap intent to mimic rich text that will make people 
laugh but if it's a  main concern and a constant work then it can 
become something really awsome.

I don't think it will be a black box.. richtext will be part of host 
kit, I think. And tight integration of text rendering with richtext 
engine is good imho.

Henrik .. that's a big job everyone has.

shadwolf, I suggest waiting with further comments until a release 
is made, so there is an actual base for commenting on.

i'm not commenting what will be  done ofcourse i didn't see it.


But i already looked at the richtext engine carl proposed 2 years 
ago and that's far to be good.... 

In fact richtext engine is supposed to be dialect layer on top of 
draw. 

That dialect layer is adapted normally to handle text rendering the 
proper way which implies that the lower level text functionnalities 

in draw for text related effects is better done than previously. 
That's all i say ...


Building a layer richtext what ever it is if the AGG /draw dialect 
exploit poorly the text related effects that will be a pain and a 
very small benefit...

and more complexity you will add to your engine more unexpected problems 
you will face...


 Like what we experienced in area-tc... suddently our perffectly working 
 engine under wnidows XP shows strong bugs in rendering just by arriving 
 on windows7. After 6 month in searching the why  and not finding 
 any cause to that rendering jam I by chance tryed the ultimate thing 
 no programer does i retro versionned back like 10  version below 
 the rendering engine and there suddently i found that rendering problems 
 disapeared by miracle...


I spend 10 times more time searching why the rendering was defective 
on windows 7 than doing area-tc and viva-rebol.r.  And that's too 
what  completly killed my mood. What else can i do than try to make 
this community know my experience with extensive text processing 
in draw with R2 to not have the same conceptual lacks repeated in 
R3.


And clearly  in R2 the text commands in AGG/draw were not suited 
for docuement rendering... That  doesn't means AGG can't do it ... 
that means at that time the dialect draw wasn't designed to exploit 
 intensivly text rendering. I always said before runnning you have 
to learn to crawl, then to stand up, then to walk. for me the way 
i  saw the realisation of a rendering engine text oriented for draw 
dialect was first step changing the color of  choosen elements in 
the text, then changing the font spécificity anytime anywhere in 
the document then being able to do strong text manipulations like 
moving by drag and drop paragraphs, inserting multimedia content 
in the document, scaling paragraphs etc... 

ROBERT: 

In fact that depends what  the rich text engine aims ... for example 
read only rendering is pretty different of  real time editing wisiwyg 
engine... The complexity betwin both approach is like 1 to 100...

Robert I know that you aim to get a WisiWyg editor for makedoc Pro 
format (wich in a time i tryed to provide in a totally deferent rendering 
technology)

therefore as you have the wip in the hand robert i think richtext 
dialect will go the way of a realtime wisiwyg  system able to be 
applyed over all the wigets we want... (like draw basically)

Not being an expect but IIRC R2 text rendering is not done using 
AGG. From this alone a lot of known problems might be coming.

I just hat a short chat with Cyphre about this. And on Windows & 
Linux the glyph outlines are used to render the fonts.

nice  :) beacasue R2 font system was a pain ... knowing what works 
where was difficult...

but once again R2  AGG/draw text  wasn't desinged to handle this 
... we used fixed fonts because we had no other why to obtain the 
x and y size of each displayed glyph so in other word that a lack 
of a basic lower level function.

We are aware of most of the text rendering issues and IMO it makes 
sense that we try to get a release out of the door ASAP so you can 
all take a look and give feedback.

so see assuming fixed fonts is a global concept is a wrong thing 
it better to say ok font will be not fixed lets handle this properly 
and offer a way to manage them the easier way...

we needed to know the size of the letters displayed on screen because 
first of all in R2 when you call 2 times a text instruction the rendering 
at piled up at same place and not disposed one after another on the 
X axis with natural spacing... so draw [ text 10X10 "a" text "b"] 
renders a "b" over the "A" and not "A" followed by "B". And it's 
logical ... text instruct was then designed to handle a serie a letter 
or several series of letter organised in distinct block we can call 
words... but you see that concept doesn't fit with the need of having 
an interaction anytime with any letter componing the words.

and in the richtext proposition of Carl made 2 years ago (times flyes..) 
we find again this block concept wich is related to the way MakeDoc 
format handle things ...  like in HTML  for example you have flags 
that defines a rendering style. But the things betwin the flags can't 
evolve... they are not supposed to change font style or font size 
or font color. See that's what i would call a we treat text as block 
and not as single element able to singularly evolve on their own 
without affecting the surrounding elements.

ofcourse you still can say a <H1> </H1> instead of the basic regular 
seting will take this font this color this size but that will affect 
all it's content and not only a part of it ...

and then if you want to have an atomical approach then MakeDoc dialect 
becomes too verbous to be efficient... like in HTML more you want 
stylised things more you pile up flags and more you have problems 
debuging and having a direct acces to your raw document content... 
So it's clear that a real design have to be set for this richtext 
even if in the end rendering html or MAkeDoc or makeDocPro  with 
that dialect means a conversion stage.

that's why the proposition of carl to have an open flag system was 
cool ... he presented it years ago as a variable inside draw dialect 
to hold styles ... And i think people didn't see the good points 
in this approach ...

The idea is that we will have the low-level font rendering stuff 
accessible. Further a standard richt-text dialect will exist. If 
htis doesn't fit, you can change it and use any other concept to 
make richt-text available in apps.

Because it's not pixel precise font. I would like to see support 
for pixel precise font which could be in just a simple bitmap format.

but steeve have a point ...  it's ugly ... i don't know if that the 
antigrain thing but on the lower size fonts damn the rendering of 
the font is messed up ... you have on the same letter bigger and 
smaller parts... This was a problem we experienced on R2 too we noticed 
it. People said don't worry R3 is completly deferent etc... and in 
the result -> blured ugly fonts... like on R2  so wher is the gain 
?

I appreciate the effort too ... but when i say this part needs a 
real work that's not to be rude etc... that's true !! damn how can 
i provide a simple functionnality like Zoom + / - for text if bellow 
font-size 14 bold the font rendering is ugly ?

MS for example, dosesn't properly typeset its font.  The historical 
reason being that their fonts are very sharp and readle on low dpi 
monitors.


If that is a problem of the outline generation, the rasterizing or 
both is up for grabs but, its possible that we can get better results 
if we "fix" one or both of the problems.

I am  not criticizing the work from the R3 team, far from it, but 
trying to provide a little bit more depth on the issue.

This is a screen shot from the Moscow tibetan OCR project http://www.buddism.ru///ocrlib/OCRLib21_07_2010.png

Again the text looks very different to that in Henrik's image

Hmm, now that you say it. The vertical alignment of the Arabic also 
looks a bit off.

Jerry's console script looks a lot better too but it's traditional 
Chinese http://rebollovesjerry.blogspot.com/2008/03/rebol-30unicode.html

Chinese is a heiroglyph based system so there needs to be spacing 
between each word ...

That is actually Hiragana -  a Japanese syllabary

so, it's all a mixture :)

Graham, sorry, I really don't know the rules how code points in Unicode 
should be positioned. That needs to be studied and corrrections being 
made in the text rendering/layouting loop. Just a note, even now 
the text rendering/layouting code ismore than 50Kb of C++ code so 
either someone needs to study all the Unicode rules and make new 
replacement or publish patches to the current version.

So, does this mean these chars render inside a text field and we 
can backspace, del etc?

(I still need to do a few changes before handing it over to Carl)

What's the mechanism of selecting a different charset ?  Just windows 
??

There is no charset selection. You just provide valid UTF-8 codes 
for the appropriate unicode chars, thats all. Also ofcourse you need 
to have font that contains that chars. I was using 'Arial Unicode 
MS' font in the test screens which is a huge font containing big 
chunk from all the unicode pages.

did you ever figure out how to create GUI event from inside a network 
protocol?

eg. for the purposes of updating a progress face

How about a bounty for the text rendering?


To be honest I don't care to much about better quality at the moment. 
We need a way to display text and some formatting (which works) and 
special chars like Umlauts. That's good-enough for us to use R3 for 
commercial development. Optimal text-rendering is nice to have but 
invest to do it must be covered by some revenue first.

Who knows how long it takes... anybody complaining about the look 
has a chance to find out.

it's probably a good idea to create a wiki page regarding all the 
discovered issues around unicode in View. that way, it's easier to 
create a community project around it.

Cyphre, the server link gives a 404

you're right - it looks like a fairly even split between good response 
and 404

my guess is yes.


it would be nice to have a switch to allow this to be switched somehow 
within a drawing operation.  some gfx operations are hard to

Composing UIs from the lop left makes sense when the UIs are specified 
using a declarative language that starts from the top left too, a 
language like REBOL.

Can't you use a draw transform?

I think that's what Cyphre also argues .. to use a transform

Is there a problem with having Draw gobs be bottom-left, but text 
gobs top-left?

it won't make a difference in speed.   its just a questing of the 
order of rasterizing, start at bottom or start at top.