AltME groups: search

What I would like to look into is the possibility of speed-up of 
GUI refresh. Not 3D based GUI, just a refresh/rendering/blitting 
- whatever is possible. Cyphre told me, he has general DLL, which 
allows to accelerate even R2 faces ...

Max - thas is something I don't agree with - turning whole View into 
3D model. You should talk to Cyphre. AGG is pixel precise, 3D stuff 
can differ per GFX card, per driver version. I would accelerate only 
blitting.

Geomol - Cyphre told me, that you could map parts of AGG to HW acceleration, 
but then it can look differently on each gfx card/driver ..

I don't know details of course - we would have to ask Cyphre ...

Poor looking fonts in R3 are because the AA settings used in R3 are 
not correct. This requires intervention by Cyphre as those settings 
are not exposed in DRAW yet.

I don't know AGG well so I'am not able to compare these. AGG can 
use same rasterization as Flash (which is more optimized for speed 
I guess). At least that's what Cyphre told me.

Cyphre has thought that we might switch to "compound rasterizer" 
of AGG, which would be more similar to Flash. But we might be slightly 
off-topic here :-)

The main thing: linear command evaluation blocks. The replacement 
for the delect method.


Once that's done, I'll release View, but only with the windowing/event 
system, not rendering... then, Cyphre can bring the rendering method 
back online as his time allows. (Or, you can do your own in OpenGL 
if you feel so inclined.)

R3 Host-Kit A100 has been uploaded to www.rebol.com.  This release 
can build CORE or VIEW (with externalized graphics lib.)


However, although the graphics lib is there, the DRAW commands are 
still in the process of conversion (Cyphre will be working on that 
part).


It's also an example (and a fairly simple one to learn from) of how 
to build a host-based extension module, including a few scripts that 
show how to process the module source to embed it in the boot.

Although Cyphre and I have both been able to build it using Mingw, 
other's have not been able to do so, and we're not sure why as of 
yet.


Therefore, we're not quite ready to distribute the host-kit to everyone, 
because we need more testing on it. However, if you want to actually 
test it (windows only), then ask Henrik for the download URL.

the images are pointers, so the data doesn't need to be copied if 
you are just manipulating it.   though it seems there was some image 
bugs in the A107 (not sure where) which AFAIK are fixed but not yet 
released in current host-kit (cyphre knows for sure).

So with Cyphre's help I have this function:
char* rebser_to_utf8(REBSER* series) {
    char *uf8str;
    REBCHR* str;
    REBINT result = RL_GET_STRING(series, 0 , (void**)&str);
        
    if (result > 0){
        //unicode string
        int iLen = wcslen(str);
        int oLen = iLen *  sizeof(REBCHR);
        uf8str = malloc(oLen);

        int result = WideCharToMultiByte(CP_UTF8, 0, str, iLen, uf8str, oLen, 
        0, 0);
        if (result == 0) {
            int err = GetLastError();
            RL->print("err: %d\n", err);
        }
    } else if (result < 0) {
        //bytes string (ascii or latin-1)
        uf8str = malloc(strlen((char *)str));
        strcpy(uf8str, (char *)str);
    }
    return uf8str;
}

and I can than use:
..
            char *filename = rebser_to_utf8(RXA_SERIES(frm, 1));
            status=MagickReadImage(current_wand, filename);
            free(filename);
            if (status == MagickFalse) {
                ThrowWandException(current_wand);
            }
            return RXR_TRUE;

Again with Cyphre's help, here is a function which converts MultiByte 
(utf-8) string from C side to REBSER used to return the string to 
REBOL side:

