Open smallB007 opened 2 years ago
Hi, and thanks for the question!
As said in the documentation:
source
indicates where the focus comes from. When the source is unclear (for example mouse events),Direction::none()
can be used.
It is, for example, how view groups know if they should give the focus to their left-most view or right-most view.
Some views don't use this parameter - for example a CheckBox doesn't care where the focus is coming from.
Hi, Thanks for the answer. Although I understand after your explanation the idea, I still think it is rather non-intuitive way of doing things. If let's say a view take(s)_focus, it really shouldn't care from what direction the focus is coming from. Source that brings that view to focus, yes, direction... mehhh... It just doesn't make clear "mental model" of the mechanics. Why would I care, which direction the focus is coming from? Left, right, top, bottom? What difference does it make to me (as a view). I am taking focus and that's that. I know I'm simplifying etc. Thank you for your answer and explanation.
A few examples:
Tab
vs Shift-Tab
, it changes whether the view receives focus from the Front or from the Back. Depending on that, it will either select the first button, or the last one.LinearLayout
, if it receives focus from the left, then it will give the focus to its left-most child. If it receives focus from the right, it will give focus to its right-most child.In the end, the source is related to the event that triggered the change in focus (pressing Left may move the focus to the left, and the source will be Right), but it doesn't have to be tied to a particular event. Some other actions may trigger changes in focus (messages from the network, some timer, some key re-binding), and it's not up to each view to interpret whether the K
key means the focus comes from the right or left.
Again, it's totally fine for some views to ignore this parameter, if the source of the focus doesn't matter.
Hi, "Я понимаю", but I'm trying to compare it to the GUI frameworks I work(ed) with like for example, Qt or Gtk, and there AFAIRC the equivalent of take_focus is never concerned with "Direction". And yet they do behave correctly when Tab or Shift+Tab is pressed. OK, now I remember. There is a concept called tab order and according to this order views are taking focus. I believe it is more logical and simpler both to comprehend and to use.
Note that for Qt and GTK (and other GUI frameworks), the situation is a bit different: most focus events come from the mouse or simply Tab/Shift-tab, and not the arrow keys. In addition, most of them have quite different view/widget APIs, often relying on OOP (even GTK, which basically reimplements OOP in C), with more complex interfaces, and more concepts "built in" the framework. By contrast, cursive currently tries to "build in" a more minimal set of concepts, and has a (slightly) more "black box" approach to views, with a smaller surface.
Note that you are of course welcome to offer alternative solutions. The whole focus system is slowly beginning to show its limitations, and a redesign is probably not too far.
Note that for Qt and GTK (and other GUI frameworks), the situation is a bit different: most focus events come from the mouse or simply Tab/Shift-tab, and not the arrow keys.
That should be an abstraction that doesn't concern cursive. What is the difference between pressing tab and right arrow?
Note that you are of course welcome to offer alternative solutions. Alternative solution is to introduce concept of "tab order" in a view, just like GUI does. No need to invent anything. Just use what works. Seriously, I know that when I see in function that takes focus argument named direction, I know something is not right. Anyway, good luck with your project. I will be using it, as I'm learning rust by building my own project. I'll try from time to time contribute. All the best.
Why? If anything, Id expect event, like mouse event, keyboard event but direction? What's the idea behind it?