World: r3wp

two images before each other, the first turning into the second by 
alpha-effect.

its in desktops test-folder

Pekr>Try to press "Return" button on lay2 - it does not work anymore 
...


It still works back in View 1.2.47... (I'm sticking with this version 
for a short time longer.. )

as Cyphre suggested to me privately - first instance of lay2 looses 
reference to the window, as it is regenerated during second button 
press. But that "face" remember its parent face. Try to replace unview/only 
lay2 with unview/only face/parent-face .... the question is, if that 
is a bug or not - should we be able to create such wrong code using 
VID?

I am starting to think, that it can't be considered a rebol bug, 
but a programmer bug. In such case though, ppl have have knowledge 
about windowing system, how it is organised in pane, etc., so View 
internals - knowing just VID will not be enough ...

... that setting "f/dirty?: no" in my complaint above is another 
example, that something is wrong here ...

button press should work no matter what other UI element state is. 
The only case where I can understand button not working would be 
if you would put some transparent face upon it to catch events ...

later

I guess you produce something like that by switching layout. usually 
both is called, the text-action because of dirty, then the button-action. 
but somehow view forgets to call the button when you switch layout 
and call focus. maybe because the layout with the button is not visible 
after the text-action? its a bug for me, but i guess it could be 
tricky to fix, lots of special case-code.

petr: it's not a trick. dirty? is there by "design", and it is handled 
by a event func. you need to handle it manually in cases like that. 
so, not a bug, just lack of proper documentation.

How do you make a shadow effect for a face, like Cyphre does in its 
menu style ?

So ignoring the button press in this special case is not a bug?

imo it is a bug, period :-)

look Gabriele - imagine strict object system - so - pressing button 
does its action, not something else, unless some other element is 
layered above it. So what is VID for? For whom? Typical VID user 
was compared to HTML coder, so why should user care of some dirty 
flag? What is dirty flag after all? It is VID internal, and it SHOULD 
NOT be imo exposed to user. List is another example of BAD design.

Can you provide an operational definition of what you mean by BAD 
design in respect of 'List ?

yes, simply put - list's supply block - you have to know pretty much 
about style internals in VID level - suddenly you use variables you 
have no clue about ...

when I look at Cyphre's my-list, there is nothing like that ... all 
configuration done by exposed facets ...

This then applies to fields as well

... after all, IIRC Carl once said that current 'list was done in 
something like 5 minutes or so beofre View alpha release :-), and 
IOS 1.3 project contained new, improved version - so I also wonder 
why that version did not make it for 1.3

Or, you could just read the documentation regarding the use of 'list

fields? Why? Where? I am able to use fields mostly without such hacks 
...

I start to think that some ppl fail to admit something could be just 
done better, even if style creator admits it :-)

Is your complaint then one of a lack of documentation?

We had such discussion before, do you remember? Many ppl arguing 
with Terry, that basically rebol draw is capable to compete with 
Flash and nowadays we are all applauding AGG inclusion :-) I just 
try to point out to things I don't like and I try to believe that 
my pressure may lead to think out some things more deeply for 1.4 
release ...

So that we don't have this discussion again, why don't you draw up 
a critique of what you feel is bad design regarding 1.3, and then 
we can work from there?

It's hard for all of us to start from the same point unless all of 
us remember past discussions.  So, let's have a summary document.

Yes, maybe documentation. But I can still see a trouble with 'list 
and if 'field is similar, than our bad. VID is abstraction. It was 
meant to ignore errors in code if possible. It was meant to configure 
style using facets ... we started to expose more facets 'edge ,'font-size, 
etc., and if not sufficient, the last part is using 'with and directly 
accessing object values. But 'list goes even further, as 'supply 
block deal with variables like 'count ...

Graham - why? My RAMBO report regarding non working button in some 
case was dismissed - so - no bug ... I just fear that we will have 
to document well all such "exceptions"/"by-designs", call it whatever 
...

Why? To communicate of course.  To persuade at best.

RT has a small habit of changing their minds.

Graham - and besides that - we don't know the plan, do we? It is 
difficult to work/cooperate, as RT choosed the way when design is 
done by few ppl. It is good on one hand, as work is being finally 
done and we have got 1.3 out fast enough, but no docs follow, no 
plans follow. I e.g. asked someone from RT's extended team describe 
proper behavior of Installer, to actually test what is desired and 
what is not. But I can imagine docs are always lower priority, it 
is simply natural. But - I would really like to know, what goes for 
VID 1.4 or 1.3.x, whatever - only styles additions? What will happen 
to focus system, how will accessors be utilised, the same for doc 
subobject, what happens to VID in general?  - btn uses bitmap, but 
we've got powerfull AGG inside. Also - how will effects be merged 
with draw? We want to keep compatibility on one hand, but surely 
we don't want to have powerfull gradients withing draw, and old-ones 
within effect block ... So - don't ask me - I would expect some developers 
oriented document, short description of what and how is gonna be 
solved. Don't forget that it seems text mark-up is gonna be introduced 
- so - many changes, in hundreds of possible ways - so I will not 
propose conrete solution, if I know nothing about more general plan 
...

You don't have to know what is planned... only need to document inconsistencies, 
or bad design as you see them.

If Cyphre is working for RT, and his list is not included in 1.3, 
presumably he knows the reasons ...

his list is not list, it is full featured grid and it needs additional 
work ...

I don't want to sound harsh, but I start to see RebGUI as more consistent 
by design. It surely does not allow some things, but ...

but well, if I am alone seeing some things as kidn of problematic, 
it is not worth to document imo. I am not good in VID nor View, so 
my impression is, that if many other ppl see no problems with things 
how they are, then I must be wrong ...

Or, other people just give up before they get to be good in Vid, 
or view ?

Pekr, Docs are being worked on. VID update is also in the plan, SDK, 
other platforms etc There is a lot of work being done. Some of this 
is sequential some is in parallel.

http://www.compkarori.com/vanilla/display/list+examples


Here is documented the face, count and index variables.  There are 
similar functions throughout VID.

Allen, are you in the know somehow?

Yes. But a lot of this was stated when the journey towards 1.3 started, 
http://www.rebol.net/article/0161.html

Perhaps it is time to consider a VID community documentation project 
?

Allen - there is particularly nothing interesting or usefull in above 
link ...

... in regards towards 1.4 ....

Possbily timing for the doc collab project is when REBOL/Coop arrives 
http://www.rebol.net/article/0146.html.

The rebolfrance rebol dictionary is a good example of community documentation

Really Pekr? To me it says what order things are going to happen 
and what is planned around & after 1.3 release.

except OSX appears to the left of 1.3 in the diagram :)

not in diagram but is in text. ie changes required for OSX

That roadmap really needs updating. Public works under construction 
can really get you lost.