REBSER* MultiByteToRebser(char* mbStr) {

    int len = MultiByteToWideChar( CP_UTF8, 0, mbStr, -1, NULL, 0);
    //the len is length of the string + null terminator
    wchar_t *wcStr = malloc(len * sizeof(wchar_t));

    int result = MultiByteToWideChar(CP_UTF8, 0, mbStr, strlen(mbStr), 
    wcStr, len);
    if (result == 0) {
        int err = GetLastError();
        RL->print("ERROR: MultiByteToWideChar -> %d\n", err);
        exit(-1); //how to throw ERROR on REBOL side?
    }
    REBSER *ser = RL_MAKE_STRING(len-1,TRUE);
    REBUNI *dst;

    //hack! - will set the tail to len
    REBINT *s = (REBINT*)ser;
    s[1] = len-1;

    RL_GET_STRING(ser,0,(void**)&dst);
    wcscpy(dst, wcStr);

    free(wcStr);
    wcStr = NULL;
    return ser;
}

I'm not sure how safe it is, but it seems to be working.
To return the string value I use:

RXA_TYPE(frm, 1) = RXT_STRING;
RXA_SERIES(frm, 1) = (REBSER *)MultiByteToRebser(utf8str);
return RXR_VALUE;

invert H and V and have the layout still work

 - that is generally not impossible, of course, but it is against 
 the readability requirement Cyphre mentioned as his reason why he 
 proposed Hpanel and Vpanel styles instead of having panel #H panel 
 #V

the user frequently wants to...

 - that it is not a speculation, I was told by Cyphre that there are 
 at least two users frequently wanting that

Aha, OK, Cyphre and I were wondering...

Regarding Graham's note about RebGUI - Cyphre checked it, and there 
we can use just a PANEL (which corresponds to the above proposed 
HPANEL, as it looks), and an AFTER X value, which corresponds to 
HPANEL X specifying the number of columns, not the number of rows, 
as Gregg/Izkata seem to propose for HPANEL

When Cyphre did the grid for RebGUI for me, that is what I suggested 
to him - to enclose column VID description into block, so that you 
can reorganise it easily .... so I am OK with that ...

ssolie - IIRC Cyphre reported here, that he has FreeType support 
done for A110, he just has to release it. That should help platforms 
like OS-X, Linux, Amiga IIRC .

Pekr: I'm using Cyphre's patch along with my own changes which enables 
the FreeType support on Amiga to function.

Guys - what is the reason of kind of slow R3 GUI progress? At least 
from external observer point of view? That is not complaint nor is 
it any kind of attack. It is just that I thought that you need R3 
GUI for a commercial project? And from external pov we could see:

- new resizing system
- some new higher-level systems (validation, tabbing/focusing)
- some news about low level tweaks
- Cyphre posting REP about new possible rich-text system
- some endless work on styles


However - from external point of view, and unless it all plugs together, 
Carl's original VID felt more concrete, more complete. Is there any 
estimate when stuff will plug together to form usable system? Simply 
put - maybe if system would be docced, ppl could start working on 
additional styles? Or is it still too early, and non-yet-finished 
subystems could break any such code?

Pekr, and all I'm saying is that the irreguarly shaped styles drawing 
can be solved with access to the face click mask, that either is 
or hopefully will be implemented by Cyphre. Therefore I find it pointless 
to work on a per-style solution.

Cyphre: I'm willing to give it a try.. it is becoming some kind of 
patched up monster so I hope Carl passes over the official A110 soon 
;-)

i just try it and it gives me that >> do %style-browser.r3

Script: "R3 GUI Style Browser" Version: $Id: style-browser.r3 1220 
2010-11-26 13
:18:02Z cyphre $ Date: none
** Script error: guie has no value
** Where: catch either either -apply- do
** Near: catch/quit either var [[do/next data var]] [data]

Due to the fact, that the B) variant was not known in this wording 
to either Cyphre or Bolek, I kindly ask both to participate in the 
poll as well. Thanks.

Cyphre, Thanks. I'd just tested it. Chinese characters can be rendered 
correctly and perfectly.

Late to the game, but


as for A) - don't we have already tags? It could all be in the tags 
block, not in the new field. And if tags block is just flat, and 
those for states could collide with another flag names, we could 
use nested blocks flags: [ show? [visible]]. I see no reason why 
to introduce new field, unless from the speed reasons

