tabstop property

[Guest]

I saw on the roadmap that keyboard interface is planned for release 0.7 so i assume that nothing has yet begun. If i'm wrong please let me know.

I'd like to contribute to the development of this feature. My first goal is to navigate between all active Editboxes using the Tab key. This should be quite easy, i just have to add a property called "tabstop" (it's the name used by microsoft in MFC class) which tell if the Editbox can be reached when pressing Tab. Then, when i catch a "tab key pressed" event, i move the text cursor to the next reachable editbox which can be found using the WindowRegistry of WindowManager.

After that, i'll try to add this property to Buttons and to enable switching between both widget but it seems to be more difficult because the state "selected" doesn't exists (and doesn't have any graphical representation). Any advice on this point are welcome.

Does it correspond to (a part of) what you wanted to do for release 0.7?

--
Chris

[CrazyEddie]

All of the following is just off the top of my head without too much thought...

A boolean 'tabstop' style property is definately required, as well as some unsigned integer property to allow us to specify the required tab ordering.

Widget-to-widget tabbing should be implmented against the child windows of a parent window rather than the entire window registry, since the window registry is not ordered in any way and would have focus jumping around all over the place in complex layouts.

There are some issues that will need to be correctly worked out with regards to granularity of this feature and if or how the decision should be made to move between higher level constructs (for example, it might be that we allow tabbing between the buttons and thumb of a scrollbar, though the scrollbar itself may be a tabstop of a higher level window or dialog, so it must be considered how or if to allow the user to navigate between the different levels in a hierarchy).

Another thing that will likely be needed is a new state in Window so that concrete classes can render some indication as to where the current 'focus' is. Obviously with the Editbox this is fairly simple, since we already have that additional state, I think it should be possible to promote that state into Window with the minimum of fuss (there is some additional code needed already, since there is a half-bug related to deactivating an editbox).

There's also a couple of ways of capturing the tab press (and in future other keys too), so do we grab that first and always swallow it, or should we allow client code a chance to see the key press and only do tabbing if it is not handled by the client.

Anyway, just a few random thoughts

CE.

[Guest]

Here's what i plan to do:

Adding property "tabindex" (uint) to the Editbox widget (explanation below).

Adding property "tabgroup" (bool) to the Window widget.

In the Editbox class, modifying the onKeyDown function to handle the Tab key. If Tab key is pressed, i'll check recursively the parents of the active window until i find one with the property "tabgroup" = true. This property means that we don't have to check windows in a higher level because the user doesn't want to navigate in another group. As far as i understand it, it'll solve our problem of granularity, won't it?

Now that we are in this "root" window, we'll have to find the child with "the smallest tabindex higher than the tabindex of the active window" and, of course, if there's no higher value, go back to the beginning.

Finally when we found the right window, change focus. You'll notice that only the widgets with a non zero value for tabindex are reachable so i don't think property "tabstop" is needed anymore.

Do you agree with that?

And could you please tell me more about this "half-bug related to deactivating an editbox"?

--
Chris

[CrazyEddie]

Your approach sounds pretty good. Plus, it should not be too much trouble to shift things about later when things are extended to include all other widget types.

The 'half-bug' is to do with the 'deactivated' state and notification. When a window is deactivated, the notification generated by it's children gets sent with the wrong window parameter. This probably doesn't affect anything related to the tab behaviour, just that you jogged my memory about it

CE.

[Guest]

Here's the situation :
For now, i'm able to navigate through Editboxes and MultiLineEditBoxes using the tab key. I can define the order in which the widgets are reached using the "TabOrder" property (i didn't used TabIndex as said before because there's already a property with this name in TabControl widget). I can also bound some groups of widgets with the TabGroup property.

The function that performs this work (i.e. to find the next widget in a bounded set of widgets) is called "handleTab" and is defined in the Window class.

The "tab key down" event is currently caught in each widget class (Editbox & MultiLineEditBoxes for the moment) but i'm not fully satisfied with this situation. I'd like to move it up to the Window class but i'm not sure it's the way you want the feature to work. Please tell me what you think of the idea.

And i also have a second question to ask : when my function "handleTab" finds the window to reach, what should it do? I currently call the "activate" function on this window. It works fine for EditBoxes but it doesn't on other widget. Any advice to give?

--
Chris

[CrazyEddie]

With regards to property names you might consider something based around "TabNavigation..." so it's explicitly clear what's going on, the same goes for any methods and what have you; this basically ensures that there's no chance for a name clash anywhere down the road either

So log as the final results are acceptable, I have no problems with the tab event handling being in the base Window class, since this is what I'm really after, so that any Window/Widget can be navigated to in this manner.

With regards to the "activate" issue, what is the exact behavior that you're looking for?

CE

[Guest]

When you call "activate" on an Editbox widget, there's a graphical change (the carat) that lets the user know where the focus is. When navigating with the tab key on an MFC window, the same exists on every widget. Here's an example of what i mean for buttons :

The first one is normal,
the second is disabled,
the third is in the state "selected" which doesn't exist for the moment in CEGUI.

Actually, my changes already work with buttons but as there is no way to know where the focus is, it's totally useless. That's why i thought i had to create a new state in each widget (different from normal, hover, clicked & disabled) to handle this possibility. I think it will also be required if we want to catch some other inputs. For example, when the system catches a "Return keydown" input, it should have the same effect as clicking on the "selected" button.

--
Chris

[CrazyEddie]

Right, yes I understand. We need to add something like this, though I don't like 'selected' as a name, I'd prefer Active or something of that nature (especially since 'isActive' basically already returns this information), and to save confusion with things like radio buttons which already have a selected state (but obviously means something different). This should go in the Window base class since it will be usable by all widgets.

This addition will require an update to every widget, and also the source imagesets to add some appropriate imagery (I knew I'd be having to do this at some stage).

I have various 'state' extensions planned, though nothing that will get implemented before the Falagard widgets.

CE.

[Guest]

So what's the point now? Do i have to wait until Falagard widgets are implemented or does it worth creating the new state and imageset now?

I should be able do the coding stuff alone (if you let me do it) but i'll probably need a little help with images.

--
Chris

[CrazyEddie]

I was not suggesting you wait for Falagard, that was just for information, Falagard is months away so there's no point in waiting for that.

I am quite happy for you to do the work, you have demonstrated a very good understanding of the system and your previous patch was of high quality.

Let me know if you intend to introduce a new state in the Window base class, or use the current 'active' state, and I'll start updating widgets to render something to relay this information to the user.

CE.

[Guest]

Here's the situation:
The "TabKey Pressed" event is now handled in the Window class. That enables the user to navigate through every widget using the tab key.
To make a difference between the activated widget and the others, i created a new image (only for push button right now) which is displayed as a new layer on the top of the current image. Thus there's still a graphical difference between normal and hover states. I don't know if my explanation is clear, i'll try to post a screenshot later.
I plan to submit a patch soon but i have another question before that. I want to add the ability to "click" a button with the Return key when it is activated and i don't know if it's better to launch the already existing "PushButton::EventClicked" event (which is the subscribed one most of the time i think) or to create a new event.
What's your opinion?

--
Chris

[CrazyEddie]

Sounds great. Looking forward to the patch

In reference to the event question, I think that the same event should be used for both; I believe that in most circumstances the means by which the button was 'clicked' is not important and it should be possible to deal with both possibilities via a single hanlder and single subscription. However, it might be useful to know whether the event originated as a keyboard or mouse event, so you might consider creating a subclass of WindowEventArgs which has a field to relay this information; by using WindowEventArgs as a base class we can ensure that nothing much breaks, while giving new functionality where needed

CE.

[Guest]

Patch submitted. Hope i didn't forget anything
The support for "Button clicked by the Return Key" should be operational.

--
Chris

[CrazyEddie]

Ok thanks

I've had an extremely brief look, and things look good. I'll make my best effort to process this over the weekend (got a few other bits to do first, but hopefully I will be able to get to this also).

CE.

[Guest]

The support for custom imagery is ready. A new property has been added to PushButtonProperties to let the user choose the image mask displayed when widget is active.
I also added the ability to navigate through widgets in reverse order using Shift+Tab.

Should i submit a new patch replacing the first one or wait until the first is commited?

--
Chris