Window focus.

[akrasuski1]

I don't think this one is needed, but I opened the issue for potential discussion. IMO it's widget-developer's and end-user's responsibility to ensure action groups don't collide.

[abenkovskii]

end-user's responsibility

There's no such thing.

[abenkovskii]

What will happen with number edit in the second window when I open a main OS menu by pressing 1?

[akrasuski1]

The more I'm thinking about it, the more I'm leaning towards it. Problem you stated is not that bad - one can argue user should just finish typing in the number, and only then think about running other programs. But without window focus, we cannot have any kind of "press me, when you're ready" type of windows. And that's quite a big issue.

[abenkovskii]

one can argue user should just finish typing in the number, and only then think about running other programs.

I think that even you will accidently hit 1 from time to time.

[akrasuski1]

So the window focus, as I see it, should work as follows:

1. One window is selected at any particular time.
2. The selected window should be visually different form others, be it dfferent corners, whole border, etc.
3. User can change window focus via: a) 1/2 - cycle back/forward b) just 1 - cycle forward Which one is better? Likely (a), but if (b) is not that much worse, I'd accept it, in order to preserve action groups.
4. There are two main ways focus can be implemented: a) make widget-developers create another window functions, onFocus_window_nameofwindow (for the first frame it has focus) and input_window_nameofwindow (for all frames it has focus) or something to that effect. I don't really like it, since the widget creation is already complicated enough. b) create a process function has_focus and make widgets relying on user input check the focus status before processing any input. I prefer option (b), but feel free to discuss.

[abenkovskii]

1. I agree that situations like: "if I press 5 it will affect window X and if I press 7 is will affect window Y" should not be possible.
2. Windows share corners so making the whole border differ may be visually better. We will probably need to do some experiments though.
3. b) is acceptable but only if the list of windows that can be selected is smaller when the list of all windows i.e. the process can make it's window unselectable.
4. I'd use (a) in Python or in C++. But in kerboscript there are not enough abstraction to implement it in a simple way and "simple is better than complex". So I vote for (b).
5. If focus is a property of window than if the process of the window changes the focus will transfer to the new window owner.

[akrasuski1]

-3. That is not bad idea, but I think it would be rarely used. So I think we should do (a) anyway. -5. Good point. I think focus should be actually a property of window and not process - otherwise we would have weird situations with child processes. I think adding another entry to os_data structure, called current_focus, with currently focused window index in it.

[akrasuski1]

But still, there can be a utility function, saying whether a process' associated window has focus.

[akrasuski1]

I think I've done it. Now I'm going to rewrite current widgets to support it and see what happens.

[abenkovskii]

@akrasuski1 Is it safe to run it right now Or you are in the middle of a change?

[akrasuski1]

You can test now, just don't expect that the windows respect their focus.

[akrasuski1]

Now they do.