Generally I like B) more, but:


I definitely don't like being dependant upon the size of 0x0? That 
seems really strange to me. Visibility state in the gob-tree should 
be imo independent from the size? E.g. look at Cyphre's code example:

button 0x0 "test" options [resizes?: true]

Do you really want to see code like that in the VID level?

Cyphre: "Brian, yes, what would you want to see on the screen if 
something has zero size?" - really, I am not sure I care about if 
something is theoretically visible in 0x0 size, because face itself 
will not have a meaning even with 1x1 size, but I think that visibility 
(event flow) should be separate. OTOH, I can't find any practical 
reason how it could be internally usefull to have some inner state 
as shown, while being at 0x0. I thought about some graph models, 
event flows via the face hierarchies, etc., but with 0x0 size, you 
can't receive events anyway (apart from timer events maybe)

Max - speak on :-)

Rebolek - by "decided" I meant Cyphre's message stating what they 
agreed upon with Ladislav, and Robert kind of seconded :-)

Cyphre - say hello to Carl :-)

re blogs - maybe not examples, but it would be nice to know, what 
is e.g. planned. As e.g. Ladislav posted on-content, I believe Cyphre 
might be planning/doing some low-level stuff changes too, or some 
changes for some styles. But I can understand the "busy" argument, 
so maybe the best aproach for those interested is to trying to test, 
and when having the questions, just asking here ...

And, to not forget, thanks to Cyphre's effort, the VGROUP and HGROUP 
styles now properly use the RETURN keywords allowing the *group styles 
to have rows/columns with unequal lengths

FACES-OF:FACES? preferences - the current count is 3 (developers 
- Cyphre, Ladislav, Henrik) : 3 ( Anton, Pekr, Oldes)

That is a problem that Ladislav, Cyphre and Bolek are attempting 
to clarify and fix right now.

Guys, time to crank up the volume and build a concrete roadmap for 
the GUI. I have a suggestion to further accelerate the development 
of the GUI: RM Asset will over time require some specific, but complex 
styles, that the community will need as well. We are developing a 
SCRUM tool, which you will need to use as a basis for discussions 
and development of these styles. Consider it also training to become 
a good style developer. For any needs, Cyphre, Bolek, Ladislav and 
I will be available to extend the UI base as needed to create the 
styles mentioned below. We also provide examples, training and help.


Many of these styles are focused for development of particular types 
of applications that open many, small windows inside a large work 
area for flexible construction of data analysis tools and other traditional 
Windows or Linux applications.


It could be a combination of how graphics shader networks are built 
(though without the need for zooming), to regular multi-document 
management. The ultimate goal is to build styles that allow a highly 
user configurable multi-document GUI to be described, using only 
the R3 GUI dialect and some helper functions that we already have.

These styles are generic enough to be usable in plenty of apps.

Inspirations for window arrangements:


http://houdini.dreamerzstudio.net/wp-content/uploads/2010/05/reflectiveShaderNetwork.jpg
http://www.codeproject.com/KB/docview/TabbedMDI/TabbedMDI.gif

Inspiration for segmented area management:


http://www.solidsmack.com/wp-content/uploads/2010/12/modo_501_RayGL_sample_002.jpg
http://jedit.sourceforge.net/jedit-snap-12.png

A list of general styles that definitely are needed:


- Style for doing multi-document window management, using various 
arrangements, window linking features, as borrowed from apps like 
Photoshop.

- Style for segmented area management, editable by users, for arranging 
tool areas, view areas. Segments are adjustable in size. Inspiration 
is JEdit and Modo.
- Multi-document window style, for use in window management style
- Tool window style, for use in window management style

- Tear-off style for toolbars and tool windows, for use in window 
management style

- Regular Windows-style menu bar with submenus, also for right-click 
popup menus.

More specific styles that will be needed later:


