World: r3wp

It is like VID list style - the worst ever - you work with exposed 
variables you don't have normally the chance to know about (from 
the VID style perspective pov) - I consider it being very bad design, 
wrong ecapsulation.

I don't understand what is 'dirty's purpose, but imo clicking Quit 
button, which clearly maps to native 'quit function, should simply 
quit, nothing else whatever else you have set. The only case would 
be, if I would put some sensor transparent face upon button to catch 
events, or something like that.

Can RT please release RebCmdView for 1.3 ... Thanks.

my observation is, that even if I change my design to view/new, I 
still have to use the dirty-flag trick ...

and dialog box system seems to be still rather messy. I changed my 
design to view/new. I have two layouts, plus insert-event-func, which 
can show another dialog box (help screen) after F1 is pressed, from 
both windows I use. But - once there is my help displayed, and I 
alt-tab to the window 2, unview/only that window does not work ...

I have found very shortened example - simply the case, when you redefine 
layout several times - maybe it is wrong aproach, but because of 
grid I always called layout once again, to fill-in list value by 
data:


view lay1: center-face layout [btn "lay2" [view/new lay2: layout 
[btn "Return" [unview/only lay2]]] btn "close" [unview]]


now run above line, press lay2 button, go back to first screen, press 
lay2 button. It gets re-rendered. Try to press "Return" button on 
lay2 - it does not work anymore ...

is that because of nested layout? Is that becuse I re-define lay2 
in memory for the second time and it confuses rebol?

I think that I redefine lay2 for the second time, so that rebol looses 
reference to the first one, and so unview is not able to unview first 
instance of window ...., so maybe actually my bug, not rebol's? :-)

in this case, move lay2 a bit ;) it gets not re-rendered, its a new 
window. lay2 now points to second lay2. you close that. you see the 
first window (but looks the same.. you unview lay2, but thats now 
the second, closed lay2, not the first you are really viewing.

ah, you typed while i typed, yes, correct.

hey guys, we have some gfx gurus. What about some splash screen content? 
Today I made small util using rebol and my friends in office were 
really happy about it - I exported telephone list from Lotus Notes 
client monster and put it into View 1.3, rebDB plus Cyphre's my-list. 
They suggested me to add some nice splash screen and to send it to 
Lotus Notes team to show them we don't need LN for such tasks :-)

I know that sometimes very little is needed to produce nice effects 
...

cross-fade in tests? fade ln-logo to rebols :)

I can find some nice demos in section of Desktop, but I am not sure 
I would succeed to adapt e.g. Imagination for my help screen - besides 
that, it is longer than my whole tool :-)

fading demo seems to be short. maybe create images with imagination 
and fade between them?

what do you mean by fading?

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