World: r3wp

I use hidden panels and buttons all the time .. to reduce GUI clutter. 
 When the user does something that satisfies some condition, I then 
show these hidden buttons, panels.

Other systems use ghosting to achieve the same benefit

there would be a difference between disabled and hidden items.

hidden is invisible disabled

yes, it could be that

i read an article stating that the 2D acceleration on windows seven 
was really poor

I reworked the traversal code. It should correspond now to the diagrams 
on the implementation page on the wiki. It's also much easier to 
read.

Do you have tooltips in this gui?

I think an hidden item should not be disabled by default (allowing 
"ghost" validation).
I you want both, then add the both flags HIDDEN + DISABLED

i mean it should accept some events event if it's hidden

*even if

what sort of events?  resize ?

VALIDATION

required for tab-panels

When you switch of tab and hide some sub-panes, then when you validate 
the whole screen, you need to validate event the hidden ones

if they're hidden you can't correct them if they fail validation

why not ?

just show them if validation fail

changing of state is a dynamic behaviour

Hidden faces should still be accessible programmatically, but can't 
get focus or key events, including access keys.

To clarify, depending on the event loop model, you may be able to 
post messages to them, but the standard UI event loop won't.

exact

graham, tooltips will come. I'll add them to the spec.

Don't make the UI depend on tooltips too much - they aren't supported 
on touch screen UIs, and those are becoming more popular.

Well, that's an app decision not a framwork one IMO. Designing for 
touch screens looks different in a lot of aspects anyway.

to my mind a tooltip should be an HIDDEN widget you add or not in 
a panel. 

This widget would "sense" the move events in its parent container 
and decide by himself if he must  pop up or not.

Framework design can shape app design. For a new GUI framework, it's 
best to support a variety of interaction models. There are a lot 
of apps written on legacy frameworks that are having trouble adapting 
to the current interaction models. For instance, we better assume 
that there can be more than one simultaneous input - multitouch is 
here already.

Does r3/view support multitouch?

The idea that Rebol has to be the same on all platforms is a little 
crippling as it means you only have the lowest common denominator

i'm agreed that's a compromise to find betwin interesting unique 
feature and common features allowing your script to be ported

and all this in less than a mega where much of the actual other advanced 
script language  use mode than 20 Mo

rebol for itab that could be really fun ...

for scripting purposes, having a script that works on all supported 
platforms is a reasonable aim.
I just don't see that it works for GUI based applications

If a particular linux distro doesn't support multitouch, what relevance 
is it to me working with Windows?

if a distribution of linux doesn't support multi touch you still 
have the oportunity to port the needed modules  to make it feet your 
distro that's less problematic than windows for example

linux is the most configurable and modular OS existing ...

Say you want to write a multiplatform gui app, well, then you make 
sure that what you do is supported.

and that flexibility is a part of a problem for setting up a small 
all in 1 VM like rebol ...

If you're not interested, you shouldn't be hindered by a philosophical 
view ( pun ) that everything should be the same.

graham yeah but in fact most of the time when you write a software 
you make it first to feel your need or the need of your client ... 
then you don't think out of the box if that guy will be able to run 
your script on his I-phone with the same posibilities that you initially 
planned

graham it's less evident than that ... things that are supposed to 
works on the 3 main OSes only works properly under Windows XP ... 
(i think area-tc shown that the portabilities in draw area is far 
from perferct in R2 )

and once again i'm not saying that's not to be done ... i'm saying 
if we take in charge unic specs according to a given documentaton 
then you have to provide a clear information mecanism explaining 
to the user why the technologies involved in the script he wants 
to use is not supported on the plateform he is under if that's the 
case

no multitouch wit threading  ( you can't have several sources of 
 event and treat them at the same time without threading system)

The OS detects the multitouch event and sends it View

I don't see why we need multithreading for that

cause you need to clip the actions to the event you receive

next issue is storing the tab face in the window face... this is 
necessary to store a tab navigation frame per window. I wonder how 
this is going to be done...

I thought that the whole point of Carl's GUI was to allow app developers 
ignore all of the little details about how the app looks and acts 
at runtime and just focus on the semantics. Let the stylist worry 
about the appearance, and let the infrastructre people worry about 
whether the input came from multitouch, mouse and keyboard, whatever. 
Separation of form and function.

people are so used to R2 VID, that it's hard to get out of that thought 
process that the GUI must be completely hackable. :-)

And I think it should be, by the GUI hackers. But those hacks should 
be able to be used by others who don't want to have to worry about 
that stuff (like me).