- High-performance style for graphing points and curves in a coordinate 
system, with zooming and panning.
- Gannt chart style: http://en.wikipedia.org/wiki/Gannt_Chart
- Harvey Ball style: http://en.wikipedia.org/wiki/Harvey_Balls
- Year calendar style
- Month calendar style
- Week calendar style
- Day calendar style

- MacOSX style tag field: http://kitara.nl/wp-content/uploads/2010/05/31.png

- Console style for input and listing results. This could eventually 
grow into the base for a View based R3 console.

- Highly ergonomic numeric input styles, that support unit conversion, 
inline math.

The question is where to start and what fits with you.


The time table is simply ASAP, and preferrably want some results 
within the next 2 months.


If you are planning R3 apps soon, it would be a good idea to have 
a look at the list to see where you may be able to contribute, as 
the GUI moves to beta status. RM Asset needs to spend time building 
end-user apps for R3 and the GUI is becoming ready, except for the 
above mentioned styles.

But the missing doc for the gui is also big issue for me (but it 
was already promised by Cyphre to provide it)

[I also wish Cyphre could comment his code... so far he was probably 
the only one who was reading it, but we should change it if we want 
go faster.]

Jocko, the level of usability of Carl's demo was not satisfactory, 
and is lower than that now, since nobody cared to keep it compatible 
with the low level changes to the hostkit. That is the situation. 
Documentation - the same level of documentation exists (written by 
me), but Cyphre decided to publish it after the changes to the remaining 
styles using the panel implementation take place.

Henrik - when I scroll above, you created the list of windowing and 
more advanced styles needed. Could we get the list, which will be 
delivered with initial release? E.g. we know, that Cyphre was working 
on some grid engine, etc., so that devs can know, what they don't 
need to focus on?

cyphre yeah you want pathetic brainless followers that appauds any 
of your moves.... Sorry that's not my style.. The thing is the people 
telling me to do my own branch of R3/GUI  for free obviously to there 
benefits don't know how to do such a project on their own to start 
with so there is obviously nothing to be expecting coming from them.

Cyphre - to get smooth (amiga-like) scrolling, with low CPU overhead 
(do you remember my scrolling news bar?), is your HW acceleration 
helpfull, or it would need any other specific links to DirectX stuff? 
Just a question ....

We should start talking look & feel at some point too, as it really 
looks completly strange :-) Cheap gradients with Aqua like old Mac 
look mixed with 70ties Unix grey aproach :-). How can anyone create 
anything like that nowadays? This is really strange, as I remember 
Gabriele's effect-lab, Cyphre's styles pack, and also Henrik's first 
UI attempts, and those looked much better ...


I need to know, if it will be adressed, as I am scared to touch the 
gui, as I fear it will do really something bad to me :-)

It would be nice if Cyphre would isolate platform specific layer 
of gfx, but that is what I understand from one of his latest messages 
he is going to do  ... then the porting should be even easier.

I can see him from time to time on Facebook, but right now he is 
not there. I believe Cyphre has his cell phone  ...

Cyphre tried to call him, but no response.

Cyphre - any quick example of inteern? Just:

intern: [area-color: red] ???

Ladislav: ""I can see you use empty rows...Aren't we wasting memory 
here?" - how can an empty row waste memory?" - :-) This is misunderstanding 
:-) My question relates to my previous discussion with Cyphre, about 
removal of 'faced element. Previously, we had facets, and faced (instance 
locals). Cyphre pointed out, that now everything is instance local, 
and goes into facets. If you want stuff to be shared, new 'intern 
slot should be used.


And that was my question - I can't see intern used anywhere in the 
stlyle definitions. What I noticed is, that in the facets blocks, 
stuff is somehow visually separated by empty rows. Hence my question 
- if I see things like min-size, max-size - aren't those a good candidate 
for items being shared? And if those are not shared (referenced), 
we are kind of "wasting" memory here. I think that it will not be 
significant though ...

