World: r3wp

SET-FACE is already reserved. Adding HIDE as a shorcut is of course 
possible.

that a face is inadvertently presented as zero-sized

 - this may occur, should a style implement its own layout engine, 
 which is possible to do.

Re the 0x0 issue: I am sure, that the solution used will satisfy 
you.

hmm, I lack imagination for all possible usage cases. But we should 
have in mind the most complex scenarios, which might be some animations 
along with timers, simply a graph structure.

Re the HIDE face: the problem is, what the function should do? (which 
of the four variants it is you want?)

Ladislav - is the solution part of posted r3-gui version from yesterday? 
Or just something which will arrive shortly?

A new one, not posted yet

Animation should be an entirely separate part, to make it easier 
to discuss, design and change when the time comes, possibly an extension 
of SHOW-FACE.

Without timers we can only dream of animation right now.

I agree with Henrik, and I reiterate my uneasiness with face size 
0x0 == hidden. Conflating the two concepts creates the problem of 
how to separate them, which may be difficult, or impossible.

I would not like that in order to hide a face, I would have to set 
its size to 0x0. That means that in order to restore the visibility, 
I must store its previous size somewhere else. So squashing two concepts 
into one value means one or both of them just pops out somewhere 
else, confused, or some state information is lost.

Yes, that is why the two *will* be separated

Cool, my worries dismissed then, as I agree with Anton too ...

Oh, I'm sorry, I probably should have re-read the discussion since 
last night.

re Animation: Recently I talked with Carl about it briefly. He plans 
to add timer port device + mezzanine support functions for that purposes. 
No EST has been said though.

Carl should just make the device extension API .  then these concerns 
can solve themselves on the Open Source side of things.

From what I know the 'custom devices' will be available in hostkit 
after 3.0.0 release.

Of course it is possible to implement timers as embedded extension 
if someone can't wait for this feature.

will that timer device have any influence on the task design? Well, 
being it one way or other - it is sadly another regression from R2. 
OTOH I think that most of R2 GUIS did not rely on timers, or am I 
wrong?

I prefer to have it designed properly, rather than to rush the implementation. 
And I agree with Max - there is imo long time plan to have extension 
API for devices ...

Cyphre - say hello to Carl :-)

most of R2 GUIS did not rely on timers...

, why should they? R3GUI can be perfectly functional without timers, 
only bit boring.

I used it only several times - to initialise GUI automatically, and 
to create a primitive gif-anim player ...

It seems like the SHAPE dialect in RM-Asset version of A110 is different 
from the original one. Is that intentional? I cannot draw and fill 
Chinses character glyphs using this version.

Maybe you should show us the difference.

Actually, I think It's bug. For example, MOVE seems not working at 
all. LINE used to mean LINE-TO, now LINE are just LINE. ... and so 
on.

Yes... so we still need the simple example to show it.. best to use 
different group (R3 graphics) as it's not related to GUI.

I would like to give GUI a try, but to be honest, the current public 
state is good only for reviewing, not for participation on the developement. 
I mean... I really don't want to hack one file which has 256kB. So 
I'm asking again, wouldn't it be better to put it into a real source-code 
system (or in case you have one already, which you probably have 
internaly, to create public mirror of it).

I would like to give GUI a try, but to be honest, the current public 
state is good only for reviewing, not for participation on the developement. 
I mean... I really don't want to hack one file which has 256kB. So 
I'm asking again, wouldn't it be better to put it into a real source-code 
system (or in case you have one already, which you probably have 
internaly, to create public mirror of it).

Also I miss the basic functionality in current GUI. Like chance to 
view a simple GOB. For example one of these: http://www.rebol.com/r3/docs/view/gobs.html

Maybe RMA team could set-up a blog too (re Amiga group post about 
OS 4.1 progress). I know there's probably not much time for that, 
but I do remember some of Henrik's articles, and it was really nice 
to read :-)

It would be the place for occassional posts, showing e.g. short examples 
of how to use new features, etc. - thu stuff you are asking for here 
anyway :-)

The GUI is still changing too much for particular blog articles. 
Around on a daily basis I get updates on 5-10 source files, which 
I don't have time to go through, otherwise I would publicize more 
information.

Oldes, VIEW is due for an overhaul and the concept of viewing any 
(or at least most) REBOL datatypes is something I wish to implement, 
but that's low priority at the moment.

That's the main reason why to have public repo.. so one can at least 
see what is changing... and maybe also why.

GUI work log update: currently, the ON-CONTENT actor is being reworked. 
Interface and behaviour are being changed (different arguments, adjusting 
"boundary case behaviour"), some bugs revealed and corrected during 
reworking as well.

For those not knowing the purpose: the ON-CONTENT actor is meant 
to handle content changes of container styles.

Oldes, I agree. We planned to move to Git to make this simpler, however 
the window for making such changes, I think, has closed for this 
year. Too busy...

on-content ... interesting ... so we will get specific per style 
type kind of handlers?

Henrik - if 'view is going to be overhauled, add 'unview to the overhual 
game too, please :-)

Pekr, that might happen.

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 ...

Henrik, wouldn't it be at least posible to pack the files separatly 
(not to have them all in one file)? It's really unusable for other 
people than you in such a state. Especially when you are modifying 
5-10 files per day.

It would at least help to understand what part is doing what... like 
what is draw related, what is for styling.. etc.

Oldes, that's possible. I'll try to make a zip archive of the current 
source directory.

I now agree with Jerry that there is a draw problem.

And it is related to GUI project as GUI project is the one where 
the draw is implemented as commands.

http://94.145.78.91/files/r3/gui/r3-gui-src.zip

I can't guarantee that it will work. There is a build script missing, 
but the resulting build should be similar to previously released 
builds. We have diverted from the build system to something else 
now, and I can't publish that build scheme.

thanks, that looks much more useful.

Maybe that zip archive could be added to the links page for R3 GUI 
project permanently?