World: r3wp

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?

ok, cool

Pekr, possibly, but that's out of my league.

There are also some docs and comments in code:)

Is the DRAWING style suppose to be working?

GUI work log update: ON-CONTENT revision done, debugging the changes. 
One of the changes is a removal of the PANEL/FACES block. Reasons:


- data aren't normalized, since the contents of the panel are listed 
both in panel/gob and in panel/faces

- thus, twice as much memory used, and unnecessary maintenance of 
the panel/faces block is necessary

- the not normalized nature was visible anyway, since the order of 
faces was not guaranteed to be the same

- to get the block when needed, it is possible to use a FACES? function 
returning such a block on demand

what about calling it get-faces?

or get-content? That would be a good match for container styles? 
....

I assume FACES? will only be used inside styles, so it should be 
a short name.

faces-of

+1