I am certainly not using that one here, will have to discuss it with 
Cyphre

Cyphre is ill (flu), so there might be some delays in answers.

So, guys, is there any new revised release in the plan?
 - most probably next week
Or any explanations to my findings?

 - having trouble to reproduce some of your findings here, and some 
 problems are related to the parts Cyphre is working on

But Cyphre might be able to reproduce your problem once he is back

Cyphre, thanks for the tips. If you will have any new release with 
some bugs fixed, please post it, so that I don't try to adapt already 
dated sources ...

Cyphre's "as usually" most probably means "on Friday", and I bet 
Cyphre will put a note to the announcement group when the update 
will be available.

Interesting. I know that I was told that 'when style is not adapted, 
but - you probably saw my earlier screenshot, which shows space at 
the top of the panel. I get this, when I use the following method:

pan: make-face 'vpanel [columns: 1] 
insert-panel-content pan pick test-blocks index
set-panel-content main-pan pan


But - if I use Cyphre's method, the visual space at the top of the 
panel is not there. My quick conclusion is, that panel content handling 
funcitons are not compatible for various creation methods:


pan: make-face 'vpanel [columns: 1content: pick test-blocks index]
set-panel-content main-pan pan

Going to temporarily use Cyphre's version ....

Cyphre - simply put - in a demo I am porting, I am not able to get 
the subpanel to work - it displays, but  don't perform actions. E.g. 
single button press causes:


** GUI ERROR: Cannot parse the GUI dialect at: panel 240.100.80 title 
Alert grou
p doc Button pressed! scroller

As Cyphre explained one concept to me, and because I have some questions, 
I post it publicly, so that others might benefit from the info. I 
was not properly understanding the structure of the panel. Cyphre 
was kind of surprised why do I need to know it, and that I might 
not eventually need it for the layout work, but the truth is, that 
I would like to understand system internals.


In R2, the structure of the face was mostly the same IIRC. And you 
put your elements into face/pane. I found out, that structure of 
face might be different for various styles. I hope I am not wrong. 
And in such a case, I suggest to document particular style fields, 
so that one does know, what does it serve for. That might be really 
good for programmers ...

Cyphre - without init-size in the options definition you won't be 
able to set the size like: button XxY

You cannot do that right now, so what's the point.

Cyphre yes, that's what I'm suggesting from beginning, but it requires 
Ladislav's death ;)

having such non logical behaviour, then better remove the option 
altogether. Cyphre's proposal is an interim solution, sitll bettter 
than having it the way it is now ...

Cyphre, so your POV changed from 11:48 where you proposed that init 
code for button should set max-size if user sets size in dialect?

That approach would make sense if there was a good reason for the 
limit, like a larger limit would screw up the draw blocks or something. 
Cyphre, is that the case with the button style?

While Cyphre and I are fighting for that same user a few minutes 
later when they need to make a change :)

Cyphre, when somebody's fiddling with options block, they must understand 
at least facets. When writing code like [button 100x100], you do 
not need to know anything about style internals.

Cyphre - you misinterpret me a bit - on one hand, yes, I think those 
are usefull to have for occassional GUI hackers, for the fun factor. 
If user is an idiot, and wants to define each button differently, 
so be it - there is analogy with inline CSS style. But if we allow 
it, the behaviour should deliver it ...

Cyphre, yes, this is the default property of buttons: Resizes to 
the maximum you can imagine. If you don't like it: stop it by giving 
you own max-size

Robert - Cyphre probably meant that button will overtake your screen 
area :-) But it can't no? There are some rules, how particular styles 
divide the spacing/sizing during the resizing?

Cyphre - now you replied to yourself - what is the difference to 
button vs my-button? The only one is, that what I wish is now covered 
by my-button. But what was the basic refusal to allow buttons being 
freely sized? Some MS Word like analogy of later on having to change 
each button separately in your app, if we allow user each button 
to be completly differently sized.

