World: r3wp

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

You can receive lot of events for 0x0 face even without timer, you'll 
be surprised.

If so, you can't auto-hide the face by just setting its size to 0x0? 
That seems like an ugly hack to what could be implemented by 'hide 
function? Well, if we have 'show, why don't we have low level 'hide 
one?

Simply put - I am for separating hiding faces from resizing the faces/gobs. 
But I will let it to the clever ones :-)

There was HIDE-FACE that is removed with this implementation, you'll 
just use SHOW-FACE face 'hidden

SHOW-FACE and HIDE-FACE allowed only two states, this method allows 
more states.

compare the code:

show-face face 'hidden
hide face


which looks more readable to you? ;-)  Why to overload show? We have 
'View, and 'unview. And with two separate functions serving its purpose 
you can implement more functionality for each of them imo ... I must 
be missing something :-)

you can use refinement. I can see, that with R3, we departed from 
refinements ... why? Look at 'unview ... unview none, unview 'all 
.... why not just uview, and unview/only, as with R2?

ok, I said enough for others to get my message, it is just my opinion, 
after all :-)

it's not just show/hide face anymore. SHOW-FACE sets face's visibility 
and usability mode. Maybe you can come up with better name, this 
one is left from previous implementation even if does currently something 
different.

Pity following feature was removed - we could have used bitsets - 
that would allow even for more combinations - http://www.rebol.net/r3blogs/0077.html

more combinations?

Yes, generally all possible states - visible ignored fixed hidden 
no-resize etc. could be part of a bitmask, and IIRC that is the aproach 
win32 is taking. I thought that named bitmasks are implemented, but 
they were removed.

But some states are mutualy exclusive, so this is not such a good 
idea. You can also achieve the same with block!

Yes, not a big deal for me ... except the idea of using size 0x0 
to express the hidden state :-)

Image the UI animated. You have button with size 100x20 that gets 
smaller until it reaches 0x0 which effectively means it gets hidden.

I don't agree with having 0x0 as hidden. It is an implied state, 
that would occur any time the X or Y size becomes zero. There are 
behavioral issues to consider, such as, whether you want to obtain 
data from the face, using GET-PANEL, or how tabbing and disabling 
behaves with a zero sized face. If the layout is dynamically created, 
so that a face is inadvertently presented as zero-sized, you will 
get topological side-effects.


For animation, you would have a start and end position. Animations 
should not express anything about face states. Only dimensions, offsets, 
transparency, colors, easing are relevant with animations.

For that matter, a face can also be considered hidden, when its parent 
is 0x0, or if the face is located outside the viewport of the parent 
face.

if "SHOW-FACE sets face's visibility".. than it should have name 
SET-FACE... btw... I'm with Pekr that  "HIDE face" is nicer than 
"SHOW-FACE face 'hidden"... I don't expect to use word SHOW when 
I want to HIDE something.

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 :-)