Re: Proposed tabbed_pane widget changes

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 23 July 2003 3:31 pm, Michael Flanagan wrote:
> Alex Russell wrote:
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >>Next item. There is no mechanism to have the widget automatically
> >>switch to the next tab other than by clicking on it.
> >
> >I think that Shift-left and Shift-right keystroke modifiers (or
> >something similar but not caught by the browser) might also be
> > useful here.
>
> Ya, I thought of that too, but it would conflict with our internal
> table widget which already co-opts those keys. I'm still trying to
> think this one through.

"Use the focus chain, Luke"
NW provides a way of bubbling keystroke events to components (not DOM 
nodes) without having each component try to co-opt a particular 
keystroke handler on document.body. Basically, when you click in a 
document that hosts NW, a "focus chain" is created from that click 
event. It contains a reference to all of the components which are 
ancestors of the last clicked DOM node. We then use this chain when 
we handle a keystroke to search up the chain to determine if anythign 
"catches" it, in which case bubbling stops. The first component 
object that's a logical parent and has registered a listener for a 
specified keystroke sequence will "hear" the keystroke and prevent 
it's parents from also receiving it.

In this way, NW transparently handles this question. You just nest 
your widgets any-which-way and register keystroke handlers via 
components, and the rest is taken care of for you.

This might go back to a wrapper widget for your sort table, which 
should be easy to write (let me know if you need help with it).

> >>I would like
> >>to implement the capability so that when you 'blur' off the last
> >>input/button/select/textarea element on the pane, it
> >> automatically makes visible the next pane in the tab order.
> >
> >Um, what if I got to a previous element in the same container? Do
> > I then still get switched?
> >
> >I think the intended behvior here is to move to the next tab if I
> >tab-through the last input element, not necessarialy if I blur off
> > of the last one.
>
> Correct. I believe we can check to see what other key's were in
> effect at the time of the 'blur.' If a modifier key was also in
> effect, then we would not change pane's. Only if it was a 'tab
> forward' so to speak (provided you were on the last tab).

Ok, cool. Just wanted to ensure that we're talking about the same 
thing.

> >>Also, the current tabbed_pane widget doesn't play nice when used
> >> in forms. It seems as though it was intended as a display only
> >> mechanism. I would like to chance it's current behavior which is
> >> to actually sub out the content of the pane (it basically does
> >> DOM node swapping) for a different one, to a system where the
> >> visibility of a pane is determined by a CSS style of hidden /
> >> visible = false, whatever it is. This would have the benefit
> >> that the form fields would actually exist in the DOM then when a
> >> submit was done.
> >
> >I think this makes some sense. Although this brings up the
> > question of whether or not all tabs are treated as a single form
> > or multiple forms?
>
> Ya, this I don't know about.... for now I'm happy that we're ahead
> of the old tabbed_pane widget (we have this working with the hidden
> div thing now).

I don't think that re-implementing will necessarialy be a good plan 
anyway. Fixing and extending will get us there much more directly.

- -- 
Alex Russell
[email protected]
[email protected]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/HvwjoV0dQ6uSmkYRAkJkAJoC9hR372GKW5+FzXJvvq2wmafhAACeLihb
XKhcQrrtViI2LSo0V5gBEfA=
=akPd
-----END PGP SIGNATURE-----


_______________________________________________
The netWindows developers list: [email protected]
http://netwindows.org/mailman/listinfo/devel_netwindows.org