Cyphre: I thought I am able to initialise the size in terms of min-max 
bounds? But all following buttons are of the same size?

view [button "1" button 180x23 "2" button 230x230 "3"]

Cyphre: "In HTML you can also specify values that are not reflected 
in the resulting page so what?" -- which one? What I know, if you 
use propper CSS, you have exactly what you want.

Panel resizing user poll:

Background information:


For resizing purposes, every graphic element (including panels) has:

INIT-SIZE, MIN-SIZE and MAX-SIZE dimensions:


* INIT-SIZE is the size that is being resized (magnified or minified),

* MIN-SIZE is the smallest possible size of the element after resize,

* MAX-SIZE is the largest possible size of the element after resize.


Until now, we used auto-sized panels, for which we always (after 
every content change, like insertion of a button, etc.) recomputed 
their INIT-SIZE, MIN-SIZE and MAX-SIZE based on the sizes of the 
elements the panel contained.


Currently it looks, that there are many reasons, why it may be better 
to *not automatically recompute* INIT-SIZE, MIN-SIZE and MAX-SIZE 
after at least some of the possible change types.


Therefore, we introduced a non-auto-sized panel, which auto-computes 
INIT-SIZE, MIN-SIZE and MAX-SIZE on-demand only.

Our questions:


* After inserting a button (or other contents), what do you think 
should be the default action - recompute all the above values, or 
not recompute any of the above values?

* How to specify a non-default behaviour? Cyphre came with a proposal 
to use a /UPDATE refinement accepting a WHAT block, so, e.g. /UPDATE 
[MIN-SIZE MAX-SIZE] is required to update just the specified dimensions. 
Would you find a different alternative more convenient?

Sounds exactly as my preferences are. I originally wanted it that 
way, but was somehow outvoted. Anyway, the current improvements I 
made (will be in the next release) look satisfactory to Cyphre. Therefore, 
I count your votes as votes to not recalculate the INIT-SIZE, MIN-SIZE 
or MAX-SIZE automatically, respecting the user setting as "higher 
authority", while allowing him to demand the (re)calculation whenever 
he feels like.

Pekr: looks, that you will get more examples from Cyphre, who promised 
to pack some and make them available. So, I am afraid, that at the 
time being, you only have the examples from the gui-panels.html text 
available.

Carl's gui: FACED = instance local, FACETS = shared.

 - I know, but what is it good for? In the end everything will end 
 in face's facets anyway. Neither me nor Cyphre saw a single reason 
 to leave it, if you have some user case, then please, enlighten us, 
 because for us, FACED is only problem-maker.

- In regards to above point, I really wonder, if buttons should be 
resizable at all. I said - resizable, not settable. I wonder, if 
I would like buttons to be of consistent size. I might try with face/resizes?: 
false, if that would make the trick.

 If you set the RESIZES attribute to OFF, you get a completely different 
 behaviour, than what you expect:


- the resizing algorithm will leave the button untouched, which means, 
that it does neither compute the position, nor the size, and the 
button would just "float" - the next version will contain more than 
20 different examples, Cyphre's visibility example manipulating the 
RESIZES attribute included


- if you just want the resizing algorithm to not change the size 
of an element, while allowing the resizing algorithm to compute the 
position of the element, you should do it differently. Just set the 
INIT-SIZE, MIN-SIZE and MAX-SIZE of the element all to the same pair. 
You will notice, that the size of the element will not change, no 
matter what, only the position may change.

Cyphre - what you just said says it all. I don't care for different 
context and word meaning, if those contexts are so close one to each 
other, that it might confuss users :-)

Cyphre - let's be realistic - I am the only one, because in fact 
I am most probably the only one, who is investigating GUI in such 
a deep manner, if not at all. This is imo a result of bad RT's treatment 
of R3, which is bringing REBOL into isolation even further more, 
making less and less ppl interested with almost zero RT's action 
... and that's the reality ...

