Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [platform-swt-dev] Tab order & drawing (Z) order


Here are all the conceptual orders:

Child order
        - the order of children returned by Control.getChildren()
Z-order
       - the stacking order of the widgets, changed by Control.moveAbove()/moveBelow()

        - same as child order
Tab order
        - the order that widgets are traversed when the Tab key is pressed
       - default to be the same as child order but can be overridden using Control.setTabList()

Layout order
        - the order that widgets are layed out
        - some layouts are not sensitive to ordering (FormLayout) so it doesn't matter
        - for layouts that are sensitive to ordering (RowLayout) same as child order

What API would you suggest to control layout order, given that some layouts don't care?
Probably the API would be specific to the layout.



"Ivan Markov" <ivan.markov@xxxxxxxxx>
Sent by: platform-swt-dev-admin@xxxxxxxxxxx

02/28/2003 07:49 AM
Please respond to platform-swt-dev

       
        To:        platform-swt-dev@xxxxxxxxxxx
        cc:        
        Subject:        RE: [platform-swt-dev] Tab order & drawing (Z) order



> Changing the z order when the tab order changes will have bad
> consequences.
>
>  For one thing, the tab order does not always contain all the children
> that appear in the z-order because some children like Label can not
take
> focus.  What will you do with the other widgets?

Controls that can't take focus like STATIC (Label) are not traversed on
Windows, no matter where in the Z order they are.

> Further, the z-order is used by layouts such as GridLayout to
determine
> the placement of widgets within the cells of the grid.  If the user
> chooses to change the tab traversal order, this will also impact the
way
> widgets are laid out which may not be desirable.

Point taken. Although I dare to say that laying out controls by their Z
order is questionable design decision as well.

> The way setTabList is used in Eclipse is to exlude some widgets from
the
> tab order so that keyboard navigation will be faster - e.g. when an
editor
> has focus, the views are excluded from the tab order so keyboard
> navigation takes you to the toolbars and the editor only.

Windows allows controls to be dynamically included/excluded from the
traversal order (which is a subset of the Z (drawing) order) by
setting/clearing the WS_TABSTOP flag using SetWindowLong().

Anyway. I found other reasons not to use the Fox implementation of tab
traversal. For one, if I use it I think I won't be able to implement the
SWT.Traverse event behaviour. Oh well. Seems like I'll reuse most of the
SWT/Win32 implementation. :)

Thanks!

>
>
>
>
>
> Steve Northover/Ottawa/IBM@IBMCA
> Sent by: platform-swt-dev-admin@xxxxxxxxxxx
> 02/27/2003 01:10 PM
> Please respond to platform-swt-dev
>
>
>         To:     platform-swt-dev@xxxxxxxxxxx
>         cc:
>         Subject:        Re: [platform-swt-dev] Tab order & drawing (Z)
> order
>
>
>
> There is only one concept of Z-order and this is used by default for
> traversal order.
> Composite.get/setTabList() can be used to override the default
traversal
> and has nothing to do with Z-order.
>
>
>
>
> "Ivan Markov" <ivan.markov@xxxxxxxxx>
> Sent by: platform-swt-dev-admin@xxxxxxxxxxx

> 02/27/2003 10:43 AM
> Please respond to platform-swt-dev
>
>         To:        platform-swt-dev@xxxxxxxxxxx
>         cc:
>         Subject:        [platform-swt-dev] Tab order & drawing (Z)
order
>
>
>
> Hi,
>
> I was just looking at the SWT/Win32 & SWT/GTK2 sources I noticed that
SWT
> has in fact two conceptions of controls' order:
> 1)       Drawing order, manipulated via
Control.moveAbove()/moveBelow()
> 2)       TAB traversal order, implemented all in Java, manipulated via
> Composite.GetTabList()/setTabList()
>
> Is that true or I've overlooked something..?
>
> If so, why the need for two different orders? In The One True
Operating
> System, there is a single, "Z" order which defines both of these. Same
in
> other toolkits I've seen J
> Also, it seems to me that by using Windows Dialogs for Composite,
Shell,
> etc. the TAB traversal Java code could have been avoided. I'm probably
> wrong here though.
>
> Guys, I need to know the answer because I'm planning to unite the two
> orders in SWT/Fox; (setTabList() will have the side effect of changing
the
> drawing order and vice versa).
>
> It shouldn't have serious implications shouldn't it? I mean, if
controls
> are to be TAB traversed, they normally don't overlap, so the drawing
order
> is a non-issue. And if they do overlap, usually the first covers all
the
> others, so TAB order is not an issue.
>
> Am I wrong? Probably. I know OTI/SWT developers do read the list so
please
> be so kind to answer me at least once - constructively. J
>
> /Ivan
>
>
>
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-swt-dev


_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev



Back to the top