release date: Cyphre will not be available to commit a new release, 
and some scroller, etc. changes are on the way, so, the release will 
happen on Monday or Tuesday

I think Cyphre is working on a change to make it easier to use.

Cyphre isn't very well, so there may be some delay with the release.

Cyphre - just some friendly opinion exchange, hopefully you will 
be able to understand my explanations (which don't necessarily represent 
my exact point of view):


- most ppl here are well aware of the fact, that RMA is a business 
entity, and hence has absolute right to do what makes sense for its 
business. The trick is, that in the end, it does not work for ppl, 
I will tell why later.


- The point above is even more difficult to understand, as RMA is 
offering its work for free, yet ppl still complain to something (including 
me of course)


- What might have failed is, that ppl might think, that accepting 
SCRUM method will mean, that we have finally found a viable model 
for  general R3 development, which will allow Carl to stay available 
 to small agile team of developers, isolated from the noise.


- Ppl were expecting GUI to probably appear in 2-3 month period. 
Althought Carl's GUI worked mostly on the surface, it was something 
ppl could experience. RMA's aproach is much broader aproach to usability 
and architecture. But - that resulted into refusal to provide usable 
demo. There was some attempt to provide style browser, but it was 
highly unusable to attract ppl.


- RMA seems not to understand (or it is not its priority) the importance 
of visuals. You surely remember the "design sells" claims, which 
are know for ages. Do you remember your Rebcon AGG demo? So much 
joy, so much applause. The current look of the GUI and its metrics 
just ruined the "hmm, nice" first look experience, and for no apparent 
reason, then constantly repeating "the skin will be done later". 
If so, it should not have been changed in the first place. (After 
porting the demo, my next area to play with is to try to play with 
material system, etc., and box-model style metrics)


- Ppl are well aware, that RMA is mostly on its own, and that even 
SCRUM methog did not work in regards to keep Carl attracted to such 
method in the long run. We are now facing the worst ever period of 
R3 development, where Carl apparently has some other projects, and 
R3 is almost stalled. Ppl are clever enough to realise, that we are 
being fed with some mid-time blogs, which should keep us distrated 
from the facts (huh, rebol file suffix importance anyone?), and we 
are also facing rushed releases as A111 is, and 2.7.8. was. You are 
free to not agree, but that is how I personally feel about the situation 
towards the RT. In the past I would probably write some letter to 
Carl, but I am at the point where I think, that RT is effectively 
burrying R3 under month by month. So - Carl is not able to find free 
time to continue with R3 development on a regular basis, and noone 
is denying his right to personal life, but - the fact is, that R3 
situation is at least - worrying. We wait for the beta plan for more 
than 4 months! If someone does not have time to even think how to 
proceed, then it is probably time to close the shop ... or open-source 
... but that will not happen. So - welcome the Amiga fate ... 


- And before someone else adds it, I will add it myself, as I believe 
I have my points right :-) Amen! Could I be wrong? Of course I could. 
You can easily state - hey, the situation is not like that, we know 
Carl works on this or that. Well - RMA knows, but that's it - the 
rest of the community is kept in information embargo from Carl. And 
that is difficult to deal with for many of us, who really like REBOL, 
and would like to see some coordinated development and the light 
in the end of the tunel once again ....

Cyphre: "Kaj, I bet your r3-gui.r3 was definitely not the latest 
version from http://www.rm-asset.com/code/downloads/files/r3-gui.r3

The bug you showed has been fixed in the release from 28.1.2011 (see 
the announce group)"

Agreed, but that is how "The most current graphics library changes 
have been included. Many thanks to Cyphre and the RMA project." was 
interpreted.

The update is planned for the next Friday, or later (some changes 
are on the way, and Cyphre was sick, planning originally do make 
some adjustments, so we do not expect to post an update sooner).

Cyphre promised to update the documentation for the boxmodel, as 
a part of the upcoming update.

jocko - I think it is not. Drawing style is not much complex, one 
binding line, but I think that there was some underlying change in 
hostkit interface to drawing, I just don't know. IIRC Cyphre or someone 
here stated, that there are going to be some changes with the next 
release ....

afaik, Cyphre is working on it right now and it should be out soon

I have published 'unofficial' proposal with improvements to the current 
RichText dialect in R3. If anyone is interested in this topic you 
can read the proposal here: http://www.rebol.cz/~cyphre/docs/rich-text.html
Any feedback is appreciated.

Cyphre - what about using direct rebol.cz plus subfolder - you've 
got access to it. ClearOS is crappy in that regard - I sent bug report 
to them, with no result at all ...

Cyphre, in your example the correct word sounds like WIDTH 400x600

Cyphre - I am not sure if we should accept CSS document model here, 
as users/designers are used to it? I tried to search for some typography 
vocabulary, but there is not much in it:

http://www.proximasoftware.com/fontexpert/terms/


Then I also looked into MS Word (well, not the best DTP option, I 
know :-), but I am somehow satisfied, how paragraph styling is done 
in it, and I find it pretty much flexible. So few of my notes:

PAGE:
--------
- text-gob - let's say it equals to page


- margin should allow to set 4 sides, as is with CSS and even DTP 
systems. DTP system talk about margin as about the space to the edge 
of the paper. I don't know, how such terms are used in conjunction 
to R3 GUI, but we should somehow find-out, how to not be confusing. 
But - having just a single marign is not imo sufficient.


- origin should replace scroll, and it should mean offset. But looking 
into VID2, origin just did what you propose - but I don't like it, 
as it required us to introduce offset to VID2.

PARA:


- indent - e.g. MS Word defines: indent-left, indent-right (kind 
of creates margins/padding, if you relate to CSS terms), then they 
have indent-special - first-line | "pre-indent" (-first-line,not 
much usefull). It also has check-box for "mirror setting", which 
changes indent-left to inner, and indent-right to outer (dunno what 
it is good for)


- spacing - top-space | bottom-space - but here, it is not inner 
space in paragraph, it is more of an indentation between paragraphs. 
In other words - I can imagine calling it even padding (as we are 
used from VID2, we used space there for the auto-spacing). It allows 
you to set, that it will not add space in between two paragraphs 
of the same style. It also allows you to set spacing for rows - either 
by float, or by multiples, 1,5 rows, double, the-least-possible (pixels), 
exactly (pixels)


- paging - some stuff to set in regards to paragraph and paging, 
as linking of paragraphs, linking of lines

- runaround settings (dunno if correct english term)

cyphre, I really like the Indent which allows Y value as well.

Cyphre, that would be great if you could make the necessary changes. 
I have simply commented out text support for the time being so I 
can continue to work on other areas.

Cyphre: thanks! I look forward to testing this out with freetype.

We are busy going 1.0 on an application these days, so I'm not working 
very much on the GUI. I can however tell that Rebolek and Cyphre 
are hard at work. :-)

yes, it does not work. Cyphre's gfx test works though. I am interested 
in Amiga figures :-)

With updated version from Cyphre:
R3gl - 0:00:03.234 123.685 FPS

Ah, way better results, then, Cyphre. 132 fps vs 86 fps on my laptop 
now.

Hmm, I wonder if Cyphre's test is really CPU bound - your video chipset 
shouldn't be that much, or at all, better than mine (from what I 
recall). Your CPU kicks my old junker's butt, though. So the test 
might be measuring CPU performance more than accelerated video.

Aloysius - I already described the help, and Cyphre kind of confirmed 
- I noticed, that this hostkit is some linux version. When you look-up 
netdb.h, it seems its inclusion belongs to non-Windows #ifdef. So 
please go to /src/include/reb-to.h directory/file and rewrite the 
definition to: #define TO_WIN32

Well, I want to make sure that Brian, Cyphre, Henrik, Maxim, and 
a few others have a chance to say something... since they're going 
to be some of the primary users.